/irc-logs / w3c / #webapps / 2013-06-21 / end

Options:

  1. # Session Start: Fri Jun 21 00:00:01 2013
  2. # Session Ident: #webapps
  3. # [00:20] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
  4. # [00:27] * Joins: marcosc (~marcosc@public.cloak)
  5. # [00:34] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  6. # [00:36] * Joins: smaug (~chatzilla@public.cloak)
  7. # [00:53] * Quits: tobie (tobie@public.cloak)
  8. # [01:21] * Joins: marcosc (~marcosc@public.cloak)
  9. # [01:28] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  10. # [01:32] * heycam|away is now known as heycam
  11. # [01:32] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
  12. # [01:36] * Joins: marcosc (~marcosc@public.cloak)
  13. # [01:38] * Joins: marcosc_ (~marcosc@public.cloak)
  14. # [01:38] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  15. # [01:38] * Joins: marcosc (~marcosc@public.cloak)
  16. # [01:38] * Quits: marcosc_ (~marcosc@public.cloak) (Client closed connection)
  17. # [01:40] * Joins: marcosc_ (~marcosc@public.cloak)
  18. # [01:40] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  19. # [02:16] * Joins: marcosc (~marcosc@public.cloak)
  20. # [02:23] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  21. # [02:23] * Quits: marcosc_ (~marcosc@public.cloak) (Client closed connection)
  22. # [02:23] * Joins: marcosc (~marcosc@public.cloak)
  23. # [02:26] * Quits: jsbell (~jsbell@public.cloak) ("There's no place like home...")
  24. # [02:30] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  25. # [02:43] * Quits: jeffh (~46c504c7@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  26. # [02:48] * heycam is now known as heycam|away
  27. # [02:50] * Quits: sicking (~sicking@public.cloak) (sicking)
  28. # [03:10] * Joins: marcosc (~marcosc@public.cloak)
  29. # [03:17] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  30. # [04:04] * Joins: marcosc (~marcosc@public.cloak)
  31. # [04:11] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  32. # [04:22] * Joins: marcosc (~marcosc@public.cloak)
  33. # [04:23] * Joins: karl (~karlcow@public.cloak)
  34. # [04:49] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  35. # [05:19] * Joins: marcosc (~marcosc@public.cloak)
  36. # [05:26] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  37. # [06:09] * heycam|away is now known as heycam
  38. # [06:13] * Joins: marcosc (~marcosc@public.cloak)
  39. # [06:20] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  40. # [07:07] * Joins: marcosc (~marcosc@public.cloak)
  41. # [07:15] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  42. # [07:57] * Quits: gavin (~gavin@public.cloak) (Client closed connection)
  43. # [07:58] * Joins: gavin (~gavin@public.cloak)
  44. # [08:02] * Joins: marcosc (~marcosc@public.cloak)
  45. # [08:09] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  46. # [08:28] * Joins: tobie (tobie@public.cloak)
  47. # [08:42] * Joins: Ms2ger (~Ms2ger@public.cloak)
  48. # [08:56] * Joins: marcosc (~marcosc@public.cloak)
  49. # [09:03] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  50. # [09:28] * heycam is now known as heycam|away
  51. # [09:49] * Joins: marcosc (~marcosc@public.cloak)
  52. # [10:03] * Joins: hallvors (~hallvord@public.cloak)
  53. # [10:16] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  54. # [10:33] * Joins: marcosc (~marcosc@public.cloak)
  55. # [11:01] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  56. # [11:19] * Joins: skddc (~anonymous@public.cloak)
  57. # [11:26] * Joins: marcosc (~marcosc@public.cloak)
  58. # [11:26] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  59. # [11:26] * Joins: marcosc (~marcosc@public.cloak)
  60. # [12:18] * Joins: abarsto (~abarsto@public.cloak)
  61. # [12:18] * abarsto is now known as ArtB
  62. # [12:37] * Joins: skddc_ (~anonymous@public.cloak)
  63. # [12:42] * Quits: skddc (~anonymous@public.cloak) (Ping timeout: 180 seconds)
  64. # [12:42] * skddc_ is now known as skddc
  65. # [12:46] * Joins: darobin (rberjon@public.cloak)
  66. # [12:56] * Quits: hallvors (~hallvord@public.cloak) (Ping timeout: 180 seconds)
  67. # [13:39] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  68. # [14:01] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  69. # [14:15] * Quits: skddc (~anonymous@public.cloak) (skddc)
  70. # [14:21] * Joins: marcosc (~marcosc@public.cloak)
  71. # [14:29] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  72. # [14:49] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
  73. # [15:02] * Joins: darobin (rberjon@public.cloak)
  74. # [15:11] * Joins: skddc (~anonymous@public.cloak)
  75. # [15:11] * Joins: marcosc (~marcosc@public.cloak)
  76. # [15:20] * Joins: davidb (~davidb@public.cloak)
  77. # [16:01] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  78. # [16:02] * Joins: shepazu (schepers@public.cloak)
  79. # [16:03] * Joins: Lachy (~Lachy@public.cloak)
  80. # [16:27] * Joins: jeffh (~46c504c7@public.cloak)
  81. # [17:25] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
  82. # [17:35] * Joins: jsbell (~jsbell@public.cloak)
  83. # [18:21] * Quits: skddc (~anonymous@public.cloak) (skddc)
  84. # [18:26] * ArtB changes topic to 'WebAppsWG; Web Components meeting June 21 @ 10:30 SFO time; Agenda = http://www.w3.org/wiki/Webapps/WebComponentsJune2013Meeting ; PIN = 92323#'
  85. # [18:27] <ArtB> be there or be talked about ;)
  86. # [18:34] <Ms2ger> I'm used to that
  87. # [18:38] <ArtB> LOL
  88. # [18:39] <Ms2ger> I try to make it hard by making my name unpronounceable... Didn't work
  89. # [18:41] <stearns> ah, but is it a hard or soft 'g'?
  90. # [18:42] <Ms2ger> It's a g as in gif
  91. # [18:43] <stearns> definitively answered
  92. # [18:45] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  93. # [19:22] * Quits: jeffh (~46c504c7@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  94. # [19:32] <ArtB> is anyone in this channel "live" at Dimitri's Web Components meeting (I think it is supposed to start now-ish)?
  95. # [19:33] * Joins: dbaron (~dbaron@public.cloak)
  96. # [19:33] * Joins: jkomoros (~uid7860@public.cloak)
  97. # [19:33] * Joins: Zakim (zakim@public.cloak)
  98. # [19:33] <dbaron> Zakim, this will be 92323
  99. # [19:33] <Zakim> ok, dbaron; I see RWC_WAPI(F2F)12:00PM scheduled to start 93 minutes ago
  100. # [19:33] * Joins: divya (~Adium@public.cloak)
  101. # [19:33] * Joins: RRSAgent (rrsagent@public.cloak)
  102. # [19:33] <RRSAgent> logging to http://www.w3.org/2013/06/21-webapps-irc
  103. # [19:34] * dbaron RRSAgent, make logs public
  104. # [19:34] * RRSAgent I have made the request, dbaron
  105. # [19:34] <ArtB> RRSAgent, make log public
  106. # [19:34] <RRSAgent> I have made the request, ArtB
  107. # [19:34] <ArtB> RRSagent, this meeting spans midnight
  108. # [19:34] <ArtB> RRSAgent, make minutes
  109. # [19:34] <RRSAgent> ok, ArtB; I will not start a new log at midnight
  110. # [19:34] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html ArtB
  111. # [19:34] <jkomoros> ScribeNick: jkomoros
  112. # [19:34] * dbaron Zakim, who is on the phone?
  113. # [19:34] * Zakim RWC_WAPI(F2F)12:00PM has not yet started, dbaron
  114. # [19:34] * Zakim sees on irc: RRSAgent, divya, Zakim, jkomoros, dbaron, jsbell, Lachy, davidb, marcosc, ArtB, Ms2ger, tobie, gavin, karl, Hixie, stearns, krijnh, logbot, anssik, timeless, ed,
  115. # [19:34] * Zakim ... dgrogan, yoichio, mounir, heycam|away, Dashiva, heath, hober, schuki
  116. # [19:35] <ArtB> ScribeNick: jkomoros
  117. # [19:35] <jkomoros> rrsagent, this meeting spans midnight
  118. # [19:35] <RRSAgent> ok, jkomoros; I will not start a new log at midnight
  119. # [19:35] <ArtB> Scribe: Alex
  120. # [19:35] * dbaron does not think this meeting spans midnight
  121. # [19:35] * hober has found it best to not disagree with dbaron on such things
  122. # [19:35] * ArtB dbaron - I asked Alex to do that, just in case ;)
  123. # [19:35] <jkomoros> Present+ Edward_OConnor
  124. # [19:36] * Ms2ger assumes dbaron is omniscient on timezones
  125. # [19:36] <jkomoros> Present+ Ryosuke_Niwa
  126. # [19:36] <ArtB> Meeting: WebApps' Web Components f2f Meeting
  127. # [19:36] <ArtB> Agenda: http://www.w3.org/wiki/Webapps/WebComponentsJune2013Meeting
  128. # [19:36] <ArtB> Chair: Dimitri
  129. # [19:36] <jkomoros> Present+ Bear_Travis
  130. # [19:36] <ArtB> RRSAgent, make minutes
  131. # [19:36] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html ArtB
  132. # [19:36] <jkomoros> Present+ Divya_Manian
  133. # [19:36] <jkomoros> Present+ Alex_Komoroske
  134. # [19:36] <jkomoros> Present+ David_Baron
  135. # [19:36] <jkomoros> Present+ Priyank_Singhal
  136. # [19:36] <jkomoros> Present+ Steve_Orvell
  137. # [19:36] * Joins: dfreedm (~uid7859@public.cloak)
  138. # [19:37] <jkomoros> Present+ Daniel_Freedman
  139. # [19:37] <jkomoros> Present+ Dimitri_Glazkov
  140. # [19:37] <jkomoros> Present+ Elliott_Sprehn
  141. # [19:37] * Joins: singhalpriyank (~singhalpriyank@public.cloak)
  142. # [19:37] <jkomoros> Present+ Scott_Miles
  143. # [19:37] * dbaron is not planning to be here past 5pm PDT
  144. # [19:37] * Joins: sorvell (~uid12099@public.cloak)
  145. # [19:38] * Joins: jeffh (~266f978c@public.cloak)
  146. # [19:38] * Joins: betravis (~Adium@public.cloak)
  147. # [19:39] <jkomoros> Chair: Dimitri_Glazkov
  148. # [19:39] <jkomoros> Meeting: Styling Issues in Shadow DOM and CSS
  149. # [19:40] * Joins: rniwa (~rniwa@public.cloak)
  150. # [19:42] <jkomoros> Topic: Quick Overview of Shadow DOM concepts
  151. # [19:42] <divya> i think we need cofffee
  152. # [19:42] <jkomoros> DG: Hoping that the main focus of this meeting will be primarily arounds CSS + Shadow DOM
  153. # [19:43] <jkomoros> ... we had one original idea, but developers trying to use it gave feedback that it wasn't exactly the right "knobs"
  154. # [19:43] * hober concurs with his esteemed colleague from adobe on the caffeine question
  155. # [19:43] <jkomoros> ... there are people here who are "Browser Vendors", and there are people who are the "web developers"
  156. # [19:43] * rniwa agrees with divya and hober
  157. # [19:43] <rniwa> but needs tea instead
  158. # [19:44] <jkomoros> ... a bunch of folks in the latter group here are from Polymer, Daniel Buchner (who should join at some point) represents x-tags
  159. # [19:44] <Ms2ger> s/but needs tea instead//
  160. # [19:44] <divya> Ms2ger: oMG YOU ARE STALKING EVERYTHING
  161. # [19:44] <jkomoros> ... and then spec folks, fantasai and tabatkins
  162. # [19:44] <Ms2ger> s/Ms2ger: oMG YOU ARE STALKING EVERYTHING//
  163. # [19:44] <jkomoros> ... who aren't here yet.
  164. # [19:44] <rniwa> Ms2ger: i think i'm allergic to coffee though :/
  165. # [19:44] <jkomoros> dbaron: Blake Kaplan and William Chen (?) have been working on Shadow DOM at Mozilla
  166. # [19:44] <jkomoros> ... and I've been talking with them
  167. # [19:45] * Quits: rniwa (~rniwa@public.cloak) (rniwa)
  168. # [19:45] * Joins: tross (~tross@public.cloak)
  169. # [19:47] <Ms2ger> s|Ms2ger: i think i'm allergic to coffee though :/||
  170. # [19:47] <Ms2ger> RRSAgent, make minutes
  171. # [19:47] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html Ms2ger
  172. # [19:51] <jkomoros> [by the way, we all took a coffee break]
  173. # [19:51] * Joins: rniwa (~rniwa@public.cloak)
  174. # [19:52] <jkomoros> [break over]
  175. # [19:52] * Ms2ger that was an early break
  176. # [19:52] <jkomoros> DG: The general idea of Shadow DOM is that you have an ability to create trees, like before, but connected for rendering purposes, render in place of nodes in document
  177. # [19:52] <rniwa> wasn't there explainer somewhere?
  178. # [19:52] * divya knows this format of avoiding being cited in minutes
  179. # [19:53] * divya will use this format to prevent extra work for Ms2ger
  180. # [19:53] <jkomoros> ... this existed in many different systems before. It allows composability (one tree vs multiple)
  181. # [19:53] <rniwa> is https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html still up to date?
  182. # [19:53] <jkomoros> ... if I can replace the rendering of a node, what happens to its children?
  183. # [19:53] <slightlyoff> rniwa: or, also: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
  184. # [19:53] * Ms2ger substitutes divya out of the logs entirely
  185. # [19:53] <jkomoros> ... the general overview gets trickier and trickier, but we have converged on a solution in today's Shadow DOM spec
  186. # [19:53] <jkomoros> [dglazkov draws a diagram on the board]
  187. # [19:54] <rniwa> Also see: https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/
  188. # [19:54] * divya actively draws graffiti over Ms2ger's substitution
  189. # [19:54] <jkomoros> ... every node that has children, you can associate (off to the right) with a shadowRoot: a DocumentFragment with extra stuff in it
  190. # [19:54] <slightlyoff> rniwa: this loads for me: https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html
  191. # [19:54] <jkomoros> ... extra stuff is effectively a subclass of DocumentFragment. Things like getElementByID, querySelector. Stuff that has migrated into Document mainly anyway
  192. # [19:54] <jkomoros> dbaron: So those just query what's in the Shadow DOM?
  193. # [19:55] <rniwa> slightlyoff: oh oops, yeah. i guess it doesn't have an ordinary index.html > / rewrite :/
  194. # [19:55] <jkomoros> DG: think of the line connecting ShadowRoot is not a normal connection--it's a separate tree
  195. # [19:55] <jkomoros> ... insertion points can be any elements inside the tree. They're called <content>
  196. # [19:55] <jkomoros> ... we use a rhombus for insertion points
  197. # [19:55] <jkomoros> ... <content> name comes from XBL2
  198. # [19:55] <jkomoros> ... you can have more than 1 content
  199. # [19:56] <jkomoros> ... content can have a select attribute, which takes a narrow subset of CSS selctors
  200. # [19:56] <jkomoros> ... that match against children of the parent node.
  201. # [19:56] <jkomoros> ... currently limited to ID, tagname, attributes, and class
  202. # [19:56] <jkomoros> ... no combinators.
  203. # [19:56] <jkomoros> ... that's the conceptual model. But actually a node can have MULTIPLE shadow roots
  204. # [19:57] <jkomoros> ... the method on the ndoe is "createShadowRoot"
  205. # [19:57] <jkomoros> ... there's an ordering.
  206. # [19:57] <jkomoros> ... Sometimes the element already has a shadowtree (like InputElement or TextArea)
  207. # [19:57] <jkomoros> ... they're basically the same as how the native implementation might be done
  208. # [19:58] <jkomoros> ... it's actually a stack of trees. new ones go on top of old ones; the newest one is the visible one. The ones underneath don't render
  209. # [19:58] <jkomoros> ... there's a concept of older and younger shadow tree
  210. # [19:58] <jkomoros> ... youngest one is the one that gets rendered
  211. # [19:58] <jkomoros> ... soemtimes you want to use parts of the older shadow tree
  212. # [19:58] <jkomoros> ... which is why there's an insertion point called <shadow>
  213. # [19:59] <jkomoros> ... when you put it in a shadow root, it will show whatever what is the older shadow root
  214. # [19:59] <jkomoros> ... it allows the youngest guy to channel the older guy
  215. # [19:59] <jkomoros> ... explicit children can only go to one insertion point.
  216. # [20:00] <jkomoros> ... there's an idea conceived by Jan on the polymer-dev list, the shadow acting as a function (?)
  217. # [20:00] <jkomoros> ... but as of now, there is an order, only selected once
  218. # [20:00] <jkomoros> ... this allows developers to take existing elements, and adorn them with existing stuff from older shadow trees
  219. # [20:01] <jkomoros> ... if there's nothing in the older shadow tree, it works as the last content element--whatever hasn'
  220. # [20:01] * Joins: darobin (rberjon@public.cloak)
  221. # [20:01] <jkomoros> ... been distributed
  222. # [20:01] <Ms2ger> s/hasn'/hasn't/
  223. # [20:01] <jkomoros> ... whole point of Shadow DOM spec is distributed. That's the majority of the spec
  224. # [20:02] <jkomoros> ... how are they distributed, what's the effect
  225. # [20:02] <jkomoros> ... things like focus, events, and rendering/sytling
  226. # [20:02] <jkomoros> ... the latter is what I want to talk abou ttoday
  227. # [20:02] <jkomoros> ... the others we have figured out mostly
  228. # [20:03] <jkomoros> dbaron: I was involved in the XBL RCC thing in 2004 (?) so these concepts are not all new to me
  229. # [20:03] <jkomoros> DG: now we get into style
  230. # [20:03] <jkomoros> ... this is where things get interesting
  231. # [20:03] <dbaron> (also XBL1 :-)
  232. # [20:03] <jkomoros> ... if the shadow root is a document fragment, what does that mean from styling perspective?
  233. # [20:03] <jkomoros> ... if I'm distributing a text node into a content element, what is its style?
  234. # [20:05] <jkomoros> rniwa: What does hte current spec say about style?
  235. # [20:05] <Ms2ger> s/hte/the/
  236. # [20:05] <Ms2ger> RRSAgent, make minutes
  237. # [20:05] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html Ms2ger
  238. # [20:06] <jkomoros> [I missed about 30 seconds :-( ]
  239. # [20:06] <jkomoros> dbaron: I think it's worth separting selector matching and inheritance
  240. # [20:06] <jkomoros> [esprehn draws a diagram on the board]
  241. # [20:06] * Ms2ger photos!
  242. # [20:08] <jkomoros> es: When you attach the shadow root, content doesn't render. But in this shadow, the content is "teleported" as though it was there when rendering
  243. # [20:08] <jkomoros> ... so you get styles from where you came from, and styles where you're going
  244. # [20:08] <jkomoros> ... there's a way to reset styles at shadow boundary
  245. # [20:09] <divya> http://s3.amazonaws.com/Gyazo/1371838156.png
  246. # [20:09] <jkomoros> ... when the tree gets flattened out, conceptually it gets flattened out
  247. # [20:10] <jkomoros> Present+ Tab_Atkins
  248. # [20:11] <jkomoros> [es draws the "composed" result on the board for clarity]
  249. # [20:11] * Quits: ArtB (~abarsto@public.cloak) ("Leaving.")
  250. # [20:11] <jkomoros> ... we use "composed" tree to mean, the thing with all of the things teleported
  251. # [20:11] <jkomoros> ... don't use "flattened" tree
  252. # [20:12] <jkomoros> dg: Although at some point we might, depending on if there's mutiple trees
  253. # [20:12] <jkomoros> rniwa: If you have a style in the distributed content, that follows hierarchy in original content
  254. # [20:12] <jkomoros> ... and merge in with shadow styles
  255. # [20:12] <jkomoros> ... I'm not sure that even in an complex widget that makes sense
  256. # [20:12] <jkomoros> ... things get really wonky
  257. # [20:13] <jkomoros> sorvell: It's just inherited styles that work this way
  258. # [20:13] <jkomoros> es: One special case si that if you have a style inside of the shadow root, it's automatically scoped to the shadow root
  259. # [20:13] <jkomoros> s/style/style element/
  260. # [20:14] <jkomoros> dbaron: So the selectors in the scoped style only match things in the shadow tree, NOT stuff that gets "teleported" there
  261. # [20:14] <jkomoros> sorvell: This is one part of the spec as a developer that makes total sense
  262. # [20:14] <jkomoros> ... allows you to worry just about this shadow root. it works really well in practice
  263. # [20:14] <jkomoros> sjmiles: Occasionally you have to pierce through that barrier, that's when it gets harder
  264. # [20:14] <divya> http://s3.amazonaws.com/Gyazo/1371838492.png
  265. # [20:14] <jkomoros> ... as a practical matter WE haven't run into that problem
  266. # [20:15] <jkomoros> ... (confused styles)
  267. # [20:15] * Joins: fantasai (~fantasai@public.cloak)
  268. # [20:15] <jkomoros> dbaron: By pierce through, do you mean that someimes you want the explicit children of the node to inherit from what before as opposed to from shadow dom?
  269. # [20:16] <jkomoros> ... is there a way to say that, in that case, the span shoul dinherit font size but not color
  270. # [20:16] <jkomoros> sjmiles: no, it's all or nothing
  271. # [20:16] <jkomoros> ... (basically)
  272. # [20:16] <jkomoros> ... we haven't run into that need in practice y et
  273. # [20:17] <jkomoros> ... that's based on empirical data with n points, where n is a relatively small number in the grand scheme of things
  274. # [20:17] <jkomoros> ... it's possible at some point in the future someone will need it, but we don't now
  275. # [20:17] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  276. # [20:17] <jkomoros> dg: let's enumerate the cool styling hooks that we have today, then figure out which ones are missing
  277. # [20:17] <jkomoros> ... 1) Style scoped.
  278. # [20:17] <jkomoros> ... it's acgtually a close cousin of shadowRoot. It's very similar scoping behavior
  279. # [20:18] <jkomoros> ... but it's a scoping NODE, and style scoped is a scoping ELEMENT
  280. # [20:18] <jkomoros> ... but they have similar abilities, except none of the styles from the document (outside the SR) don't apply down.
  281. # [20:18] <jkomoros> ... style scoped in isolation, essentially
  282. # [20:18] <jkomoros> dbaron: So nothing from the author style sheets don't match SR. But still UA styles
  283. # [20:19] <jkomoros> DG: we have applyAuthorSTyles
  284. # [20:19] <jkomoros> ... that allows the component to explicitly allow outside styles out to come inside
  285. # [20:19] <jkomoros> ... user styles are treated like Author styles
  286. # [20:20] <jkomoros> eo: It's problematic that user styles by default get blocked
  287. # [20:20] <jkomoros> dg: Actually, we don't know what we do here, we need to check
  288. # [20:20] <jkomoros> tabatkins: It's reasonabl eto say, yeah, User styles apply by default
  289. # [20:20] <jkomoros> dbaron: How selector matching works is intersting
  290. # [20:21] <jkomoros> dg: If you say applyAuthorStyles, there's still a weird relationship, where you even though a child of shadowRoot might LOOK like it's child of the host
  291. # [20:21] <jkomoros> ... it's actually not. The selector matching can either be fully in the host, or in the SR
  292. # [20:21] <jkomoros> [I think I got that right?]
  293. # [20:21] <jkomoros> ... so in this example, div > div will not match
  294. # [20:21] <jkomoros> ... but if you just do `div` and have applyAuthorStyles it will match both divs
  295. # [20:21] <jkomoros> sjmiles: If I put div class=foo, and foo is defined in document, it won't see that
  296. # [20:22] <jkomoros> ... as a user I go, applyAuthorStyles will make it work, but it won't
  297. # [20:22] <jkomoros> dg: No, that will work
  298. # [20:23] <jkomoros> es; BAsically, the selector must COMPLETELY Match outside, or completely inside. There's no boundary crossing
  299. # [20:23] <jkomoros> eo: What about a boundary crossing combinator?
  300. # [20:23] <dbaron> db: yeah
  301. # [20:23] <jkomoros> dg: That's what we want to talk about today: :-)
  302. # [20:23] <jkomoros> ... There's another flag on SR that says resetStyleInheritance
  303. # [20:23] <jkomoros> ... it's very powerful
  304. # [20:23] <jkomoros> ... everything inside of the SR, when you flip to true, it will look like it's initial styling
  305. # [20:24] <jkomoros> dbaron: Kind of like you had a parent in between all ::initial (?)
  306. # [20:24] <dbaron> s/all ::initial (?)/all:initial/
  307. # [20:24] <jkomoros> dg: similar thing exists on insertion points
  308. # [20:24] <jkomoros> ... so that you can have the styles in SR not go into the composed children
  309. # [20:25] <jkomoros> ... that's all the styling machinery (minus any boundary-piercing things)
  310. # [20:25] <jkomoros> ... but this isn't enough. how do you make the subtrees intreact with doc?
  311. # [20:26] <jkomoros> ... similarly, sorvell wants to be able to style inside the shadow tree, style the composed children as well
  312. # [20:26] <jkomoros> ... like say in a tab strip, styling the active children
  313. # [20:26] <jkomoros> ... you want to be able to let SOME stuff in from SR in from document, and also in
  314. # [20:26] <jkomoros> ... similar for content
  315. # [20:27] <jkomoros> dbaron: The XBL solution to that is that you have a separate binding for active tab that is different, point to that instead
  316. # [20:27] <jkomoros> dg: We didn't want the content of the host to not know what's happening to it (?)
  317. # [20:27] <jkomoros> ... we had two solutions, both of which have strengths and weaknesses
  318. # [20:27] <jkomoros> ... 1) let CSS Variables bleed through the SR boundary. So you could specify a CSS variable in doc, and catch it inside the SR
  319. # [20:28] <jkomoros> tabatkins: in Style WG, we decided that variable resetting isn't covered in "all". YOu'd need to explicitly say "vars" as well (syntax I probably got wrong)
  320. # [20:28] <jkomoros> dbaron: i don't like describing inheritance blocking as all property
  321. # [20:29] <jkomoros> fantasai: You probably do want the ability to jump inheritance over the shadows
  322. # [20:29] <jkomoros> dbaron: I'm nervous about cutting off inheritance from stuff outside SR to stuff inside. I'm less nervous about inheriting from the shadow into the children
  323. # [20:29] <jkomoros> tabatkins; that turns out to be extremely popular for writing components in the real world
  324. # [20:30] <jkomoros> ... like components in jquery have to go through and manually reset everything
  325. # [20:30] <jkomoros> ... they want consistent, predictable starting point--even if they allow poking in after that
  326. # [20:30] <jkomoros> fantasai: But imagine we're using this to rearrange list items into new structure. The expectation of the author is that setting font on the root of the doc, it sets it everywhere. But if you do cut off inheritance, then those list items will have UA default
  327. # [20:31] <jkomoros> tabatkins: That's why it's a flag. Component authors can decide if it works
  328. # [20:31] <jkomoros> es: Actually, default is to allowing
  329. # [20:31] <jkomoros> sjmiles: So if you turn it off, the component author did it on purpose
  330. # [20:32] <jkomoros> dbaron: So in thec ases where you have a binding wiht lots of content inside, like say a tab widget. You probably want the inheritance through to your big piece of content. Bu there's some little content you don't want it
  331. # [20:32] * Joins: darobin (rberjon@public.cloak)
  332. # [20:32] <jkomoros> dg: Think about disqus use case. They mostly want it to match the blog they're embedded in. But if you're building an app, you might want a certain style that's very aprticular no matter where it is
  333. # [20:33] <jkomoros> ... like the G+ share widget, as an example, that wants to have complete control over exactly what's inside it
  334. # [20:33] <jkomoros> sjmiles: db makes a good point
  335. # [20:33] <jkomoros> tabatkins: wihtin the shadow, if you want to block it only in some places, the 'all' property exists
  336. # [20:33] <jkomoros> sjmiles: Or make a component for just the parts where you want to reset it
  337. # [20:33] <jkomoros> sorvell: We don't use resetting much in practice, it's such a blunt tool
  338. # [20:34] <jkomoros> ... generally we want to control a small number of properties
  339. # [20:34] <jkomoros> rniwa: In disqus use case, you want to be able to read the background color of surrounding, but decide how to interpet that
  340. # [20:34] <jkomoros> tabatkins: Today you can do that. Use 'all' to reset all, then 'inherit' for the other properties you want to allow in. Or the other way around, use 'initial'
  341. # [20:35] <jkomoros> es: LIke in a facebook button as an example, you want to force the font, but don't care about the size of it
  342. # [20:35] <jkomoros> dg: Let's keep going with explaining the tools
  343. # [20:35] <jkomoros> ... those variables are cool but not enough
  344. # [20:35] <jkomoros> ... we see this alot with WebKit's internal input elements
  345. # [20:35] <jkomoros> ... you want access to a sepcific element to style arbitrarily
  346. # [20:36] <jkomoros> ... leads to:
  347. # [20:36] <jkomoros> ... 2) Custom pseudo elements
  348. # [20:36] <Ms2ger> s/thec ases/the cases/
  349. # [20:36] <Ms2ger> s/aprticular/particular/
  350. # [20:36] <jkomoros> ... you define a pseudo attribute on an element
  351. # [20:36] <jkomoros> ... then you can use it with standard ::foo syntax in selectors
  352. # [20:37] <jkomoros> ...so like <outer-element>::x-foo
  353. # [20:37] <jkomoros> dbaron: Like functionality, but want a function
  354. # [20:37] <jkomoros> eo: agreed
  355. # [20:37] <jkomoros> dg: Agreed, at the time when we proposed this dave hyatt didn't want it to be a functional syntax, but we can revisit
  356. # [20:38] <jkomoros> es: ONe of the goals of the project is to explain lower-level magic
  357. # [20:38] <jkomoros> eo: I don't agree with that goal, for what it's worth
  358. # [20:38] * Joins: chaals (~Adium@public.cloak)
  359. # [20:38] <jkomoros> es: If we swithc to functional syntax, we miss out on explaining the ::foo magic
  360. # [20:39] <jkomoros> rniwa: We could change the syntax for pseudos like that if we want, only blink and webkit do this
  361. # [20:39] <jkomoros> dbaron: If implementations want to implement web platform features that have pseudos, they can have their own versions that don't use the functional syntax
  362. # [20:39] <jkomoros> ... I'm SLIGHTLY sympathetic to wanting to explain the magic. But some of them are things we really don't want to freeze
  363. # [20:40] <jkomoros> ... like if we had done styling of form controls right back in 2000/2002, it wouldn't have been web-compatible to make the form controls used on iOS and ANdroid
  364. # [20:40] <fantasai> s/right/"right"/
  365. # [20:40] <jkomoros> ... because the web would have depended on fixed structures that work on destop, but don't make sense on mobile devices
  366. # [20:40] <jkomoros> dg: There is a larger debate here. I want to table that for now. Keep it in mind today, but avoid engaging today
  367. # [20:40] <jkomoros> eo: We'll only be able to make so much progress without it
  368. # [20:41] <jkomoros> dg: So even with this second knob, it doesn't complete all of the use cases from developers
  369. # [20:41] <dbaron> (I think he used "put it aside" rather than "table" (which is en-GB/en-US ambiguous).)
  370. # [20:41] <jkomoros> ... now I'm crossing threshold to the boundary-crossing thing
  371. # [20:41] <jkomoros> ... I'll first describe things they way they WERE/ARE
  372. # [20:42] <jkomoros> divya: What do you mean by "functional syntax"?
  373. # [20:42] <jkomoros> dg: things like ::shadow(foo)
  374. # [20:43] <jkomoros> dbaron: the advantage is, there's a rule in selector spec that says rules UA doesn't understand get dropped
  375. # [20:43] <jkomoros> ... pseudo elements/classes are part of that rule. WebKit/Blink don't do that correctly
  376. # [20:43] <jkomoros> ... all other browsers drop the entire rule, but WebKit/Blink retains those
  377. # [20:43] <jkomoros> es: That was willful; we can fix it
  378. # [20:43] <jkomoros> tabatkins: But peopel do use it today already :-(
  379. # [20:44] <jkomoros> dg: In querySelector, incidetnally, we don't violate spec
  380. # [20:44] <jkomoros> ... onto the new things that we're thinking of
  381. # [20:44] <jkomoros> ... in order to select things that are distirbuted into an insertion point, we invested the distirbuted pseudo element function
  382. # [20:45] <jkomoros> ... ::distributed(---------)
  383. # [20:45] <jkomoros> ... where ----- allows combinators
  384. # [20:45] <jkomoros> ... on an insertion poiint, inside of a SR, it matches the element that was distributed into that matches the inner selector in the function
  385. # [20:46] <jkomoros> es: example: content::dsitributed(span) { border: ________ }
  386. # [20:46] <Ms2ger> s/poiint/point/
  387. # [20:46] <Ms2ger> s/dsitributed/distributed/
  388. # [20:46] <jkomoros> ... in the example we diagrammed, that style that earlier didn't match, now matches
  389. # [20:47] <jkomoros> tabatkins: Remember, this is current junky stuff that we don't like
  390. # [20:47] <jkomoros> es: Essentially content has a list of things that have been distributed in, the selector inside the parens says which in that list to select
  391. # [20:47] <jkomoros> sorvell: It's relative
  392. # [20:47] <jkomoros> dg: It's relative to the virtual node that represents the thing that envelopes all distributed elements
  393. # [20:48] <jkomoros> sorvell: use case: i want to style all children, not all descendants
  394. # [20:48] <jkomoros> ... so you can do like content::distributed( > span)
  395. # [20:48] <jkomoros> es: It's like find() on content
  396. # [20:48] <jkomoros> dbaron: I don't know if I like leading cominbators yet
  397. # [20:48] <jkomoros> fantasai: I have reservations, but I think at this point we have to go with it, everyone expects it to work that way
  398. # [20:49] <jkomoros> tabatkins: jquery uses it for years, and now it's documented in selectors level 4. It's a small section
  399. # [20:49] <jkomoros> dbaron: leading combinators only work when there's an implicit node being targeted to
  400. # [20:50] <jkomoros> sjmiles: This is very necessary in our experience
  401. # [20:50] <jkomoros> divya: Can I have a class on the content element and use that in the selector?
  402. # [20:50] <jkomoros> dg: yes
  403. # [20:50] * Quits: karl (~karlcow@public.cloak) (":tiuQ tiuq sah woclrak")
  404. # [20:50] <jkomoros> es: Although content element itself is NOT stylable
  405. # [20:50] <jkomoros> ... which I don't like. I wish that I could style the content to, say, display:none it
  406. # [20:50] <jkomoros> ... currently it has no effect
  407. # [20:50] <jkomoros> ... it's bizarre
  408. # [20:50] <jkomoros> dg: I agree
  409. # [20:51] <stearns> +1 to styling content nodes
  410. # [20:51] <jkomoros> ... I would like to explain content as a display:contents
  411. # [20:51] <jkomoros> es: In the current model, it's easy to distribute two things, but if you want to hide it, you need ANOTHER wrapper
  412. # [20:51] <jkomoros> ... styles targeted at <content> don't inherit down; it's unstylable, no rendernode
  413. # [20:52] <jkomoros> fantasai: If it's an intermediary, it makes for example uls and lis nested not work
  414. # [20:52] <jkomoros> dg: I hope we can solve it by having <content> have display:contents on it
  415. # [20:52] <jkomoros> fantasai: but that doesn't address the ul/li use case
  416. # [20:53] <fantasai> also mentioned :nth-child
  417. # [20:53] <fantasai> ul/li shouldn't be a problem
  418. # [20:53] <jkomoros> dg: let's talk about @host
  419. # [20:53] <fantasai> otherwise
  420. # [20:53] <jkomoros> ... we want to get rid of thinks
  421. # [20:53] <jkomoros> s/thinks/this
  422. # [20:54] <jkomoros> ... when you put a SR inside a tree, I want to be able to apply borders on the component, for example
  423. # [20:54] <jkomoros> ... works like @host { [selector] { border: 1px solid red }}
  424. # [20:54] <jkomoros> ... the inner selector matches only host
  425. # [20:54] <jkomoros> dbaron: and what would antyhing other than *
  426. # [20:55] <jkomoros> eo: You can imagine a case where you want to embed a widget in two different places, and you only want one (regarding why you'd want something other than *)
  427. # [20:55] <jkomoros> tabatkins: And because of is attribute, you could have one component with different tag-names
  428. # [20:55] <jkomoros> dbaron: So @host lets the SR influence the containing box
  429. # [20:56] <jkomoros> ... I think that in XBL1 we replace the outer box, but I might be misremembering
  430. # [20:56] <jkomoros> dg: This is the entire family of styling stuff. Now we want to get rid of many of these
  431. # [20:57] * Quits: chaals (~Adium@public.cloak) (Client closed connection)
  432. # [20:57] * Joins: chaals1 (~Adium@public.cloak)
  433. # [20:59] * Joins: betravis1 (~Adium@public.cloak)
  434. # [20:59] * Quits: scheib (~uid4467@public.cloak) (Ping timeout: 180 seconds)
  435. # [21:00] * Quits: dfreedm (~uid7859@public.cloak) (Ping timeout: 180 seconds)
  436. # [21:00] <fantasai> side discussion of pseudo-element syntax, vs . combinators vs. @rule
  437. # [21:00] * Quits: jsbell (~jsbell@public.cloak) (Ping timeout: 180 seconds)
  438. # [21:00] <fantasai> ::distributed() matches pattern of ::cue() and ::region(), seems we're alinging on that
  439. # [21:00] * Joins: heathjs (~quassel@public.cloak)
  440. # [21:01] * Quits: tross (~tross@public.cloak) (Ping timeout: 180 seconds)
  441. # [21:01] * Quits: sorvell (~uid12099@public.cloak) (Ping timeout: 180 seconds)
  442. # [21:01] * Quits: betravis (~Adium@public.cloak) (Ping timeout: 180 seconds)
  443. # [21:01] * Quits: slightlyoff (~uid1768@public.cloak) (Ping timeout: 180 seconds)
  444. # [21:03] * Quits: jkomoros (~uid7860@public.cloak) (Ping timeout: 180 seconds)
  445. # [21:03] * Quits: dgrogan (~dgrogan@public.cloak) (Ping timeout: 180 seconds)
  446. # [21:03] * Quits: heath (~quassel@public.cloak) (Ping timeout: 180 seconds)
  447. # [21:03] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  448. # [21:04] * Joins: dbaron (~dbaron@public.cloak)
  449. # [21:09] <fantasai> ScribeNick: fantasai
  450. # [21:09] <fantasai> ... @host did not solve the body class=light, and have components be able to see that
  451. # [21:09] <fantasai> sjmiles: ANd we never used this @host { * {}}
  452. # [21:09] <fantasai> fantasai: You probably want ::shadow, ::light, and ::context (to reach out)
  453. # [21:09] <fantasai> dbaron: or a combinator to jump out
  454. # [21:09] <fantasai> fantasai: Issue with a combinator is that it breaks the rule where combinators limit the matched set as you go
  455. # [21:09] <fantasai> ... so if you did bar <magic cobminator> foo, suddenly you're selecting a different set of foos
  456. # [21:09] <fantasai> dbaron: What I was thinking of was a combinator that would let you get to the scoped root from the selecto rthat's selecting inside it
  457. # [21:09] <fantasai> ... which is adding restrictions, right?
  458. # [21:09] <fantasai> ... in the dark theme use case
  459. # [21:09] <fantasai> tabatkins: yeah, that works with combinator
  460. # [21:09] <fantasai> ... eventually we rejected that idea
  461. # [21:09] <fantasai> [tab opens a Google Doc to show this idea off. He will share a link here]
  462. # [21:09] <fantasai> [we will share the doc later]
  463. # [21:09] <fantasai> docs.google.com/document/d/19fpRugyOO8kZfVVfdN1vkorwv8rmKztfNOEVLzIU2pU/edit?usp=sharing
  464. # [21:09] * Joins: jkomoros (~jkomoros@public.cloak)
  465. # [21:09] <fantasai> ... does that work?
  466. # [21:09] <fantasai> ... no :-(
  467. # [21:09] <fantasai> tabatkins: host element and shadow have equal claim
  468. # [21:09] <fantasai> ... we need to pretend the hos telement is in the root of the shadow tree
  469. # [21:09] <fantasai> ... so i fyou want to select on it, all you do is [writes in doc]
  470. # [21:09] <fantasai> ... this example will target the host element outside
  471. # [21:09] <fantasai> http://tinyurl.com/mueleah
  472. # [21:10] <fantasai> ^ that link works
  473. # [21:10] <fantasai> s/selecors/selectors/
  474. # [21:10] <fantasai> tabatkins: you want to be able to select based on the content further up in the document. like the theme use case, or modernizer up higher
  475. # [21:10] <fantasai> ... but you don't want to allow arbitrary selecors above
  476. # [21:10] <jkomoros> can you see this?
  477. # [21:10] <dbaron> ScribeNick: jkomoros
  478. # [21:10] <singhalpriyank> yes
  479. # [21:10] <jkomoros> tabatkins: If you have the outer document followed by a shadow element, and inside of that another component
  480. # [21:11] <jkomoros> ... the outer document you would see includes the shadow tree of the outer component.
  481. # [21:11] <jkomoros> ... that breaks encapsulation, allows developers to depend on details of components outside
  482. # [21:11] <jkomoros> ... we still need a communication channel to outside
  483. # [21:11] <jkomoros> ... we think we have a simple thing that satisfies use csaes
  484. # [21:12] <jkomoros> ... here's an example. The context pseudo class is placed on the root element (hsot element)
  485. # [21:12] <jkomoros> ... it matches if something in the compound selector matches in the fully composed ancestor list (?)
  486. # [21:12] <jkomoros> ... including stuff in other boundaries
  487. # [21:12] <jkomoros> ... because maybe you're applying a theme inside of one of the parent components above
  488. # [21:12] <jkomoros> ... it allows some information to be piped through, but not enough to allow a fragile dependency (we hope)
  489. # [21:13] <jkomoros> ... the list of elements checked starts with host element itself, goes up to the root, through any of the composed shadow trees
  490. # [21:13] <jkomoros> ... that's the only way to select up outside
  491. # [21:13] <jkomoros> ... going the other way, we still use ::distributed
  492. # [21:13] * Joins: dfreedm (~dfreedm@public.cloak)
  493. # [21:13] <jkomoros> ... works the same way
  494. # [21:13] * Joins: scheib (~uid4467@public.cloak)
  495. # [21:13] <jkomoros> ... we think this solves all the use cases we know of
  496. # [21:14] <jkomoros> ... and it's convenient and easy ,not the contorted tree hopping of @host and everything else
  497. # [21:14] <jkomoros> dbaron: What is removed?
  498. # [21:14] * Joins: shepazu (schepers@public.cloak)
  499. # [21:14] <jkomoros> tabatkins: What is removed is the @host (in favor of moving host element into shadow tree for styling purposes, and using context pseudo class to select up)
  500. # [21:14] * Joins: dgrogan (~dgrogan@public.cloak)
  501. # [21:14] * dfreedm is now known as dfreedm_
  502. # [21:15] <jkomoros> rniwa: So if you have multiple composed layers, it selects each composited layer (?)
  503. # [21:15] <jkomoros> tabatkins: no, the fully flattened tree up above
  504. # [21:15] <jkomoros> ... you do see the shadow dom of things up the tree... but not very much
  505. # [21:15] <jkomoros> ... so at any point you can inject information in
  506. # [21:15] <jkomoros> rniwa: So a shadow DOM A, inside sahdow dom B
  507. # [21:16] * Joins: jsbell (~jsbell@public.cloak)
  508. # [21:16] <jkomoros> tabatkins: we haven't changed the way normal selectors work. In a shadow style sheet, still only match within that shadow tree
  509. # [21:16] <jkomoros> ... only thing that I think we might want to change, as a result of the recent discussion aroudn region pseudo-element (as opposed to rule)
  510. # [21:17] <jkomoros> ... the problem is this distributed pseudo class isn't compatible with any nesting mechanisms we might add in future
  511. # [21:17] <jkomoros> ... like, if you had foo bar baz {} as foo { @nest bar baz { ... }} , the distributed pseudo class wouldn't let you do the nested selectors
  512. # [21:17] <jkomoros> ... same problem applies to regions, because regions often have complex selectors inside of the regions
  513. # [21:17] * fantasai would do @scope foo { bar baz { ... } }, personally
  514. # [21:18] <jkomoros> ... a possible aternate syntax is to have content selected and inside have a @distributed rule that takes ...
  515. # [21:18] <jkomoros> ... content { @distributed { :scope > foo {}}}
  516. # [21:18] <jkomoros> ... behaves similarly, but more future-compatible
  517. # [21:18] <jkomoros> ... it's an @-rule inside of a declaration block
  518. # [21:18] <jkomoros> ... we agreed to use it in error handling rules. This would be the first other use of it
  519. # [21:19] <jkomoros> es: I like the ::distributed
  520. # [21:19] <jkomoros> sjmiles: Yeah, that one is easier to type
  521. # [21:19] <jkomoros> fantasai: what about ::distributed <space> <other stuff>?
  522. # [21:19] <jkomoros> tabatkins: problem about jumping sub-trees, not narrowing matching
  523. # [21:19] <jkomoros> ... if that's not a problem, then maybe that's fine
  524. # [21:20] <jkomoros> es: That space one requires deeper architectural change to selector matching
  525. # [21:20] <jkomoros> sorvell: I don't think the notion of limiting across selectors is something web developers know or care about
  526. # [21:20] <jkomoros> dbaron: I don't think it violates it, although ::distributed is the wrong name in this formulation
  527. # [21:20] <jkomoros> fantasai: light?
  528. # [21:20] <jkomoros> sjmiles: well, one person's light is another person's shade
  529. # [21:21] * Joins: tross (~tross@public.cloak)
  530. # [21:21] <jkomoros> es: As an implementor I don;t like it
  531. # [21:21] <jkomoros> dg: We have the same basic thing with pseudo elements already
  532. # [21:21] <jkomoros> ... we take this linked list and grab and swap it around at the end
  533. # [21:21] <fantasai> fantasai: It's just a syntactic difference; implementation can store it in whatever structures it wants
  534. # [21:21] <jkomoros> es: yeah, but this would come at the end
  535. # [21:22] <jkomoros> es; Why is this not an @ rule?
  536. # [21:22] <jkomoros> ... like @teleport
  537. # [21:22] <dbaron> I'd rather have content::back-to-light-dom > .foo { ... }
  538. # [21:22] * stearns dglazkov is speaking too quietly for the phone
  539. # [21:22] * Joins: dfreedm (~uid7859@public.cloak)
  540. # [21:22] <jkomoros> tabatkins: You don't want you to accidentally select hidden things in shadows above you
  541. # [21:23] <jkomoros> dbaron: I think that we want selectors that continue to the right of pseudo elements. And the impleemntatin model there is treat them like you treat pseudoelements today, where you match the thing to the left first, and then you
  542. # [21:23] <jkomoros> ... say , oh, pseudo element, do this other stuff
  543. # [21:23] <jkomoros> ... I think it makes sense without parens
  544. # [21:23] <singhalpriyank> s/impleemntatin/implementation
  545. # [21:23] <jkomoros> es: But selector matchign starts from right side
  546. # [21:24] <jkomoros> dbaron: not really, not with pseudo-elements. You have to start from just to the left of hte pseduo-element
  547. # [21:24] <stearns> the key is that we're combining two selectors. You can still use right-to-left evaluation on each piece
  548. # [21:24] <jkomoros> ... now we're going to allow more stuff to the right of ::, but still same model
  549. # [21:24] <jkomoros> es: why is the other thing not good as a functional syntax but this is?
  550. # [21:24] <jkomoros> dbaron: Because it's a singular thing (?)
  551. # [21:25] <jkomoros> es: The current distributed thing matches cue
  552. # [21:25] <jkomoros> dbaron: Tab doesnt want's functional syntax because nested syntax will come along in the ftuure
  553. # [21:25] <jkomoros> es: I'm not comfortable with rewriting whole selector checker
  554. # [21:25] <jkomoros> dg: You just do it when parsing rules
  555. # [21:25] <jkomoros> tabatkins: Find first pseudo element, run part before it, then ... [didn't get]
  556. # [21:25] * Joins: sorvell (~uid12099@public.cloak)
  557. # [21:26] <jkomoros> es: But it's not "at end", it's a nesting relationship. It's more complicated
  558. # [21:26] * Quits: dfreedm_ (~dfreedm@public.cloak) ("irccloud is back :)")
  559. # [21:26] <jkomoros> tabatkins: exactly like a b is not all b's just b's inside of a's
  560. # [21:26] <jkomoros> dbaron: I agree it's hard. I think we want implementation experience on concept before we commit to using it
  561. # [21:26] <jkomoros> ... but it's the same concept we've come up with in multiple places already (like overflow fragments, here, regions)
  562. # [21:26] <jkomoros> fantasai: cue?
  563. # [21:27] <jkomoros> es: cue currently works like distributed does
  564. # [21:27] <jkomoros> ... distributed is consistent with that
  565. # [21:27] <jkomoros> ... the inner selector in there is not even HTML, it's a totally different world
  566. # [21:27] <jkomoros> tabatkins: But different constraints: the document exposed is completely flat
  567. # [21:27] <jkomoros> ... whereas this will expose more complex things inside the parens
  568. # [21:27] <dbaron> It needs to be called the see-you-eee element (the "cue" element) and not the queue element (the "q" element)
  569. # [21:28] <jkomoros> dfreedm: I've hit this before. Nesting would be great
  570. # [21:28] <jkomoros> es: What people are arguing for is a "reuse this selector" ability in CSS, like a #define for selectors
  571. # [21:28] <jkomoros> dbaron: But with that, you'd end up having something with an unmatched parens in your #define,
  572. # [21:28] <jkomoros> tabatkins: yeah, that would be painful
  573. # [21:29] <jkomoros> sjmiles: Looking at the multiple {} solution, if I write that rule, I might be tempted to ask, can I put stuff to the right that is different than what's to the left? (?)
  574. # [21:29] <jkomoros> ... as a developer, it's just getting in my way. Confusing.
  575. # [21:30] <jkomoros> es: In this syntax, how do I match stuff that is a sibling of the stuff that's distributed
  576. # [21:30] <jkomoros> ... example: content::distributed(> .foo) + span {}
  577. # [21:30] <jkomoros> ... what does that do?
  578. # [21:30] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
  579. # [21:30] <jkomoros> tabatkins: That doesn't do anything in current syntax
  580. # [21:31] <jkomoros> ... given the assumptions of functional syntax, we're doing that because "only one pseudo element, and at end rule". So this is nonsense, because it comes after pseudo-element
  581. # [21:31] <jkomoros> ... but content::distributed > .foo {} is also nonsensical
  582. # [21:31] <jkomoros> dbaron: So you want a pseud-class instead of a pseudo-element?
  583. # [21:31] <jkomoros> es: I want to style the heading element that immediately follows the first heading element
  584. # [21:32] <jkomoros> tabatkins; The general use case of dropping down to jump back up (?) is a generic discussion not limited to this discussion
  585. # [21:32] <jkomoros> es: I'll reserve judgement, but I don't know what happens if you have two distributed
  586. # [21:32] <jkomoros> tabatkins: You can never ahve a double distributed, because content nodes are gone
  587. # [21:32] <jkomoros> dg: yes you can
  588. # [21:32] <fantasai> content:matches(!::distributed > .foo) + span
  589. # [21:32] <jkomoros> ... imagine that you're inside of a tree that's inside of a shadow tree
  590. # [21:33] <jkomoros> tabatkins: But as far as you can tell, you're not in a distributed tree (?)
  591. # [21:33] <jkomoros> ... content::distirbuted > .foo::region p content {} will never match anything
  592. # [21:33] <jkomoros> es: ... no?
  593. # [21:33] <jkomoros> tabatkins: remembe,r the :context selects on flattened tree
  594. # [21:34] <jkomoros> ... below you, any contents you contain you can't access content
  595. # [21:34] * Joins: cabanier (~cabanier@public.cloak)
  596. # [21:34] <jkomoros> es: That's not how it's currently specced. It's currentlys pecced that elements are distirbuted, but not that <content> is gone
  597. # [21:34] <jkomoros> tabatkins: But it doesn' matter for the purpose of this example
  598. # [21:34] <jkomoros> dg: What he's proposing works the same way as one with parens, just no parens
  599. # [21:35] <jkomoros> es: So in <an example> you could have interleaved with multiple implied parens
  600. # [21:35] <jkomoros> dg: Positive impression from CSS people around dropping parens?
  601. # [21:35] <jkomoros> ... what about people who implement?
  602. # [21:36] * Joins: sgalineau (~sgalineau@public.cloak)
  603. # [21:36] <jkomoros> dbaron: It doesn't seem easy, I think we should get implementation experience before we commit, but I think it's probably the right thing
  604. # [21:36] * divya welcomes sgalineau
  605. # [21:36] <jkomoros> tabatkins; So we leave spec as it is right now, we add notes with paren-less version, that says implement and give feedback, if it does work then we use it
  606. # [21:37] <jkomoros> ... someone has to solve these similar problems (e.g. in regions) first that leads the solution
  607. # [21:37] <stearns> I'm happy to change to this
  608. # [21:37] <jkomoros> es: So you change region, and hixie changes cue?
  609. # [21:37] <jkomoros> dbaron: cue might be a special case? it's selecting into a different document
  610. # [21:38] <jkomoros> es: I want to hear from apple
  611. # [21:38] <jkomoros> rniwa: We don't like ANY changes. ideally we wouldn't implement anything, but we'll have to implement SOMETHING
  612. # [21:38] <jkomoros> dg: I'm interested in how hayato-san feels about this
  613. # [21:38] <jkomoros> ... and see how much he screams
  614. # [21:39] * Zakim excuses himself; his presence no longer seems to be needed
  615. # [21:39] * Parts: Zakim (zakim@public.cloak) (Zakim)
  616. # [21:39] <jkomoros> eo: my rule of thumb is to let dbaron do his experiment and see what happens
  617. # [21:39] <jkomoros> ACTION: tabatkins to update the spec to the paren-less version of the :context, with a note that we will use that syntax if implementors don't scream after experimenting with implementation
  618. # [21:39] * trackbot is creating a new ACTION.
  619. # [21:39] <trackbot> Error finding 'tabatkins'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
  620. # [21:39] * RRSAgent records action 1
  621. # [21:40] * stearns fantasai: syntax isn't an issue - I pledge never to bikeshed on syntax again
  622. # [21:40] <jkomoros> es: It's defiintely implementable, it's a question if the implementation cost justifies the developer confusion benefit
  623. # [21:40] <jkomoros> dbaron: Remember, either of these solutions is hard
  624. # [21:40] * fantasai stearns, for the implementation, it's not an issue to implement one vs the other
  625. # [21:40] <jkomoros> dg: so instead of a list, it's a tree
  626. # [21:41] <jkomoros> ... so what will happen is that at parsing you'll have to be aware that when you see this pseudo-element you change what you've seen already into a tree and parse selector again
  627. # [21:41] <jkomoros> es: One of these was described in a grammar. But the current proposal can't be done in a grammar; it's context sensitive
  628. # [21:42] <jkomoros> ... so it makes it harder to implement. The parser has to be made more complex
  629. # [21:42] <fantasai> s/:context/:distributed/
  630. # [21:43] <jkomoros> (in the action above)
  631. # [21:43] * Ms2ger stearns, you should clearly bikeshed on gradients
  632. # [21:43] <jkomoros> dg: context is confusing, because it looks like content
  633. # [21:43] <jkomoros> es: what about "projection"
  634. # [21:43] <jkomoros> rniwa: THat's too complicated
  635. # [21:43] <jkomoros> dbaron: Let's get rid of context entirely
  636. # [21:43] <jkomoros> es: what about ":path"
  637. # [21:43] * Joins: slightlyoff (~uid1768@public.cloak)
  638. # [21:44] <jkomoros> dg: ":composed"
  639. # [21:44] <jkomoros> dfreedm: I prefer path
  640. # [21:44] <jkomoros> es: "has" looks closer to "matches"
  641. # [21:44] <jkomoros> sjmiles: Front end developers want everything to be as short as possible
  642. # [21:45] <jkomoros> rniwa: What about ":host" since we got rid of @host?
  643. # [21:45] <jkomoros> sjmiles: not bad
  644. # [21:45] <jkomoros> dbaron: agreed
  645. # [21:45] <jkomoros> es: But this could be arbitrary levels above
  646. # [21:46] <jkomoros> rniwa: I like ancestor
  647. # [21:46] <jkomoros> eo/sjmiles: I find it confusion
  648. # [21:46] <jkomoros> fantasai: I like host best
  649. # [21:46] <jkomoros> es: What about :inside?
  650. # [21:46] <jkomoros> sjmiles: that's the opposite of how we think about it as devleopers
  651. # [21:47] <jkomoros> rniwa: yeah, I'd expect that to be OUTSIDE
  652. # [21:47] * divya thinks everyone's hunger is speaking
  653. # [21:47] * fantasai also thinks x:o_O() x:O_o() is pretty cool :P
  654. # [21:47] <jkomoros> es: If we do distributed shenanigans, why don't we do same thing here?
  655. # [21:47] <jkomoros> dbaron: This is intentionally limited
  656. # [21:47] * stearns suggests you all get some food before you add o_0
  657. # [21:47] <dfreedm> too late
  658. # [21:47] <jkomoros> dbaron: I think we're moving to :host?
  659. # [21:48] <jkomoros> tabatkins: not bad
  660. # [21:48] <jkomoros> es: but x is the host here, and the theme is on body
  661. # [21:48] <jkomoros> es: path makes sense, like a traversal path
  662. # [21:48] <jkomoros> fantasai: What if you allowed host element to be matched in host
  663. # [21:49] <jkomoros> tabatkins: you can: :host(*)
  664. # [21:49] <jkomoros> sjmile: Is there a way to avoid me having to write "x" all the time for my placehodler
  665. # [21:49] <jkomoros> ... now we don't use the name, we just use @host
  666. # [21:49] <jkomoros> tabatkins: no need to worry about it. will only match pseudo element
  667. # [21:50] <jkomoros> es: is there a way to reference your host without explicit tag name?
  668. # [21:50] <jkomoros> tabatkins: you can: :host()
  669. # [21:50] <jkomoros> es: how does that differ from :scope
  670. # [21:50] <jkomoros> tabatkins: no, because things aren't actually scoped
  671. # [21:50] <jkomoros> ... the shadow is not actually a scoped style sheet
  672. # [21:51] <jkomoros> ... it happens to be scoped, but it isn't technically a scoped style
  673. # [21:51] <jkomoros> es: I think we should go with :host()
  674. # [21:51] <jkomoros> tabatkins: We can omit empty parens
  675. # [21:51] <jkomoros> rniwa: I like :host
  676. # [21:52] <jkomoros> proposed resolution: :host(<simple selector on ancestor path>), or :host, which is equivalent to :host(*)
  677. # [21:52] <jkomoros> fantasai: What's the specificity
  678. # [21:52] <jkomoros> tabatkins: I think we can add the specificity inside the host (?)
  679. # [21:53] <dbaron> I think s/simple selector/chain of simple selectors without combinators/
  680. # [21:53] <jkomoros> es: what about like [data-foo]:host(.dark)
  681. # [21:53] <jkomoros> RESOLUTION: :host(<chain of simple selectors without combinators on ancestor path>), or :host, which is equivalent to :host(*)
  682. # [21:54] <jkomoros> sjmiles: This is a different concept than ancestor. It has some similarity to "something that's above me"
  683. # [21:54] * hober notes that WebApps is chartered to only make decisions async, so we can't RESOLVE like the above line suggests.
  684. # [21:54] <jkomoros> ... it feels a bit weird to put what would be on the left side would be in the parens to the RIGHT
  685. # [21:55] <jkomoros> whoops, sorry strike that resolution
  686. # [21:55] <jkomoros> I misunderstood what "resolution" meant in this context
  687. # [21:55] * hober basically, you can minute that the people at the meeting agreed to something (but that agreement doesn't bind the wg in any way)
  688. # [21:56] * hober it's the opposite of the csswg
  689. # [21:56] <jkomoros> thanks for the information! I'll get the hang of this some day :-)
  690. # [21:56] * fantasai also this is not an official meeting afaik, it's just resolved within the context of this discussion
  691. # [21:56] * divya thinks no developer will ever be wasting time doing this
  692. # [21:56] * divya thinks except leaverou
  693. # [21:57] <jkomoros> sjmiles: To be clear, this syntax is fine, but ultimately developers would have wanted somethign similar: .dark goes on left, then some host, then wormhole
  694. # [21:57] <jkomoros> ... but this is fine, given all the constraints.
  695. # [21:57] <dbaron> just wait until I propose :上(.dark)
  696. # [21:58] <jkomoros> tabatkins: earlier we had a ^ combinator which said (jump boundary), but it was weird because you could have only one simple thing on the left
  697. # [21:58] * divya thinks we can have selector haikus now
  698. # [21:58] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  699. # [21:58] <dbaron> or :下(.dark)? Not sure which makes more sense.
  700. # [21:58] <jkomoros> ... I think it's easier to internalize the restrictions that things inside the parens play by different rules than the things on the left of that magic combinator
  701. # [21:59] <jkomoros> rniwa: I agree the ^ is weirder than :hsot
  702. # [21:59] <jkomoros> s/:hsot/:host/
  703. # [22:00] <Ms2ger> s/RESOLUTION:/CONCLUSION:/
  704. # [22:00] * Joins: tross_ (~tross@public.cloak)
  705. # [22:00] <Ms2ger> RRSAgent, make minutes
  706. # [22:00] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html Ms2ger
  707. # [22:00] * hober the video feed of tab's chrome window keeps toggling between sharp and awkwardly blurry
  708. # [22:00] * hober either that or i had too much coffee
  709. # [22:00] * divya is also seeing that
  710. # [22:00] * hober but i'm pretty sure it's the former
  711. # [22:01] * divya is mentally rolling eyes most dramatically
  712. # [22:01] <jkomoros> [discussion has gotten disorganized; scribe has been unable to keep up for the past 2 minutes]
  713. # [22:01] <jkomoros> fantasai: We should agree that words should either be plural or not plural
  714. # [22:01] * divya thinks jkomoros should pretend internet died
  715. # [22:01] * dfreedm declares time for food
  716. # [22:02] <fantasai> fantasai: And CSS already has 'content' in some places
  717. # [22:02] * Quits: divya (~Adium@public.cloak) ("Leaving.")
  718. # [22:03] <jkomoros> CONCLUSION: rename ::distributed to ::content
  719. # [22:03] <jkomoros> sjmiles: you don't need to have the content ahead of the ::content
  720. # [22:03] <jkomoros> fantasai: This helps people remember what it means, what concepts it's connected to
  721. # [22:04] <fantasai> (because the tag name is content -- distributed is just out of the blue)
  722. # [22:04] <jkomoros> rniwa: Ideally the developer needs to know the minimum of terrms
  723. # [22:04] <dbaron> so 'content: contents' in http://dev.w3.org/csswg/css-content/#contents0 should be 'content: content' ?
  724. # [22:04] * Quits: betravis1 (~Adium@public.cloak) ("Leaving.")
  725. # [22:04] <fantasai> either that or something else, yeah
  726. # [22:04] * Quits: tross (~tross@public.cloak) (Ping timeout: 180 seconds)
  727. # [22:05] * Quits: rniwa (~rniwa@public.cloak) (rniwa)
  728. # [22:05] <jkomoros> [lunch break]
  729. # [22:08] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  730. # [22:10] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
  731. # [22:11] * Quits: singhalpriyank (~singhalpriyank@public.cloak) (Ping timeout: 180 seconds)
  732. # [22:30] * Joins: betravis (~Adium@public.cloak)
  733. # [22:38] * Joins: marcosc (~marcosc@public.cloak)
  734. # [22:40] <jkomoros> [lunch break over]
  735. # [22:40] <jkomoros> dg: Any more CSS - related topics?
  736. # [22:40] <jkomoros> dbaron: I don't know if we agreed if custom pseudos should be functional or not?
  737. # [22:40] <jkomoros> eo: Yes
  738. # [22:41] <jkomoros> es: I think it would be said to sacrifice explanatory effect
  739. # [22:41] <jkomoros> dg: I agree with that
  740. # [22:41] <jkomoros> eo: I think it makes sense; it calls out that pseudos you come across are from a component somewhere, as opposed to from the system
  741. # [22:41] * fantasai agrees with Ted
  742. # [22:42] <jkomoros> ... there's a clarity that gets sacrificed by confusing the two
  743. # [22:42] <jkomoros> tabatkins: Even if we use no (), we still need to have a prefix (?)
  744. # [22:42] * Quits: davidb (~davidb@public.cloak) (Ping timeout: 180 seconds)
  745. # [22:42] <jkomoros> ... even the explanatory power of a non-functional syntax is still limited because custom ones would have to be named in a way that wouldn't conflict with new ones
  746. # [22:43] <jkomoros> es: Okay, I won't fight for it
  747. # [22:43] <jkomoros> dg: dbaron mentioned a solution I'm okay with
  748. # [22:43] * Joins: TabAtkins (~uid11559@public.cloak)
  749. # [22:43] <jkomoros> ... have a switch in shadow DOM spec that says that UA can define pseudos if they want
  750. # [22:44] <jkomoros> es: Long ago, the idea that in this future world all the quirks of the bedrock go away, evertyhing is components and who cares
  751. # [22:44] * Parts: TabAtkins (~uid11559@public.cloak)
  752. # [22:44] <jkomoros> ... but we're leaving warts all over the place
  753. # [22:44] <jkomoros> sjmiles: There's a tension. Sometimes it's a clarity concept, but sometimes user doesn' tneed to know
  754. # [22:44] <jkomoros> eo: In the future with lots of components, you can clearly tell when you're dealing with a part of a components
  755. # [22:45] <jkomoros> es: Why need a prefix? Why can't you implement ::placeholder
  756. # [22:45] <jkomoros> tabatkins: We want to avoid namespaces that are unchecked, so that we don't have to worry about compat checks for new keywords in the future
  757. # [22:45] <jkomoros> es: Why not expose things that are actually inside of shadow roots, why aren't they just a namespace open to anyone?
  758. # [22:45] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  759. # [22:46] * Joins: singhalpriyank (~singhalpriyank@public.cloak)
  760. # [22:46] <jkomoros> ... placeholder is specced
  761. # [22:46] <jkomoros> ... you'd need to say ::part(placeholder) (?)
  762. # [22:46] <jkomoros> eo: you wouldn't want to expose it as a shadow root; it's an implementation detail
  763. # [22:46] <jkomoros> es: But every browser implements placeholder in the same way
  764. # [22:47] <jkomoros> ... and this argument is, what if someone hypothetical browser wants to do it some other way?
  765. # [22:47] <jkomoros> dbaron: Placeholder in gecko uses native anonymous content
  766. # [22:47] <jkomoros> ... that's different from XBL, which is different from web components
  767. # [22:48] <jkomoros> es: Gecko creates divs inside of an input element, right?
  768. # [22:48] <jkomoros> dbaron: The inside of a select box is more complicated. There are things in there that have boxes but no content nodes for those boxes
  769. # [22:48] <jkomoros> ... which is different from Native Anonymous Content
  770. # [22:48] <jkomoros> ... because NAC is where we construct actual content nodes and construct boxes for those
  771. # [22:48] <jkomoros> ... for a select we just make boxes
  772. # [22:49] <jkomoros> es: I don't understand the harm in claiming that <input> uses component model
  773. # [22:49] <jkomoros> ... like, keep ::placeholder. But why not also allow the new syntax to address the same thing?
  774. # [22:49] <jkomoros> eo: Because the implementors can choose how to implement it!
  775. # [22:50] <jkomoros> dg: The question is not, whether it's implemented with Shadow DOM, but rather how it interacts with rest of content
  776. # [22:50] <jkomoros> ... so you don't have all of these weird behaviors and edge cases. It's all described by semantics of shadow DOM
  777. # [22:50] <jkomoros> dbaron: You assume shadow dom will be web compatible
  778. # [22:50] <jkomoros> dg: We have implemented almost all crazy elements uses Shadow DOM machinery
  779. # [22:51] <jkomoros> ... everything exceltp select, which we have plans to switch over as well
  780. # [22:51] <jkomoros> ... it's been for two years now that we've been using it
  781. # [22:51] <jkomoros> es: If I have input::part(placeholder) and it was a normal input, now I inherit it, I shouldn't have to change the CSS that targets it; I should just have a placeholder pseudo in my new shadow dOM
  782. # [22:51] <jkomoros> [murmurs of aggremeent from sjmiles, dg]
  783. # [22:51] <jkomoros> dg: yeah, big fan
  784. # [22:52] <jkomoros> ... part() comes from an old discussion
  785. # [22:52] <jkomoros> dbaron: There are three sorts: pseudos that are not tree like, some that are leaf like, some are tree-like and contain real emenets
  786. # [22:53] <jkomoros> ... CSS doesn't define any in the third category. But there's been discussion about various ones
  787. # [22:53] <jkomoros> es: ::first-line can't possibly be implemented as an element, for example
  788. # [22:53] <jkomoros> ... it's different from somethign that can be exposed as an API surface to style
  789. # [22:53] <singhalpriyank> s/emenets/elements/
  790. # [22:53] <jkomoros> dfreedman: I don't understand why it has to be different
  791. # [22:53] <jkomoros> eo: part() takes an author-defined dient
  792. # [22:53] <jkomoros> s/dient/ident/
  793. # [22:53] * Quits: tobie (tobie@public.cloak)
  794. # [22:54] <jkomoros> sjmiles: I think it's a strong point: this is a specific kind of styling we're doing here--it's a node. It's the same for web components and implemented pieces
  795. # [22:54] <jkomoros> ... it seems this makes sense. It makes sense that ::first-line is different
  796. # [22:54] <jkomoros> dg: it's hard to explain ::backdrop in terms of these primitives
  797. # [22:54] <jkomoros> ... so that would stay the same
  798. # [22:55] <jkomoros> es: like there are some things that are clearly defined by what's inside
  799. # [22:55] <jkomoros> ... like scrollbars
  800. # [22:55] <jkomoros> eo: I disagree about scrollbars
  801. # [22:55] <jkomoros> dbaron: We plan to get rid of all internals to scrollbars
  802. # [22:55] <jkomoros> es: What kinds of scrollbars would you not want to build in the div
  803. # [22:55] <jkomoros> rniwa: That's for the scrollbars that have been released to date; in the future they might not
  804. # [22:56] <jkomoros> eo: Currently in WebKit if you use legacy pseudos for scrollbars, you go to legacy scrollbar mode. If you don't, then you get the special new ones
  805. # [22:56] <jkomoros> es: What I'm saying is that if you don't want the API surface, don't expose it. In this case, it's already been exposed
  806. # [22:57] <jkomoros> sjmiles: I think it's reasonable to say, for this thing, the way we implement it we shouldn't reveal it
  807. # [22:57] <jkomoros> eo: I want to make a distinction between UA-implemented things, and things built in WC world. We want that distinction
  808. # [22:57] <jkomoros> es: But why? If the standard says ::placeholder, it cannot be removed entirely
  809. # [22:57] <jkomoros> ... so for new ones, it should use part() so that others can override later. But if it's not exposed, doesn't matter
  810. # [22:58] <jkomoros> dg: it gives a clear message to author of how to reason about it--it's just like Shadow DOM.
  811. # [22:58] <jkomoros> ... the UA is acting as an author in those cases where the guts are exposed like this
  812. # [22:58] * Quits: jeffh (~266f978c@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  813. # [22:58] <jkomoros> rniwa: We don't want to be adding APIs that limit the ways in which we can tweak UIs
  814. # [22:59] <jkomoros> dg: agreed. I don't think it matters. ::placeholder behaves like it's implemented as Shadow DOM. So it should behave htat way fully
  815. # [22:59] <jkomoros> eo: The entire existing platform prior to the feature means that user-land psueods and UA pseudos are different
  816. # [22:59] <jkomoros> es: today in WebKit, ::-webkit-spin-button IS a div today. That's an API surface
  817. # [22:59] <singhalpriyank> s/htat/that/
  818. # [23:00] <jkomoros> ... right now it has a prefix
  819. # [23:00] <jkomoros> ... but if a spec adds a non-prefixed api surface, it's now a real API surface and it should behave like the other non-magic things
  820. # [23:00] <jkomoros> eo: as an author, I want to be able to send a bug report to the right person
  821. # [23:01] <jkomoros> dbaron: Authors aren't the users. End users are the user. Web platforms are designed for both of those constiunenciies. Sometimes you don't want to give control
  822. # [23:01] <jkomoros> es: But we're talking about, for things that ARE already exposed
  823. # [23:01] <jkomoros> dbaron: Some of the motivation for it, is there's stuff that might be the same now, but we don't want to be stuck with it forever
  824. # [23:01] <jkomoros> eo: we're stuck with legacy scrollbar contrrols forever. :-(
  825. # [23:02] <jkomoros> dbaron: mobile use cases are a great example. I'm glad we didn't commit to select's having a dropdown button
  826. # [23:02] <jkomoros> ... I think you're being conservative about what to expose
  827. # [23:02] <jkomoros> es: You seem to be arguing that ::placeholder was a mistake and we should remove immediately?
  828. # [23:02] <jkomoros> dbaron: I think freezing everything about form controls at this moment is a bad thing.
  829. # [23:03] <jkomoros> dg: I think we're talking about two different things
  830. # [23:03] <jkomoros> sjmiles: UAs should be able to choose what to expose. But, IF you have chosen what to expose, like ::placeholder, then what you expose is Shadow DOM
  831. # [23:04] <jkomoros> dg: ::placeholder already behaves, as specced today, as a custom pseudo-element
  832. # [23:04] <jkomoros> ... as if it was a custom pseudo-element
  833. # [23:04] <jkomoros> rniwa: Spec doesn't say that ::placeholder needs to be text inside a Shadow DOM. Just that color and whatever can be controlled
  834. # [23:04] * Joins: lmclister (~lmclister@public.cloak)
  835. # [23:04] <jkomoros> ... this allows UAs to match the convention of the platform
  836. # [23:05] <jkomoros> rniwa: placeholder is okay, but in case of like scrollbars, we have to show legacy scroll bars even on platforms that have other scrollbars --it's confusing ot users
  837. # [23:05] <jkomoros> es: I don't care so much about scroll bars; mozilla doesn't want to implement them
  838. # [23:05] <jkomoros> ... I'm saying when it's a standardized API surface, it should be exposed with Shadow DOM
  839. # [23:06] <jkomoros> eo: take input type=password
  840. # [23:06] <jkomoros> ... users before authors, etc
  841. # [23:06] <jkomoros> ... it would be reasonable for an impelemnter to say that user type=password cannot be overriden by components
  842. # [23:06] <jkomoros> es: that's fine, the standard should say that for those cases
  843. # [23:06] <jkomoros> dbaron: I think there's another answer to this requirement
  844. # [23:07] <jkomoros> ... your requirement is about re-impelmenting existing parts of the platform
  845. # [23:07] <jkomoros> ... I'm okay with the component model having a way to match an existing part of the web platform
  846. # [23:07] <jkomoros> ... that's different from saying that you can extend the pseudo-element space arbitrarily
  847. # [23:08] <jkomoros> es: To clarify, I'm arguing we should do ::part(). And that we should fix the platform to fit this
  848. # [23:08] * Joins: karl (~karlcow@public.cloak)
  849. # [23:08] <jkomoros> eo: Dbaron is saying that I want to impelement a new component and react to ::placeholder. Because it's an existing platform feature, you should have a way to say, this thing is my ::placeholder
  850. # [23:08] <jkomoros> ... and then if you add a new pseudo, it goes in the box where user-land new pseudos go
  851. # [23:09] <jkomoros> sjmiles: Eliot's proposal does everything yours says, but simpler, from our perspective
  852. # [23:09] <jkomoros> es: We all seem to be talking from different contexts
  853. # [23:09] <jkomoros> sjmiles: I think we're closer than we think we are
  854. # [23:09] <jkomoros> dbaron: eliot wants ::part(placeholder) to react to all the same thigns that ::placeholder does. I think they should be two different name spadces, and Shadow DOM should be able to get to both of them
  855. # [23:10] <jkomoros> sjmiles: But you're telling Bob Web Developer that in case A you use this syntax, but in case B use a different one. But there's no difference
  856. # [23:10] <jkomoros> ... why does it matter what comes from UA and what comes from a component?
  857. # [23:10] <jkomoros> rniwa: That is an API surface. It's a namespace issue
  858. # [23:11] <jkomoros> es: It doesn't matter if you don't reproject
  859. # [23:11] <jkomoros> dbaron: the reason I don't like them being the same, that goes back to the assumption you'd implement all of the platform in Shadow DOM
  860. # [23:11] * Quits: tross_ (~tross@public.cloak) (Ping timeout: 180 seconds)
  861. # [23:11] <jkomoros> sjmiles: I think rniwa has a good point about namespaces
  862. # [23:11] <jkomoros> *namespace
  863. # [23:12] <jkomoros> rniwa: We could have collisions with new formalized pseudos if they share the same namespace
  864. # [23:13] <jkomoros> es: ::part(placeholder) is exactly like a method that gets stomped on by some new web platform feature adding a new method to a type of node
  865. # [23:13] <jkomoros> ... those types of collisions happen all the time.
  866. # [23:13] <jkomoros> es: You're trying to protect yourself from one, particular type of namespace collision. THere are lots of them!
  867. # [23:14] <jkomoros> dbaron: There's a different error-handling rule for pseudos, and WebKit implemented something else, and didn't come back to the standards groups
  868. # [23:14] <jkomoros> ... now you come back and say you want to build a new feature on top of that broken feature
  869. # [23:14] <jkomoros> es: We agreed on that part--we should move to ::part(placeholder)
  870. # [23:14] <jkomoros> ... isn't this like saying, custom elements are bad idea
  871. # [23:14] <jkomoros> eo: yes! I think you should only do it if it's a good idea
  872. # [23:15] <jkomoros> dfreedman: but how do you know in advance if htey'll have a good reason?
  873. # [23:15] <jkomoros> s/idea/reason/
  874. # [23:15] <singhalpriyank> s/htey'll/they'll/
  875. # [23:15] <jkomoros> es: I'm saying, all platform widgets, however they're implemented (jquery, etc) they should have the same API surface
  876. # [23:15] <jkomoros> ... not if you use Shadow DOM surface.
  877. # [23:15] <jkomoros> dfreedman: part(oplaceholder) just describes the same thing as ::placeholder
  878. # [23:16] <jkomoros> dg: eo is saying htat part defines user-defined pseudos
  879. # [23:16] <jkomoros> dbaron: I think I'm okay with either formulation (?)
  880. # [23:16] <jkomoros> rniwa: think about for example, translation attribute
  881. # [23:16] <jkomoros> ... we shipped and broke a lot of libraries in india
  882. # [23:16] <jkomoros> eo: We have compat constraints we need to take into account
  883. # [23:17] <jkomoros> rniwa: We want to avoid breaking existing websites
  884. # [23:17] <jkomoros> es: If we go there, and say part is magical only userland, and every pseudo in user space should start with data- so you don't conflict
  885. # [23:17] <jkomoros> ... so you're saying that every method in say polymer has to be polymer_foo()
  886. # [23:17] <jkomoros> sjmiles: We tried somethign at the beginning, where we presented a different public face. Developer users HATED it
  887. # [23:17] <jkomoros> ... developers want more power AND backwards compatibility. It's hard.
  888. # [23:18] <jkomoros> rniwa: MediaWiki added a special style attribute to work around WebKit bug
  889. # [23:18] <jkomoros> ... we fixed it, but now we can't remove it because mediawiki content is deployed with the old stuff
  890. # [23:19] <jkomoros> eo: Quickly: this is the same argument from last F2F: the idea if we should allow custom element names over the wire
  891. # [23:19] <jkomoros> ... is=foo nicely delineates which is user land
  892. # [23:19] * Joins: tross (~tross@public.cloak)
  893. # [23:19] <jkomoros> dg: it's solved with the - requirement
  894. # [23:19] <jkomoros> rniwa: I'm less concerned if authors can only extend HTMLEleement
  895. # [23:20] <jkomoros> es: Either developers are responsible for avoiding namespace collisions everywhere, or nowhere
  896. # [23:20] <singhalpriyank> s/HTMLEleement/HTMLElement/
  897. # [23:20] <jkomoros> sjmiles: Seems like everyone agrees the ::part() is a good idea in many cases
  898. # [23:20] <jkomoros> CONCLUSION: ::part() is a good solution for user-land pseudo elements
  899. # [23:21] <jkomoros> ... although the group doesn't necessarily agree about existing pseudo elements at this point
  900. # [23:21] <jkomoros> dg: ::Part and ::pseudo is fine (?)
  901. # [23:21] <dbaron> (by either formulation -- one formulation is that ::pseudo and ::part(foo) are just two different namespaces, shadow DOM can't extend the first namespace, but it can create things that match either -- the other formulation is that ::part(foo) is an extensible namespace and future Web features that could be represented as such a part (whether or not they are implemented in terms of shadow DOM) plus ::placeholder should have such parts done as ::part(foo), an
  902. # [23:21] <dbaron> d that ::part(placeholder) should be an alias for ::placeholder for consistency
  903. # [23:21] <dbaron> )
  904. # [23:21] * Joins: divya (~Adium@public.cloak)
  905. # [23:22] <jkomoros> CONCLUSION: the attribute to register these custom pseudos is "part" (not pseudo as it currently is in spec)
  906. # [23:23] * Quits: divya (~Adium@public.cloak) ("Leaving.")
  907. # [23:24] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  908. # [23:24] <jkomoros> The CSS portion of this discussion is over. We'll stop taking notes h ere
  909. # [23:26] * Quits: tross (~tross@public.cloak) ("Page closed")
  910. # [23:30] * Quits: singhalpriyank (~singhalpriyank@public.cloak) ("Page closed")
  911. # [23:33] * Joins: marcosc (~marcosc@public.cloak)
  912. # [23:35] * Quits: jkomoros (~jkomoros@public.cloak) (Ping timeout: 180 seconds)
  913. # [23:40] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  914. # [23:41] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  915. # [23:58] * Joins: jeffh (~266f9799@public.cloak)
  916. # Session Close: Sat Jun 22 00:00:00 2013

The end :)