Re: [webcomponents] Minutes from 21 June 2013 f2f meeting

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:
> <>

The minutes were not complete when I announced them yesterday but that 
issue has been fixed and the complete minutes are copied below.




                                - DRAFT -

                   WebApps' Web Components f2f Meeting

21 Jun 2013



    See also: [3]IRC log



           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





      * [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
    ... 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
    xplainer/index.html still up to date?


    DG: if I can replace the rendering of a node, what happens to
    its children?

    <slightlyoff> rniwa: or, also:


    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:


    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:


    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

    [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]


    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
    ... 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

    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]


    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
    ... 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

    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

    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
    ... 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

    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

    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

    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

    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
    ...: :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

    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
    ... 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]

    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
    ... this example will target the host element outside



    ^ that link works


    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
    ... 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
    ... 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

    <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

    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

    <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

    es: That's not how it's currently specced. It's currentlys
    pecced that elements are distirbuted, but not that <content> is

    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

    <trackbot> Error finding 'tabatkins'. You can review and
    register nicknames at


    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

    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

    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

    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

    es: is there a way to reference your host without explicit tag

    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

    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

    CONCLUSION: rename ::distributed to ::content

    sjmiles: you don't need to have the content ahead of the

    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

    <dbaron> so 'content: contents' in
    [16] should be
    'content: content' ?


    <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
    ... 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

    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
    ... 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
    ... 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

    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

    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

    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

    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
    ... 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
    ... 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

    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


    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
    ... 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

    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
    ... so you're saying that every method in say polymer has to be

    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

    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
    ... 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

    [End of minutes]

Received on Tuesday, 25 June 2013 11:27:54 UTC