[Web Components] Minutes - Shadow DOM teleconf April 5

Available at https://www.w3.org/2016/04/05-webapps-minutes.html or as text  
below.

Thanks to Jan Miksovsky for logistics, and in particular for scribing!

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                      Web Components Teleconference

05 Apr 2016

    See also: [2]IRC log

       [2] http://www.w3.org/2016/04/05-webapps-irc

Attendees

    Present
           Jan Miksovsky, Domenic Denicola, Ryosuke Niwa, annevk,
           Dimitri Glazkov, Elliott Sprehn, Travis Leithead, Hayato
           Ito, dan, smaug

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           Jan Miksovsky
      __________________________________________________________

    <Jan> Rniwa proposing we go through Domenic’s prioritized list
    of issues

    Domenic: let’s start with some easy ones
    ... seems like “restrict to secure contents” is not going to
    happen

    [no one objects]

    Domenic: I’ll note that in the thread

    annek: on attributeChangedCallback order, sounds like we can’t
    agree on an order

    rniwa: order is an interop issue

    annek: it’s going to take a long time before Gecko gets around
    to (preserving stable attribute order)

    elliott: there’s stuff to be sacrificed there
    ... what webkit does doesn’t end up with memory optimization
    ... we’re asking Gecko to reduce the effectiveness of their
    memory optimization
    ... Chrome and WebKit both agree

    elliott: there’s no interop here, so if we change it, nothing
    breaks
    ... MutationObserver is going to give you totally different
    order in diff browsers

    domenic: propose: keep the order that’s in the spec, general
    willingness to converge on determinism

    rniwa: ok, but I wouldn’t necessarily block the other browsers
    from implementing custom elements (by forcing determinism)

    elliott: doesn’t seem like a big enough win for Gecko

    <annevk> sorry dglazkov :-(

    Travis: try again

    <annevk> no jokes this time I guess

    <dglazkov> hangouts_queue.pop()

    (Travis joins video chat)

    rniwa: should we tackle “parse <slot> like <template>”?

    annek: it sounds like nobody is really interested in making
    parser changes
    ... i’m tempted to punt on the whole thing
    ... ideally a custom element could replace a <thead>, etc.,
    but...

    rniwa: I thikn that this would be really risky
    ... we’ve seen elements in the wild with a dash in their name,
    so changing this would be risky

    domenic: this would be nice, but probably not worth it
    ... nobody seems to be strongly advocating for it

    annek: this is probably okay as is

    travis: is there a good workaround?

    annke: you can always just use the DOM API to restrict your
    tree instead of the parser

    annek: but that’s a workaround
    ... or you could use custom elements for everything, reinvent
    all the elements

    elliott: that’s funny, html tables is missing column spans,
    that’s the only reason people use real tables
    ... the generalized solution we’d like to pursue is a meta tag
    that lets you opt into a more streamlined parser

    annek: an XML5 (?) parser

    elliott: we’ve spend so much time band-aiding this thing,
    that’s why we never went there

    annek: in general, that’s a fine plan

    travis: sounds like versioning to me

    annek: sounds more like strict mode

    elliott: the nature of such a thing is off topic

    annek: it is hard

    rniwa: alternative is to have an attribute to add an element to
    a slot

    domenic: certainly not v1, but any reason why that’s not a good
    idea

    rniwa: it kind of violates the fundamentals of the element

    annek: do you use display: contents on it, and then what does
    that mean? sounds like v2

    rniwa: an attribute way of adding a slot might be a v2 thing

    elliott: if this is popular, someone will write a library to
    (implement this feature), and that will be a signal to do this

    annek: let’s move to the top of the list, issue 308: should we
    use “display: contents"?
    ... I’m going to say “yes"
    ... … Gecko has an implementation of display: contents.

    rniwa: We haven’t done this yet, but our intention is to do so

    domenic: our position: reasonable semantics, main concern is
    that this adds a lot of implmentation
    ... would delay getting this into users’ hands

    travis: can someone restate the problem

    annek: can the <slot> element itself end up in the final
    layout/flat tree

    if it ends up there, you can style it; if not, you can’t do
    anything with it

    travis: iframes are sort of like super-slots, and they’re
    independently styleable
    ... but its background color doesn’t matter, because it gets
    replaced

    (as jan) I haven’t seend the need for this

    travis: maybe it shouldn’t have a particular representation

    annek: if blink ships with its current idea of not having it in
    the layout tree, ...

    and then changes some months later...

    elliott: this doesn’t really work, you could end up styling the
    slot by mistake
    ... you wouldn’t want to ship this
    ... any style applied to the slot is a no-op

    rniwa: we’re changing the behavior as we speak

    <Domenic_>
    [6]https://github.com/w3c/webcomponents/issues/308#issuecomment
    -204198578 outlines elliott's concerns in more detail

       [6]  
https://github.com/w3c/webcomponents/issues/308#issuecomment-204198578

    rniwa: we also support computed styles on the slot
    ... principle is this: there are real use cases that display:
    none would be ignored
    ... that’s confusing
    ... every other kind of element is styleable

    elliott: it’s not clear to me that eveyrone has that
    expectation

    travis: but the slot will be there if you go exploring (in the
    DOM)

    elliott: yes, the slot is there, but you can’t put a border on
    it, or padding, or margin...
    ... assuming display: contents, you could put an inheritable
    property on it
    ... if I put :before and :after on the slot, do they apply?

    rniwa: this is an issue with display: contents in general

    elliott: I think display: contents is a confusing feature

    rniwa: if you want to object to that feature, you could do that
    with W3C

    elliott: I have
    ... coupling Shadow DOM to a feature that involves…

    rniwa: elliott and Tab (Atkins) both work for the same company,
    and should (be on the same page)

    elliott: there’s not concensus within Google that we need this
    feature
    ... there are a lot of edge cases that would be broken in v1

    annek: if we don’t do this in v1, we can’t add it later

    elliott: the only way to solve this in the future would be to
    introduce a new CSS property

    annek: there’s an element in the tree, and then it disappears
    from the tree, we don’t have anything else like that

    domenic: can you style the <meta> element?

    (someone) yes

    annek: it sounds like we add a style for style slot in the
    future that’s special, or do display: contents now

    elliott: it’s not clear that everyone’s agreed to the details
    of everything (Tab) is implying

    domenic: figuring out suitable semantics for everything is what
    we’re not excited about

    annek: if you do display: contents, you can have
    pseudo-elements

    <annevk>
    [7]http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!D
    OCTYPE%20html%3E%0A...%3Cstyle%3E%0Adiv%20%7B%20display%3Aconte
    nts%20%7D%0Adiv%3A%3Abefore%20%7B%20content%3A%22X%22%20%7D%0Ad
    iv%3A%3Aafter%20%7B%20content%3A%22X%22%20%7D%0A%20%3C%2Fstyle%
    3E%0A%3Cdiv%3Etest%3C%2Fdiv%3E

       [7]  
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A...%3Cstyle%3E%0Adiv%20%7B%20display%3Acontents%20%7D%0Adiv%3A%3Abefore%20%7B%20content%3A%22X%22%20%7D%0Adiv%3A%3Aafter%20%7B%20content%3A%22X%22%20%7D%0A%20%3C%2Fstyle%3E%0A%3Cdiv%3Etest%3C%2Fdiv%3E

    hayato: because shadow root is removed from the tree, slot is
    removed from the tree
    ... there’s a dilemma for that
    ... problem is we have to make the <slot> element an element
    ... can we have a new type of element for <slot>?
    ... we can style the parent elements of slots

    rniwa: i think the problem is consistency. <slot> is a weird
    element
    ... can’t get computed style, but things inside of it would be
    shown, it’s exotic

    annek: we could have a <slot> node instead of an element
    ... would it still have to be created by the HTML parser?
    ... if that’s the requirement, then it does need to be an
    element

    (someone) let’s not go there

    travis: i don’t have a problem with <slot> being an element
    ... i like having display: contents so that it’ll be there down
    the road

    annek: some engines can ship display: contents, some don’t, we
    can sort it out later

    travis: it’s like the appearance property

    domenic: (grimmace)

    elliott: if we spec it as display: contents, and then change it
    to display: block, does the slotting algorithm still place
    things underneath it?

    rniwa: it would render
    ... it’s as if you have an anonymous box around the lements

    annek: it’s not anonymous, it’s not an element

    traivs: you can give it some padding, and that would work

    annek: i think it’s okay, if mozilla and webkit ship it, and
    blink can fix it soon enough

    <annevk> [8]https://github.com/w3c/webcomponents/issues/417:
    caching vs. late binding of lifecycle callbacks

       [8] https://github.com/w3c/webcomponents/issues/417:

    annek: next: issue #417: caching vs. late binding of lifecycle
    callbacks

    domenic: if you change callback on an element, should we call
    it, instead of one on the custom element you originally
    registered
    ... i’d like to close this, it’s the only big remaining custom
    elements problem

    travis: trying to parse out the last comments on that issue

    rniwa: the main problem we had was is the inconsistency
    ... you can change other methods on an element, but not
    callbacks

    domenic: all elements go through a define step, including
    built-ins
    ... if i’m the browser, and change setAttribute before the
    built-in element is defined, that changes the behavior
    ... if i do that after it’s been registered, it doesn’t change
    the behavior
    ... same thing should apply to user code

    travis: we should impose similar restrictions on user code by
    caching (callbacks) and not allowing mutability

    annek: this sounds nice, until you consider subclasses
    ... the subclass cannot change those things
    ... mozilla has given up on finding any consistency here

    domenic: if you want to be completely consisten with regard to
    subclassing you have to protect (invariants?)

    [discussion]

    elliott: you shouldn’t do dynamic customization on a per
    element basis

    domenic: you should have to opt-in to per-element customization
    ... you can’t overwrite the click method of an <input>

    [discussion]

    rniwa: we could just freeze those attributes once define is
    called

    domenic: i don’t like modifying user classes
    ... we just got away from that

    elliott: how do you freeze these?

    rniwa: we can store the callbacks at define time
    ... there concern is that the user can modify it, all
    othermethods work, but not these (callbacks)

    travis: domenic pointed out that the user can try to modify all
    sorts of platform behavior, and that doesn’t work

    domenic: when the platform wants to create an array, it doesn’t
    call user code, it just creates an array

    [discussion of @@species as an example of user code being
    called from platform code]

    travis: the question is: is this an extension point that we
    want to create

    rniwa: if that’s the case, we should go back and make these
    symbols again
    ... then there’d be less confusion that these are special

    travis: symbols are not immutable

    elliott: symbols would have different author expectations

    <annevk> Element.attributeChanged

    <annevk> "attributeChangedCallback"

    <annevk> (latter is two characters extra, but I guess you
    typically don't need the quotes)

    annek: i think we have rough consensus, and Apple would be
    slightly sad

    domenic: these callbacks (on custom element classes) are kept
    there for subclasses

    rniwa: i’m not okay with it, but let’s just move on

    elliott: let’s move on, what’s next

    [9]https://github.com/w3c/webcomponents/issues/477:

       [9] https://github.com/w3c/webcomponents/issues/477:

    rniwa: exposing the element inside a closed shadow root doesn’t
    make sense

    annek: since open trees are exposes here and there,
    currentscript can expose them?
    ... how do we solve this, even for the closed case?
    ... it doesn’t seem ideal that you can’t get a reference to
    yourself

    rniwa: it’s hard to imagine a custom element accessing a random
    script inside it and getting a reference to itself

    elliott: script type=“module” runs in a separate scope, right?

    domenic: corret

    elliott: document.currentScript is kind of bizarre
    ... in an HTML Import, document.currentScript ends up
    referencing the script that’s being imported
    ... we should have a variable within script type=“module” for
    this instead of a currentScript global

    domenic: we can let it be null in Shadow DOM, especially
    closed, potentially open, is that right?

    elliott: there are use cases where you need to be attributes on
    a the <script> tag directly

    annek: it’s reasonable that those libraries get rewritten for
    the brave new module world
    ... maybe we should just ban this API

    rniwa: that’s a good way to go, esp. since no one’s implemented
    script type="module"

    travis: the fact that we have this global property and that’s
    sort of working already, i feel that we shouldn’t do any work
    on it to protect closed Shadow DOM
    ... closed Shadow DOM isn’t a security barrier anyway
    ... this is just another way to work around it
    ... if I really want that strong security, we have to go with
    that isolated approach
    ... not doing anything with currentScript and let it have this
    weird access seems like a bizarre case

    annek: we should resolve this as returning null
    ... this is the least objectionable path
    ... moving on

    <annevk> [10]https://github.com/w3c/webcomponents/issues/355:
    use CSS containment features by default

      [10] https://github.com/w3c/webcomponents/issues/355:

    elliott: are we okay with saying that if you put an absolute
    element inside your element, and position it outside your
    element, is it okay if it gets clipped (because of CSS
    containment)?
    ... intention of doing this is to state an opinion about the
    direction we should be moving
    ... if you encourage authors to place elements more visually,
    you get a simplified implementation and your code can be faster
    ... we could encourage authors to be fast by default

    domenic: this was just an opportunity to introduce a new
    direction

    rniwa: this would simplify delay introducing Shadow DOM in
    WebKit
    ... we don’t have this implemented

    annek: how many browsers implement `contain`?

    [discussion]

    rniwa: i think doing this for Shadow DOM is the wrong approach

    dan: we don’t about this feature being the default

    annek: sounds like we have consensus (to punt this)

    <annevk> [11]https://github.com/w3c/webcomponents/issues/186:
    integrating callback invocation with IDL and editing operations

      [11] https://github.com/w3c/webcomponents/issues/186:

    domenic: [describes a proposal related to IDL]

    rniwa: I think this is a great thing to do

    travis: i agree
    ... it would be great to have this declaratively

    domenic: okay
    ... i’ll figure it out, it’s just going to be a pain

    <annevk> [12]https://github.com/w3c/webcomponents/issues/468:
    provide a mechanism for adding default/"UA" styles to a custom
    element

      [12] https://github.com/w3c/webcomponents/issues/468:

    domenic: now that we got rid of /deep/, there’s no way to style
    an element like this

    rniwa: only question is whether we take a string, or what type?

    elliott: it can’t be inline style
    ... there’s also a proposal to have constructible stylesheets
    ... if we do this to use a string, then we can use
    constructible stylesheets when they’re finished
    ... blocking on stylesheet objects seems silly, that’s a big
    project and a ways out

    travis: this isn’t blocking v1, right?

    domenic: we could add this

    elliott: we were hoping this would be just like attaching a
    shadow root, then appendChild’ing a a style element

    travis: i was seeing this as styling the custom element itself

    domenic: the :host selector would style the element itself and
    the descendants

    elliott: it doesn’t style the descendants

    rniwa: we need to create a new context in which these (styles?)
    are evaluated
    ... we’re somewhat skeptical of this feature, it seems
    redundant
    ... we already implemented optimization that if you define the
    same style in a shadow root, and it gets reused across many
    elements, we reuse...

    domenic: this would let you do styles without having to add a
    shadow root
    ... i would like this to be at the same level of the cascade as
    UA styles
    ... this is currently impossible

    [discussion]

    elliott: providing a feature like this allows a framework to
    say, “all elements in my framework are block”, which I think is
    beneficial

    rniwa: i don’t think we object to this, but i don’t want to
    block the rest of the custom elements API on this

    annek: this shouldn’t block shipping minimum viable product

    <annevk> [13]https://github.com/w3c/webcomponents/issues/288:
    `slotchange` event

      [13] https://github.com/w3c/webcomponents/issues/288:

    domenic: this doesn’t block shipping v1

    annek: i think we all agree on using MutationObserver timing
    ... i’m assuming it wouldn’t bubble?

    elliott: are there any other microtask-timed events?

    <smaug> (does bubble or not really matter?)

    travis: promises are microtasks timed

    <smaug> (and no, this would be the first microtask timed event)

    rniwa: maybe this microtask is the timing you want to use for
    new async-type events

    annek: full-screen events don’t use task-timing

    <smaug> (and we need to remember that microtask != async from
    UA point of view. /me goes back to doing something else.)

    elliott: this seems like we’re inventing a new technology, do
    we intend to do that

    (someone) want about “blur"?

    annek: depends on the engine

    elliott: i’m not objecting to the timing here, unless we think
    this is one-off thing for slotchange

    domenic: this is mutation-to-the-DOM timing

    (someone) why isn’t this is a MO?

    travis: this generalizes it, to the point where we may not want
    it to be a MO

    annek: 1 we have multiple mutation records
    ... 2 a record is expected to carry sufficient data to reply
    what happened, which someone people don’t want here
    ... 3 if you think of Shadow DOM as a layer on top of DOM and
    should use DOM architecture
    ... the proposal is tied to how much insert/remove behave
    ... given not wanting to expose too much data, i’m okay with
    this as an event

    travis: the event and how you expect it to look after
    processing queued records, is that defined?

    annek: i’ve been waiting for this call to be over

    elliott: when do we queue the event?

    [discussion]

    elliott: let’s just do this for v1, and see what authors

    <rniwa> woot! so productive :D

    <annevk> yeah this was great

    <annevk> thanks everyone

    <dglazkov> \o/

    <rniwa> jan: thanks for scribing!

    [End of minutes]
      __________________________________________________________



-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Wednesday, 6 April 2016 12:10:16 UTC