/irc-logs / w3c / #css / 2015-08-01 / end

Options:

Previous day, Next day

  1. # Session Start: Sat Aug 01 00:00:01 2015
  2. # Session Ident: #css
  3. # [00:24] * Joins: adenilson (~anonymous@public.cloak)
  4. # [00:52] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
  5. # [00:59] * Joins: estellevw (~estellevw@public.cloak)
  6. # [00:59] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  7. # [00:59] * Quits: estellevw (~estellevw@public.cloak) (Client closed connection)
  8. # [01:00] * Joins: dbaron (~dbaron@public.cloak)
  9. # [01:17] * Joins: dbaron_ (~dbaron@public.cloak)
  10. # [01:23] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  11. # [01:28] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  12. # [01:36] * Joins: jdaggett (~jdaggett@public.cloak)
  13. # [02:47] * Quits: liam (liam@public.cloak) (Client closed connection)
  14. # [03:40] * Quits: dbaron_ (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  15. # [03:46] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
  16. # [04:05] <hgl> TabAtkins, is it possible to express conditions with custom properties? like when --width < 40px, --radius should equal to 0px. if not, do you think it's even a good idea for css to have this kind of language feature?
  17. # [04:08] <TabAtkins> hgl: Not currently, no. At some point in the nearish future you'll get the ability to define custom at-rules, which'll let you define your own @--if rule.
  18. # [04:09] <hgl> I was discussing with a friend about what kind of css preprocessor to choose, he thinks we should choose sass/less, because it provides powerful abstraction, and the language is always backwards compatible. but i think we should choose one like cssnext that is based on future specs, where you have the ability to pass source code directly to future browsers. what do you think?
  19. # [04:10] <hgl> TabAtkins, cool, that's what custom at-rules are for, didn't realize that
  20. # [04:10] <TabAtkins> That's one of the uses, yeah.
  21. # [04:10] <TabAtkins> I suggest Sass; I think it's the best processor personally.
  22. # [04:10] <TabAtkins> It's built on a solid, well-thought out syntax and overall system.
  23. # [04:11] <TabAtkins> And trying to track future CSS specs is weird, anyway. We change those things!
  24. # [04:11] <hgl> but eventually css is going to catch up, and the sass code you write is going to obsolete.
  25. # [04:12] <hgl> like if you have a huge amount of coffeescript codes, it looks like obsolete when babel comes up.
  26. # [04:28] * Joins: dbaron (~dbaron@public.cloak)
  27. # [04:36] * Joins: liam (liam@public.cloak)
  28. # [06:12] * Quits: renoirb (renoirb@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
  29. # [06:54] * Quits: myles (~Adium@public.cloak) ("Leaving.")
  30. # [06:58] * Quits: hgl (~hgl@public.cloak) (hgl)
  31. # [06:59] * Joins: hgl (~hgl@public.cloak)
  32. # [07:29] * Joins: myles (~Adium@public.cloak)
  33. # [07:51] <TabAtkins> hgl: No, it probably won't. Sass does a lot of things that CSS probably won't ever do, or that at least is low-probability for the foreseeable future.
  34. # [08:01] <hgl> TabAtkins, so if some really useful grammar sugar is preprocessable, the wg is just going to acknowledge the using of preprocessors, instead of incorporating these features into css directly?
  35. # [08:03] <hgl> with most browsers go evergreen, if some features exist in a spec, won't it be adapted very soon?
  36. # [08:04] <hgl> and with the faster rate of evolving a language, do you think it's wise to bet on a DSL?
  37. # [08:18] <liam> there are draft CSS features going back years that are not yet implemented
  38. # [08:19] <liam> in some cases because the features aren't entirely thought out, in some cases because e.g. interactive page-based media hasn't been a priority for browsers
  39. # [08:31] <hgl> liam, ok, thanks. i have to rethink about my enthusiasm for spec based preprocessors...
  40. # [08:34] <hgl> then is it equally not very wise, for example, to rely on web polyfills to use future APIs. like node.before() & node.query() ? since the spec can change, and these apis won't be implemented soon?
  41. # [09:14] <liam> the polyfill should continue to work though; the main problem comes when a property is implemented but with different meaning, e.g. different values
  42. # [09:14] <liam> as polyfills often test for native support first
  43. # [09:19] * leaverou is now known as leaverou_away
  44. # [09:38] * Joins: antonp (~Thunderbird@public.cloak)
  45. # [10:18] * leaverou_away is now known as leaverou
  46. # [10:30] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  47. # [12:31] * leaverou is now known as leaverou_away
  48. # [14:01] * leaverou_away is now known as leaverou
  49. # [15:31] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
  50. # [16:23] * Joins: jdaggett (~jdaggett@public.cloak)
  51. # [17:13] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  52. # [17:45] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
  53. # [18:48] * Joins: Florian (~Florian@public.cloak)
  54. # [19:16] * Joins: dbaron (~dbaron@public.cloak)
  55. # [19:56] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  56. # [21:00] * Joins: Florian (~Florian@public.cloak)
  57. # Session Close: Sun Aug 02 00:00:00 2015

Previous day, Next day

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn