See also: IRC log
<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_> https://github.com/w3c/webcomponents/issues/308#issuecomment-204198578 outlines elliott's concerns in more detail
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
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> https://github.com/w3c/webcomponents/issues/417: caching vs. late binding of lifecycle callbacks
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
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> https://github.com/w3c/webcomponents/issues/355: use CSS containment features by default
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> https://github.com/w3c/webcomponents/issues/186: integrating callback invocation with IDL and editing operations
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> https://github.com/w3c/webcomponents/issues/468: provide a mechanism for adding default/"UA" styles to a custom element
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> https://github.com/w3c/webcomponents/issues/288: `slotchange` event
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!
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/travis/domenic/ No ScribeNick specified. Guessing ScribeNick: jan Inferring Scribes: jan WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: Domenic_ annek annevk annke dan davidb dglazkov domenic elliott hayato https marcosc rniwa smaug traivs travis zcorpan You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 05 Apr 2016 Guessing minutes URL: http://www.w3.org/2016/04/05-webapps-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]