- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 25 Jun 2013 07:27:20 -0400
- To: public-webapps@w3.org
On 6/24/13 9:44 AM, ext Arthur Barstow wrote:
> Hi All,
>
> The minutes from the June 21 Web Components meeting [Agenda] are
> available at the following and copied below:
>
> <http://www.w3.org/2013/06/21-webapps-minutes.html>
The minutes were not complete when I announced them yesterday but that
issue has been fixed and the complete minutes are copied below.
-AB
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WebApps' Web Components f2f Meeting
21 Jun 2013
[2]Agenda
[2] http://www.w3.org/wiki/Webapps/WebComponentsJune2013Meeting
See also: [3]IRC log
[3] http://www.w3.org/2013/06/21-webapps-irc
Attendees
Present
Edward_OConnor, Ryosuke_Niwa, Bear_Travis, Divya_Manian,
Alex_Komoroske, David_Baron, Priyank_Singhal,
Steve_Orvell, Daniel_Freedman, Dimitri_Glazkov,
Elliott_Sprehn, Scott_Miles, Tab_Atkins
Regrets
Chair
Dimitri
Scribe
Alex
Contents
* [4]Topics
1. [5]Quick Overview of Shadow DOM concepts
* [6]Summary of Action Items
__________________________________________________________
<jkomoros> ScribeNick: jkomoros
<ArtB> ScribeNick: jkomoros
<ArtB> Scribe: Alex
<scribe> Chair: Dimitri_Glazkov
<scribe> Meeting: Styling Issues in Shadow DOM and CSS
Quick Overview of Shadow DOM concepts
<divya> i think we need cofffee
DG: Hoping that the main focus of this meeting will be
primarily arounds CSS + Shadow DOM
... we had one original idea, but developers trying to use it
gave feedback that it wasn't exactly the right "knobs"
... there are people here who are "Browser Vendors", and there
are people who are the "web developers"
... a bunch of folks in the latter group here are from Polymer,
Daniel Buchner (who should join at some point) represents
x-tags
... and then spec folks, fantasai and tabatkins
... who aren't here yet.
dbaron: Blake Kaplan and William Chen (?) have been working on
Shadow DOM at Mozilla
... and I've been talking with them
[by the way, we all took a coffee break]
[break over]
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
<rniwa> wasn't there explainer somewhere?
DG: this existed in many different systems before. It allows
composability (one tree vs multiple)
<rniwa> is
[7]https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/e
xplainer/index.html still up to date?
[7] https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html
DG: if I can replace the rendering of a node, what happens to
its children?
<slightlyoff> rniwa: or, also:
[8]http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
[8] http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
DG: the general overview gets trickier and trickier, but we
have converged on a solution in today's Shadow DOM spec
[dglazkov draws a diagram on the board]
<rniwa> Also see:
[9]https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/e
xplainer/
[9] https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/
scribe: every node that has children, you can associate (off to
the right) with a shadowRoot: a DocumentFragment with extra
stuff in it
<slightlyoff> rniwa: this loads for me:
[10]https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/
explainer/index.html
[10] https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html
scribe: extra stuff is effectively a subclass of
DocumentFragment. Things like getElementByID, querySelector.
Stuff that has migrated into Document mainly anyway
dbaron: So those just query what's in the Shadow DOM?
<rniwa> slightlyoff: oh oops, yeah. i guess it doesn't have an
ordinary index.html > / rewrite :/
DG: think of the line connecting ShadowRoot is not a normal
connection--it's a separate tree
... insertion points can be any elements inside the tree.
They're called <content>
... we use a rhombus for insertion points
... <content> name comes from XBL2
... you can have more than 1 content
... content can have a select attribute, which takes a narrow
subset of CSS selctors
... that match against children of the parent node.
... currently limited to ID, tagname, attributes, and class
... no combinators.
... that's the conceptual model. But actually a node can have
MULTIPLE shadow roots
... the method on the ndoe is "createShadowRoot"
... there's an ordering.
... Sometimes the element already has a shadowtree (like
InputElement or TextArea)
... they're basically the same as how the native implementation
might be done
... 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
... there's a concept of older and younger shadow tree
... youngest one is the one that gets rendered
... soemtimes you want to use parts of the older shadow tree
... which is why there's an insertion point called <shadow>
... when you put it in a shadow root, it will show whatever
what is the older shadow root
... it allows the youngest guy to channel the older guy
... explicit children can only go to one insertion point.
... there's an idea conceived by Jan on the polymer-dev list,
the shadow acting as a function (?)
... but as of now, there is an order, only selected once
... this allows developers to take existing elements, and adorn
them with existing stuff from older shadow trees
... if there's nothing in the older shadow tree, it works as
the last content element--whatever hasn't
... been distributed
... whole point of Shadow DOM spec is distributed. That's the
majority of the spec
... how are they distributed, what's the effect
... things like focus, events, and rendering/sytling
... the latter is what I want to talk abou ttoday
... the others we have figured out mostly
dbaron: I was involved in the XBL RCC thing in 2004 (?) so
these concepts are not all new to me
DG: now we get into style
... this is where things get interesting
<dbaron> (also XBL1 :-)
DG: if the shadow root is a document fragment, what does that
mean from styling perspective?
... if I'm distributing a text node into a content element,
what is its style?
rniwa: What does the current spec say about style?
[I missed about 30 seconds :-( ]
dbaron: I think it's worth separting selector matching and
inheritance
[esprehn draws a diagram on the board]
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
... so you get styles from where you came from, and styles
where you're going
... there's a way to reset styles at shadow boundary
<divya> [11]http://s3.amazonaws.com/Gyazo/1371838156.png
[11] http://s3.amazonaws.com/Gyazo/1371838156.png
es: when the tree gets flattened out, conceptually it gets
flattened out
[es draws the "composed" result on the board for clarity]
scribe: we use "composed" tree to mean, the thing with all of
the things teleported
... don't use "flattened" tree
dg: Although at some point we might, depending on if there's
mutiple trees
rniwa: If you have a style in the distributed content, that
follows hierarchy in original content
... and merge in with shadow styles
... I'm not sure that even in an complex widget that makes
sense
... things get really wonky
sorvell: It's just inherited styles that work this way
es: One special case si that if you have a style element inside
of the shadow root, it's automatically scoped to the shadow
root
dbaron: So the selectors in the scoped style only match things
in the shadow tree, NOT stuff that gets "teleported" there
sorvell: This is one part of the spec as a developer that makes
total sense
... allows you to worry just about this shadow root. it works
really well in practice
sjmiles: Occasionally you have to pierce through that barrier,
that's when it gets harder
<divya> [12]http://s3.amazonaws.com/Gyazo/1371838492.png
[12] http://s3.amazonaws.com/Gyazo/1371838492.png
sjmiles: as a practical matter WE haven't run into that problem
... (confused styles)
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?
... is there a way to say that, in that case, the span shoul
dinherit font size but not color
sjmiles: no, it's all or nothing
... (basically)
... we haven't run into that need in practice y et
... that's based on empirical data with n points, where n is a
relatively small number in the grand scheme of things
... it's possible at some point in the future someone will need
it, but we don't now
dg: let's enumerate the cool styling hooks that we have today,
then figure out which ones are missing
... 1) Style scoped.
... it's acgtually a close cousin of shadowRoot. It's very
similar scoping behavior
... but it's a scoping NODE, and style scoped is a scoping
ELEMENT
... but they have similar abilities, except none of the styles
from the document (outside the SR) don't apply down.
... style scoped in isolation, essentially
dbaron: So nothing from the author style sheets don't match SR.
But still UA styles
DG: we have applyAuthorSTyles
... that allows the component to explicitly allow outside
styles out to come inside
... user styles are treated like Author styles
eo: It's problematic that user styles by default get blocked
dg: Actually, we don't know what we do here, we need to check
tabatkins: It's reasonabl eto say, yeah, User styles apply by
default
dbaron: How selector matching works is intersting
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
... it's actually not. The selector matching can either be
fully in the host, or in the SR
[I think I got that right?]
scribe: so in this example, div > div will not match
... but if you just do `div` and have applyAuthorStyles it will
match both divs
sjmiles: If I put div class=foo, and foo is defined in
document, it won't see that
... as a user I go, applyAuthorStyles will make it work, but it
won't
dg: No, that will work
es; BAsically, the selector must COMPLETELY Match outside, or
completely inside. There's no boundary crossing
eo: What about a boundary crossing combinator?
<dbaron> db: yeah
dg: That's what we want to talk about today: :-)
... There's another flag on SR that says resetStyleInheritance
... it's very powerful
... everything inside of the SR, when you flip to true, it will
look like it's initial styling
dbaron: Kind of like you had a parent in between all:initial
dg: similar thing exists on insertion points
... so that you can have the styles in SR not go into the
composed children
... that's all the styling machinery (minus any
boundary-piercing things)
... but this isn't enough. how do you make the subtrees
intreact with doc?
... similarly, sorvell wants to be able to style inside the
shadow tree, style the composed children as well
... like say in a tab strip, styling the active children
... you want to be able to let SOME stuff in from SR in from
document, and also in
... similar for content
dbaron: The XBL solution to that is that you have a separate
binding for active tab that is different, point to that instead
dg: We didn't want the content of the host to not know what's
happening to it (?)
... we had two solutions, both of which have strengths and
weaknesses
... 1) let CSS Variables bleed through the SR boundary. So you
could specify a CSS variable in doc, and catch it inside the SR
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)
dbaron: i don't like describing inheritance blocking as all
property
fantasai: You probably do want the ability to jump inheritance
over the shadows
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
tabatkins; that turns out to be extremely popular for writing
components in the real world
scribe: like components in jquery have to go through and
manually reset everything
... they want consistent, predictable starting point--even if
they allow poking in after that
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
tabatkins: That's why it's a flag. Component authors can decide
if it works
es: Actually, default is to allowing
sjmiles: So if you turn it off, the component author did it on
purpose
dbaron: So in the cases 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
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 particular no matter
where it is
... like the G+ share widget, as an example, that wants to have
complete control over exactly what's inside it
sjmiles: db makes a good point
tabatkins: wihtin the shadow, if you want to block it only in
some places, the 'all' property exists
sjmiles: Or make a component for just the parts where you want
to reset it
sorvell: We don't use resetting much in practice, it's such a
blunt tool
... generally we want to control a small number of properties
rniwa: In disqus use case, you want to be able to read the
background color of surrounding, but decide how to interpet
that
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'
es: LIke in a facebook button as an example, you want to force
the font, but don't care about the size of it
dg: Let's keep going with explaining the tools
... those variables are cool but not enough
... we see this alot with WebKit's internal input elements
... you want access to a sepcific element to style arbitrarily
... leads to:
... 2) Custom pseudo elements
... you define a pseudo attribute on an element
... then you can use it with standard ::foo syntax in selectors
... so like <outer-element>::x-foo
dbaron: Like functionality, but want a function
eo: agreed
dg: Agreed, at the time when we proposed this dave hyatt didn't
want it to be a functional syntax, but we can revisit
es: ONe of the goals of the project is to explain lower-level
magic
eo: I don't agree with that goal, for what it's worth
es: If we swithc to functional syntax, we miss out on
explaining the ::foo magic
rniwa: We could change the syntax for pseudos like that if we
want, only blink and webkit do this
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
... I'm SLIGHTLY sympathetic to wanting to explain the magic.
But some of them are things we really don't want to freeze
... 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
... because the web would have depended on fixed structures
that work on destop, but don't make sense on mobile devices
dg: There is a larger debate here. I want to table that for
now. Keep it in mind today, but avoid engaging today
eo: We'll only be able to make so much progress without it
dg: So even with this second knob, it doesn't complete all of
the use cases from developers
<dbaron> (I think he used "put it aside" rather than "table"
(which is en-GB/en-US ambiguous).)
dg: now I'm crossing threshold to the boundary-crossing thing
... I'll first describe things they way they WERE/ARE
divya: What do you mean by "functional syntax"?
dg: things like ::shadow(foo)
dbaron: the advantage is, there's a rule in selector spec that
says rules UA doesn't understand get dropped
... pseudo elements/classes are part of that rule. WebKit/Blink
don't do that correctly
... all other browsers drop the entire rule, but WebKit/Blink
retains those
es: That was willful; we can fix it
tabatkins: But peopel do use it today already :-(
dg: In querySelector, incidetnally, we don't violate spec
... onto the new things that we're thinking of
... in order to select things that are distirbuted into an
insertion point, we invested the distirbuted pseudo element
function
...: :distributed(---------)
... where ----- allows combinators
... on an insertion point, inside of a SR, it matches the
element that was distributed into that matches the inner
selector in the function
es: example: content::distributed(span) { border: ________ }
... in the example we diagrammed, that style that earlier
didn't match, now matches
tabatkins: Remember, this is current junky stuff that we don't
like
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
sorvell: It's relative
dg: It's relative to the virtual node that represents the thing
that envelopes all distributed elements
sorvell: use case: i want to style all children, not all
descendants
... so you can do like content::distributed( > span)
es: It's like find() on content
dbaron: I don't know if I like leading cominbators yet
fantasai: I have reservations, but I think at this point we
have to go with it, everyone expects it to work that way
tabatkins: jquery uses it for years, and now it's documented in
selectors level 4. It's a small section
dbaron: leading combinators only work when there's an implicit
node being targeted to
sjmiles: This is very necessary in our experience
divya: Can I have a class on the content element and use that
in the selector?
dg: yes
es: Although content element itself is NOT stylable
... which I don't like. I wish that I could style the content
to, say, display:none it
... currently it has no effect
... it's bizarre
dg: I agree
<stearns> +1 to styling content nodes
dg: I would like to explain content as a display:contents
es: In the current model, it's easy to distribute two things,
but if you want to hide it, you need ANOTHER wrapper
... styles targeted at <content> don't inherit down; it's
unstylable, no rendernode
fantasai: If it's an intermediary, it makes for example uls and
lis nested not work
dg: I hope we can solve it by having <content> have
display:contents on it
fantasai: but that doesn't address the ul/li use case
<fantasai> also mentioned :nth-child
<fantasai> ul/li shouldn't be a problem
dg: let's talk about @host
<fantasai> otherwise
dg: we want to get rid of this
... when you put a SR inside a tree, I want to be able to apply
borders on the component, for example
... works like @host { [selector] { border: 1px solid red }}
... the inner selector matches only host
dbaron: and what would antyhing other than *
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 *)
tabatkins: And because of is attribute, you could have one
component with different tag-names
dbaron: So @host lets the SR influence the containing box
... I think that in XBL1 we replace the outer box, but I might
be misremembering
dg: This is the entire family of styling stuff. Now we want to
get rid of many of these
<fantasai> side discussion of pseudo-element syntax, vs .
combinators vs. @rule
<fantasai> ::distributed() matches pattern of ::cue() and
::region(), seems we're alinging on that
<fantasai> ScribeNick: fantasai
dg: @host did not solve the body class=light, and have
components be able to see that
sjmiles: ANd we never used this @host { * {}}
fantasai: You probably want ::shadow, ::light, and ::context
(to reach out)
dbaron: or a combinator to jump out
fantasai: Issue with a combinator is that it breaks the rule
where combinators limit the matched set as you go
... so if you did bar <magic cobminator> foo, suddenly you're
selecting a different set of foos
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
... which is adding restrictions, right?
... in the dark theme use case
tabatkins: yeah, that works with combinator
... eventually we rejected that idea
[tab opens a Google Doc to show this idea off. He will share a
link here]
[we will share the doc later]
docs.google.com/document/d/19fpRugyOO8kZfVVfdN1vkorwv8rmKztfNOE
VLzIU2pU/edit?usp=sharing
scribe: does that work?
... no :-(
tabatkins: host element and shadow have equal claim
... we need to pretend the hos telement is in the root of the
shadow tree
... so i fyou want to select on it, all you do is [writes in
doc]
... this example will target the host element outside
[13]http://tinyurl.com/mueleah
[13] http://tinyurl.com/mueleah
^ that link works
s/selecors/selectors/
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
... but you don't want to allow arbitrary selecors above
<jkomoros> can you see this?
<dbaron> ScribeNick: jkomoros
<singhalpriyank> yes
tabatkins: If you have the outer document followed by a shadow
element, and inside of that another component
... the outer document you would see includes the shadow tree
of the outer component.
... that breaks encapsulation, allows developers to depend on
details of components outside
... we still need a communication channel to outside
... we think we have a simple thing that satisfies use csaes
... here's an example. The context pseudo class is placed on
the root element (hsot element)
... it matches if something in the compound selector matches in
the fully composed ancestor list (?)
... including stuff in other boundaries
... because maybe you're applying a theme inside of one of the
parent components above
... it allows some information to be piped through, but not
enough to allow a fragile dependency (we hope)
... the list of elements checked starts with host element
itself, goes up to the root, through any of the composed shadow
trees
... that's the only way to select up outside
... going the other way, we still use ::distributed
... works the same way
... we think this solves all the use cases we know of
... and it's convenient and easy ,not the contorted tree
hopping of @host and everything else
dbaron: What is removed?
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)
rniwa: So if you have multiple composed layers, it selects each
composited layer (?)
tabatkins: no, the fully flattened tree up above
... you do see the shadow dom of things up the tree... but not
very much
... so at any point you can inject information in
rniwa: So a shadow DOM A, inside sahdow dom B
tabatkins: we haven't changed the way normal selectors work. In
a shadow style sheet, still only match within that shadow tree
... 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)
... the problem is this distributed pseudo class isn't
compatible with any nesting mechanisms we might add in future
... like, if you had foo bar baz {} as foo { @nest bar baz {
... }} , the distributed pseudo class wouldn't let you do the
nested selectors
... same problem applies to regions, because regions often have
complex selectors inside of the regions
... a possible aternate syntax is to have content selected and
inside have a @distributed rule that takes ...
... content { @distributed { :scope > foo {}}}
... behaves similarly, but more future-compatible
... it's an @-rule inside of a declaration block
... we agreed to use it in error handling rules. This would be
the first other use of it
es: I like the ::distributed
sjmiles: Yeah, that one is easier to type
fantasai: what about ::distributed <space> <other stuff>?
tabatkins: problem about jumping sub-trees, not narrowing
matching
... if that's not a problem, then maybe that's fine
es: That space one requires deeper architectural change to
selector matching
sorvell: I don't think the notion of limiting across selectors
is something web developers know or care about
dbaron: I don't think it violates it, although ::distributed is
the wrong name in this formulation
fantasai: light?
sjmiles: well, one person's light is another person's shade
es: As an implementor I don;t like it
dg: We have the same basic thing with pseudo elements already
... we take this linked list and grab and swap it around at the
end
<fantasai> fantasai: It's just a syntactic difference;
implementation can store it in whatever structures it wants
es: yeah, but this would come at the end
es; Why is this not an @ rule?
scribe: like @teleport
<dbaron> I'd rather have content::back-to-light-dom > .foo {
... }
tabatkins: You don't want you to accidentally select hidden
things in shadows above you
dbaron: I think that we want selectors that continue to the
right of pseudo elements. And the implementation model there is
treat them like you treat pseudoelements today, where you match
the thing to the left first, and then you
... say , oh, pseudo element, do this other stuff
... I think it makes sense without parens
es: But selector matchign starts from right side
dbaron: not really, not with pseudo-elements. You have to start
from just to the left of hte pseduo-element
<stearns> the key is that we're combining two selectors. You
can still use right-to-left evaluation on each piece
dbaron: now we're going to allow more stuff to the right of ::,
but still same model
es: why is the other thing not good as a functional syntax but
this is?
dbaron: Because it's a singular thing (?)
es: The current distributed thing matches cue
dbaron: Tab doesnt want's functional syntax because nested
syntax will come along in the ftuure
es: I'm not comfortable with rewriting whole selector checker
dg: You just do it when parsing rules
tabatkins: Find first pseudo element, run part before it, then
... [didn't get]
es: But it's not "at end", it's a nesting relationship. It's
more complicated
tabatkins: exactly like a b is not all b's just b's inside of
a's
dbaron: I agree it's hard. I think we want implementation
experience on concept before we commit to using it
... but it's the same concept we've come up with in multiple
places already (like overflow fragments, here, regions)
fantasai: cue?
es: cue currently works like distributed does
... distributed is consistent with that
... the inner selector in there is not even HTML, it's a
totally different world
tabatkins: But different constraints: the document exposed is
completely flat
... whereas this will expose more complex things inside the
parens
<dbaron> It needs to be called the see-you-eee element (the
"cue" element) and not the queue element (the "q" element)
dfreedm: I've hit this before. Nesting would be great
es: What people are arguing for is a "reuse this selector"
ability in CSS, like a #define for selectors
dbaron: But with that, you'd end up having something with an
unmatched parens in your #define,
tabatkins: yeah, that would be painful
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? (?)
... as a developer, it's just getting in my way. Confusing.
es: In this syntax, how do I match stuff that is a sibling of
the stuff that's distributed
... example: content::distributed(> .foo) + span {}
... what does that do?
tabatkins: That doesn't do anything in current syntax
... 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
... but content::distributed > .foo {} is also nonsensical
dbaron: So you want a pseud-class instead of a pseudo-element?
es: I want to style the heading element that immediately
follows the first heading element
tabatkins; The general use case of dropping down to jump back
up (?) is a generic discussion not limited to this discussion
es: I'll reserve judgement, but I don't know what happens if
you have two distributed
tabatkins: You can never ahve a double distributed, because
content nodes are gone
dg: yes you can
<fantasai> content:matches(!::distributed > .foo) + span
dg: imagine that you're inside of a tree that's inside of a
shadow tree
tabatkins: But as far as you can tell, you're not in a
distributed tree (?)
... content::distirbuted > .foo::region p content {} will never
match anything
es: ... no?
tabatkins: remembe,r the :context selects on flattened tree
... below you, any contents you contain you can't access
content
es: That's not how it's currently specced. It's currentlys
pecced that elements are distirbuted, but not that <content> is
gone
tabatkins: But it doesn' matter for the purpose of this example
dg: What he's proposing works the same way as one with parens,
just no parens
es: So in <an example> you could have interleaved with multiple
implied parens
dg: Positive impression from CSS people around dropping parens?
... what about people who implement?
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
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
scribe: someone has to solve these similar problems (e.g. in
regions) first that leads the solution
<stearns> I'm happy to change to this
es: So you change region, and hixie changes cue?
dbaron: cue might be a special case? it's selecting into a
different document
es: I want to hear from apple
rniwa: We don't like ANY changes. ideally we wouldn't implement
anything, but we'll have to implement SOMETHING
dg: I'm interested in how hayato-san feels about this
... and see how much he screams
eo: my rule of thumb is to let dbaron do his experiment and see
what happens
<scribe> ACTION: tabatkins to update the spec to the paren-less
version of the :distributed, with a note that we will use that
syntax if implementors don't scream after experimenting with
implementation [recorded in
[14]http://www.w3.org/2013/06/21-webapps-minutes.html#action01]
<trackbot> Error finding 'tabatkins'. You can review and
register nicknames at
<[15]http://www.w3.org/2008/webapps/track/users>.
[15] http://www.w3.org/2008/webapps/track/users>.
es: It's defiintely implementable, it's a question if the
implementation cost justifies the developer confusion benefit
dbaron: Remember, either of these solutions is hard
dg: so instead of a list, it's a tree
... 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
es: One of these was described in a grammar. But the current
proposal can't be done in a grammar; it's context sensitive
... so it makes it harder to implement. The parser has to be
made more complex
(in the action above)
dg: context is confusing, because it looks like content
es: what about "projection"
rniwa: THat's too complicated
dbaron: Let's get rid of context entirely
es: what about ":path"
dg: ":composed"
dfreedm: I prefer path
es: "has" looks closer to "matches"
sjmiles: Front end developers want everything to be as short as
possible
rniwa: What about ":host" since we got rid of @host?
sjmiles: not bad
dbaron: agreed
es: But this could be arbitrary levels above
rniwa: I like ancestor
eo/sjmiles: I find it confusion
fantasai: I like host best
es: What about :inside?
sjmiles: that's the opposite of how we think about it as
devleopers
rniwa: yeah, I'd expect that to be OUTSIDE
es: If we do distributed shenanigans, why don't we do same
thing here?
dbaron: This is intentionally limited
<dfreedm> too late
dbaron: I think we're moving to :host?
tabatkins: not bad
es: but x is the host here, and the theme is on body
... path makes sense, like a traversal path
fantasai: What if you allowed host element to be matched in
host
tabatkins: you can: :host(*)
sjmile: Is there a way to avoid me having to write "x" all the
time for my placehodler
... now we don't use the name, we just use @host
tabatkins: no need to worry about it. will only match pseudo
element
es: is there a way to reference your host without explicit tag
name?
tabatkins: you can: :host()
es: how does that differ from :scope
tabatkins: no, because things aren't actually scoped
... the shadow is not actually a scoped style sheet
... it happens to be scoped, but it isn't technically a scoped
style
es: I think we should go with :host()
tabatkins: We can omit empty parens
rniwa: I like :host
proposed resolution: :host(<simple selector on ancestor path>),
or :host, which is equivalent to :host(*)
fantasai: What's the specificity
tabatkins: I think we can add the specificity inside the host
(?)
<dbaron> I think s/simple selector/chain of simple selectors
without combinators/
es: what about like [data-foo]:host(.dark)
CONCLUSION: :host(<chain of simple selectors without
combinators on ancestor path>), or :host, which is equivalent
to :host(*)
sjmiles: This is a different concept than ancestor. It has some
similarity to "something that's above me"
... it feels a bit weird to put what would be on the left side
would be in the parens to the RIGHT
whoops, sorry strike that resolution
I misunderstood what "resolution" meant in this context
thanks for the information! I'll get the hang of this some day
:-)
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
... but this is fine, given all the constraints.
<dbaron> just wait until I propose :上(.dark)
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
<dbaron> or :下(.dark)? Not sure which makes more sense.
tabatkins: 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
rniwa: I agree the ^ is weirder than :host
[discussion has gotten disorganized; scribe has been unable to
keep up for the past 2 minutes]
fantasai: We should agree that words should either be plural or
not plural
<fantasai> fantasai: And CSS already has 'content' in some
places
CONCLUSION: rename ::distributed to ::content
sjmiles: you don't need to have the content ahead of the
::content
fantasai: This helps people remember what it means, what
concepts it's connected to
<fantasai> (because the tag name is content -- distributed is
just out of the blue)
rniwa: Ideally the developer needs to know the minimum of
terrms
<dbaron> so 'content: contents' in
[16]http://dev.w3.org/csswg/css-content/#contents0 should be
'content: content' ?
[16] http://dev.w3.org/csswg/css-content/#contents0
<fantasai> either that or something else, yeah
[lunch break]
[lunch break over]
dg: Any more CSS - related topics?
dbaron: I don't know if we agreed if custom pseudos should be
functional or not?
eo: Yes
es: I think it would be said to sacrifice explanatory effect
dg: I agree with that
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
... there's a clarity that gets sacrificed by confusing the two
tabatkins: Even if we use no (), we still need to have a prefix
(?)
... 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
es: Okay, I won't fight for it
dg: dbaron mentioned a solution I'm okay with
... have a switch in shadow DOM spec that says that UA can
define pseudos if they want
es: Long ago, the idea that in this future world all the quirks
of the bedrock go away, evertyhing is components and who cares
... but we're leaving warts all over the place
sjmiles: There's a tension. Sometimes it's a clarity concept,
but sometimes user doesn' tneed to know
eo: In the future with lots of components, you can clearly tell
when you're dealing with a part of a components
es: Why need a prefix? Why can't you implement ::placeholder
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
es: Why not expose things that are actually inside of shadow
roots, why aren't they just a namespace open to anyone?
... placeholder is specced
... you'd need to say ::part(placeholder) (?)
eo: you wouldn't want to expose it as a shadow root; it's an
implementation detail
es: But every browser implements placeholder in the same way
... and this argument is, what if someone hypothetical browser
wants to do it some other way?
dbaron: Placeholder in gecko uses native anonymous content
... that's different from XBL, which is different from web
components
es: Gecko creates divs inside of an input element, right?
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
... which is different from Native Anonymous Content
... because NAC is where we construct actual content nodes and
construct boxes for those
... for a select we just make boxes
es: I don't understand the harm in claiming that <input> uses
component model
... like, keep ::placeholder. But why not also allow the new
syntax to address the same thing?
eo: Because the implementors can choose how to implement it!
dg: The question is not, whether it's implemented with Shadow
DOM, but rather how it interacts with rest of content
... so you don't have all of these weird behaviors and edge
cases. It's all described by semantics of shadow DOM
dbaron: You assume shadow dom will be web compatible
dg: We have implemented almost all crazy elements uses Shadow
DOM machinery
... everything exceltp select, which we have plans to switch
over as well
... it's been for two years now that we've been using it
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
[murmurs of aggremeent from sjmiles, dg]
dg: yeah, big fan
... part() comes from an old discussion
dbaron: There are three sorts: pseudos that are not tree like,
some that are leaf like, some are tree-like and contain real
elements
... CSS doesn't define any in the third category. But there's
been discussion about various ones
es: ::first-line can't possibly be implemented as an element,
for example
... it's different from somethign that can be exposed as an API
surface to style
dfreedman: I don't understand why it has to be different
eo: part() takes an author-defined ident
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
... it seems this makes sense. It makes sense that ::first-line
is different
dg: it's hard to explain ::backdrop in terms of these
primitives
... so that would stay the same
es: like there are some things that are clearly defined by
what's inside
... like scrollbars
eo: I disagree about scrollbars
dbaron: We plan to get rid of all internals to scrollbars
es: What kinds of scrollbars would you not want to build in the
div
rniwa: That's for the scrollbars that have been released to
date; in the future they might not
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
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
sjmiles: I think it's reasonable to say, for this thing, the
way we implement it we shouldn't reveal it
eo: I want to make a distinction between UA-implemented things,
and things built in WC world. We want that distinction
es: But why? If the standard says ::placeholder, it cannot be
removed entirely
... so for new ones, it should use part() so that others can
override later. But if it's not exposed, doesn't matter
dg: it gives a clear message to author of how to reason about
it--it's just like Shadow DOM.
... the UA is acting as an author in those cases where the guts
are exposed like this
rniwa: We don't want to be adding APIs that limit the ways in
which we can tweak UIs
dg: agreed. I don't think it matters. ::placeholder behaves
like it's implemented as Shadow DOM. So it should behave that
way fully
eo: The entire existing platform prior to the feature means
that user-land psueods and UA pseudos are different
es: today in WebKit, ::-webkit-spin-button IS a div today.
That's an API surface
... right now it has a prefix
... 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
eo: as an author, I want to be able to send a bug report to the
right person
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
es: But we're talking about, for things that ARE already
exposed
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
eo: we're stuck with legacy scrollbar contrrols forever. :-(
dbaron: mobile use cases are a great example. I'm glad we
didn't commit to select's having a dropdown button
... I think you're being conservative about what to expose
es: You seem to be arguing that ::placeholder was a mistake and
we should remove immediately?
dbaron: I think freezing everything about form controls at this
moment is a bad thing.
dg: I think we're talking about two different things
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
dg: ::placeholder already behaves, as specced today, as a
custom pseudo-element
... as if it was a custom pseudo-element
rniwa: Spec doesn't say that ::placeholder needs to be text
inside a Shadow DOM. Just that color and whatever can be
controlled
... this allows UAs to match the convention of the platform
... 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
es: I don't care so much about scroll bars; mozilla doesn't
want to implement them
... I'm saying when it's a standardized API surface, it should
be exposed with Shadow DOM
eo: take input type=password
... users before authors, etc
... it would be reasonable for an impelemnter to say that user
type=password cannot be overriden by components
es: that's fine, the standard should say that for those cases
dbaron: I think there's another answer to this requirement
... your requirement is about re-impelmenting existing parts of
the platform
... I'm okay with the component model having a way to match an
existing part of the web platform
... that's different from saying that you can extend the
pseudo-element space arbitrarily
es: To clarify, I'm arguing we should do ::part(). And that we
should fix the platform to fit this
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
... and then if you add a new pseudo, it goes in the box where
user-land new pseudos go
sjmiles: Eliot's proposal does everything yours says, but
simpler, from our perspective
es: We all seem to be talking from different contexts
sjmiles: I think we're closer than we think we are
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
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
... why does it matter what comes from UA and what comes from a
component?
rniwa: That is an API surface. It's a namespace issue
es: It doesn't matter if you don't reproject
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
sjmiles: I think rniwa has a good point about namespaces
*namespace
rniwa: We could have collisions with new formalized pseudos if
they share the same namespace
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
... those types of collisions happen all the time.
... You're trying to protect yourself from one, particular type
of namespace collision. THere are lots of them!
dbaron: There's a different error-handling rule for pseudos,
and WebKit implemented something else, and didn't come back to
the standards groups
... now you come back and say you want to build a new feature
on top of that broken feature
es: We agreed on that part--we should move to
::part(placeholder)
... isn't this like saying, custom elements are bad idea
eo: yes! I think you should only do it if it's a good reason
dfreedman: but how do you know in advance if they'll have a
good reason?
es: I'm saying, all platform widgets, however they're
implemented (jquery, etc) they should have the same API surface
... not if you use Shadow DOM surface.
dfreedman: part(oplaceholder) just describes the same thing as
::placeholder
dg: eo is saying htat part defines user-defined pseudos
dbaron: I think I'm okay with either formulation (?)
rniwa: think about for example, translation attribute
... we shipped and broke a lot of libraries in india
eo: We have compat constraints we need to take into account
rniwa: We want to avoid breaking existing websites
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
... so you're saying that every method in say polymer has to be
polymer_foo()
sjmiles: We tried somethign at the beginning, where we
presented a different public face. Developer users HATED it
... developers want more power AND backwards compatibility.
It's hard.
rniwa: MediaWiki added a special style attribute to work around
WebKit bug
... we fixed it, but now we can't remove it because mediawiki
content is deployed with the old stuff
eo: Quickly: this is the same argument from last F2F: the idea
if we should allow custom element names over the wire
... is=foo nicely delineates which is user land
dg: it's solved with the - requirement
rniwa: I'm less concerned if authors can only extend
HTMLElement
es: Either developers are responsible for avoiding namespace
collisions everywhere, or nowhere
sjmiles: Seems like everyone agrees the ::part() is a good idea
in many cases
CONCLUSION: ::part() is a good solution for user-land pseudo
elements
... although the group doesn't necessarily agree about existing
pseudo elements at this point
dg: ::Part and ::pseudo is fine (?)
<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
<dbaron> d that ::part(placeholder) should be an alias for
::placeholder for consistency
<dbaron> )
CONCLUSION: the attribute to register these custom pseudos is
"part" (not pseudo as it currently is in spec)
The CSS portion of this discussion is over. We'll stop taking
notes h ere
<MikeSmith> .win 15
Summary of Action Items
[NEW] ACTION: tabatkins to update the spec to the paren-less
version of the :distributed, with a note that we will use that
syntax if implementors don't scream after experimenting with
implementation [recorded in
[17]http://www.w3.org/2013/06/21-webapps-minutes.html#action01]
[End of minutes]
Received on Tuesday, 25 June 2013 11:27:54 UTC