See also: IRC log
<ArtB> ScribeNick: ArtB
<scribe> Scribe: Art
<dglazkov> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0074.html
<smaug> hello all
<adrianba> scribe: israelh
dglazkov: Would like to break down discussion into three topics: Shadow DOM, Custom Elements, and HTML Imports
... Shadow DOM is the more interesting. Let's pick which one we want to discuss first.
... Start with Custom Elements ?
... Shadow DOM after that?
... Custom elements is in first draft
<ArtB> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html -> Custom Elements Editor's Draft
<dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
dglazkov: And interesting topic to start with 24578 buhg
... Registering a register primitive
... Having the ability to expose internal attributes on Customer elements allow you to clone it, assing it to a different document
<ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567#c69 -> Anne's comment #69 for bug 20567
dglazkov: The idea is that when an element is adopted from one doc to another, and as an an author of the element you will get a callback that allows you to reason about the attribute being used in other elements
... also, the idea that you could use the registry as a way to scope the element names.
... a web developer has a sub-tree in their document and would like to parse their specific elements from the local registry. Having a scoping concept would be very useful for them. However, if you want to rountrip when coming back form the parse you would have problems
... because when you serialize the tree the parse would have no idea of where that element came from, thus surprising.
... I would like to introduce the registry concept into the spec and see where it goes from there.
... I want to allow allowNode callback to reason about registries.
... I would like to get everyone's opinion about it.
rniwa: What is the use case for the callback.
dglazkov: deeper into this subject. IE and FF have a behavior that is different from blink and WebKit and their prototype when it is adopted from another doc.
... IE and FF when you are adopted from one doc to another, you loose your old prototypes. Blink and WebKit don't do that.
... there is disagrements whether this should be on spec.
... the callback we are discussing provides a mechanism to allow elements to update the prototypes dynamically. Thus, becoming and implementation detail instead of part of the spec.
rniwa: it might be more useful to standardize the UA behaviors instead of putting this on the hands of the devs.
dglazkov: for custom elements this decision is not so clear. It is not always clear what is the right behavior. Specially if the definintion of my element is not defined on the new environment.
... element foo may colide with a different definition of another element foo on that document.
rniwa: it seems strange that each doc would behave diff on each environment. It doesn't allow you to reason about the custom element on the environment that is being used.
dglazkov: this seems bad if you don't have the ability to reason about the custom elements diff.
adrianba: it would be bad.
rniwa: it seems like we need to figure out how we can guarantee that the custom element keeps the same information across document. Maybe this is the issue.
dglazkov: that is what registers let you do. You can look at the registry and reason about this.
rniwa: potentially you can have a global map for each page. that checks if the definition of the class has been raised and possibly rejected. Some type of consistency check.
... we probably don't want to reason about having different custom elements that are of the same expected type.
dglazkov: the thing is that it doesn't have to be the case, the problem is that the scenario could happen and we need to figure out how to deal with this.
rniwa: for ex. you can imagine the registry happening about all in one script context, within one navigation.
dglazkov: there is a specific reason the registry is scoped to the doc. because each doc could have its own set of elements.
... in xhr docs don't have a registry for custom elements and don't run script.
... there is no document in browsing context. there is no association between document and browser context.
rniwa: in the case of XHR, there isn't any document context.
dglazkov: the create implementation of create document should have a browsing context.
... (looking at spec chapters looking for something )
... creating and passing a regisry section, we do associate a new registry at that point when creating a new import document (those things don't have a browsing context but are able to operate as if they had a registry)
... It is a good idea to look at this bug 20567 and understand what needs to be done here.
<dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567#c69
rniwa: exposing a list of custom registries seems like a good thing. but I'm not sure how the ability to update the definition of the doc using this information is a good idea.
adrianba: if you end up with a button and import a different button (but when looking at the elements they look the same) that seems like a bad situation.
dglazkov: I agree this is a bad situation, that is what we are trying to solve.
... this is not a use case, it is more of how do we deal with this if it happens.
adrianba: can we just say that the call fails and the element doesn't work.
dglazkov: it seems reasonable to make it work, however we need to reason about their seirialization differences.
adrianba: can we clone the prototype?
... if we import from one doc to another and then clone the prototype things might work.
dglazkov: I'm not sure there is a concept of cloning the prototype. the notion that you are attached to the old world, where someone creates a doc, registers things to it, import those notes, but not sure why you would do that although it is supported.
rniwa: maybe we could have the registry that is shared across elements that come from the same origin.
<smaug> what does cloning the prototype mean? should the expando properties from the old prototype be cloned too?
rniwa: if we do that, we have the same issue where one prototype has multiple def, but if we had this mechanism (park all docs in the same origin) we might be okay if registration is simulatneous. It would reduce the instance in which the def are diff.
... after we create the object, that doesn't mean that the two objects are the same.
dglazkov: if you want to compare, you would have to introduce the abiltiy to compare diff between elements.
rniwa: if we allow customents, we need to provide that ability to compare themselves. This could be a big developer issue. We need to come up with a solution where we don't burden the author of the custom element.
mjs: clarification, do we have the usecase for adapt a custom element from one doc to another, is this a real case or theoretical.
adrianba: is the situation where the custom element has the same name but a different instantiation
mjs: can we just let this scenario fail, or do we need to support it? failing seems like a good approach if this is an edge case.
dglazkov: I didn't say this wasn't sufficient, i would like to reduce the number of errors we throw.
... yes it simplifies but it will likely anoy the developer.
mjs: It will only anoy the author if this is a common case, otherwise he should be okay.
<KenjiBX> +q
dglazkov: there are many shades of gray here. There is a reasonable situation with HTML templates when you are moving from a template to the main document. We need to support this situation, we don't want to throw.
mjs: there are simple behaviors we could support without throwing.
... (talking about possible options). buttom line we should err on the side of simplicity.
dglazkov: the main case where we need to do the right thing is when we deal with multiple docs that are import docs and templates. Those things have to work, if we start messing with the definitions there we are in trouble.
mjs: import docs share the same registry.
... requiring docs to deal with extra complexities seems difficult to address as a component author.
dglazkov: what complexity are you talking: adapt mode callback and registry? The adopt mode callback allows for changes to be reacted when loading resources.
mjs: do custom elements allow for remove and insert into documents?
dglazkov: no
mjs: adapt doesn't seem like a special case unless, many people have already created custom elements without this functionality.
dglazkov: not sure how DOM core works here. Anne had some ideas here. We can definetely talk about the importance of this callback.
mjs: what is the correct venue to discuss this?
dglazkov: 20567 bug is the right venue for this.
<rniwa> +q
KenjiBX: ... it seems there is no real case, and the conclusion is to make it fail. If we find out later that there is a use case, can we then deal with this situation.
dglazkov: I beleive this is reasonable. That is the reason I wanted to bring it up to the group. I wanted to get everyone's opinion in the need to register. I will put it in the back burner. THere are some usescases that might help. I'm not feeling the love right now.
... we can talk about the difference between adoption and registration.
mjs: adpation node without inserting anywhere is very rare, (doesn't seem to happen).
... if they were to change to insert doc and remove doc, then we could easily look for customer default view. if we had that, elements could check that. If I had the option of adding the adapt callback then I would prefer the ability to inserting attach and detach.
... if we had remove and insert, we could simplify the operations.
dglazkov: please provide feedback on bug and state your opinion, it could be that what you are suggesting is good enough.
mjs: maybe we should have a different bug on remove and add callback
<rniwa> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24577
dglazkov: there seems to be one bug on this (24577)
mjs: I think Anne in this bug is looking at the leaking of the entire document when the element moves.
dglazkov: any help here would be appreciated, maybe if we solve this problem we might be in good shape for the previous bug.
mjs: It seems like letting thing fails would be the initial good approach for this.
... perhaps the concept of a global registry that is shared everywhere could be an interesting approach.
dglazkov: let's work on these two bugs and discuss the possibility to add remove and add from document concepts.
... is the ship in the water or the deep in the ground :-)
<alia> Scribe: Ali
<alia> ScribeNick: alia
dglazkov: I need something in my custom elements to mean something different. Use case: I'm building a framework. Custom elements are in and out of the framework. Inside is the plumbing that uses custom elements because it's useful. How to separate the two and don't expose to each other.
... Shadow DOM is a good example. Parser is per docment. But that seems like a bad idea. Maybe we could let the frameworks define the registry that contains the internal plumbing and feed it to innerHTML of the fragment parsing of the shadow trees that they're creating so that when they create these things they get the definitions of these outside elements.
... Allows the ability to scope the parser. Bringing up here. Give me a doc registry and add stuff to it. May have a method that is in addition to pass the registry.
... Can put things in template and as it's being inserted into the shadow tree, they will be inflated the proper way. Not sure if this is outlandish or crazy or both.
mjs: Want to understand the use case better. Two possible meanings. An element that is used in the light DOM. TR in TABLE. TR outside of TABLE is not sensical. Other compound elements that have these structures. Want to have some elements as implementation details.
dglazkov: You're right on. Shadow DOM is the prime use case, but there are some thoughts on this in light DOM. Parent changes the meaning of the element outside.
mjs: Need different ways of dealing with these two cases. Need an attachment of the custom element to be conditional based on the parent element.
... Which do we want?
dglazkov: I don't care how it's fixed, but we need a fix. In my mind, having meaning changed based on the parent is a path to madness.
mjs: Want to refactor internal implementation. Two completely different use cases.
dglazkov: When a developer has no Shadow DOM, they only have one of them. Here is my internal and external stuff. Spoken from a developer who has not ever had a shadow tree.
alexrussel: We don't know what we don't know in this area. We don't know what people actually want to do. If we make it possible to create new local namesets, it removes any incentive to agree on global names. We lose our ability to define elements and custom semantics. Would lose value on the web.
mjs: Depends on which use case. Some degree of global agreement. There can be imports, but some internal that it can use. Cleaner way to do it, than have scoped registry. Only some of the names I define can be exported. May change the way the that import function works, so it is not suggested we do it right now.
... TR almost makes sense in the context of the TABLE element. There are specific elements that are defined in this hierarchy.
... It seems obvious that people would want to build things like this. It clearly is a use case. Do not agree with using private names would reduce incentive to create global names.
... Get developers to participate in the group so we can have a direct conversation with them to understand the use cases better.
... It would help if you want clarification on this feedback to ask them directly.
dglazkov: I will try to get people.
... We have beaten this registry thing pretty well. Moving on to custom elements.
... I want to tackle exposing element on callback queues first.
<ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0074.html -> Dimitri's topic list
dglazkov: There was a valid point brought up that custom element spec reminds us of a special kind of mutation observers.
... In the custom elements spec, in queueing and invoking callback. The general idea is there is a quantum of time for invoking callbacks that is different than queueing callbacks. Might be a good idea to expose this a mutation observer so that developers can start using it directly.
... Want to gauge opinion.
<dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579
rniwa: Only feedback is that it is vaguely specified. Transitioning between scripts. Multiple stacks of user scripts and user agent scripts that would result in messy situation. Running two user scripts with an interleaved DOM script based on the spec's wording. Could use more clarification.
dglazkov: Posted a bug 24579. After callback, drain the pool, so that we can fix the problem
mjs: Super inconvenient because every native method that does this wouldn't require annotation. If implementations are done in native and client code, the draining needs to be conditional. There are some cases when this could happen.
dglazkov: This is a separate topic and so we need to separate the abstractions. Need to separate the quantum of time for callbacks and queueing. Start trusting it in a certain point in time and stop at a certain point in time.
... Only a few methods that do this.
mjs: There are many methods that don't mutate DOM but could include script that mutate DOM.
dglazkov: Already done this in Blink, if you look at the element.IDL, you would see a bunch of Custom element callbacks. Some of them, some will, but it's not really that bad.
mjs: Let me ask a specific quesiton, does dispatch event have this notation?
... Could retake the DOM.
dglazkov: Dispatch event itself does not mutate DOM.
... In the event handler will have its own draining which will arrive at a consistent state.
mjs: Will always be at a safe point in this case.
<morrita> Just FYI: https://code.google.com/p/chromium/codesearch#search/&q=CustomElementCallbacks%20file:idl
dglazkov: Trying to wrap up mutation events. Did not participate in mutation observers but will give it a shot and see what I can come up with.
rniwa: Jonas pointed out on one of the threads is that mutation observers calling each other back while in an observer itself, with this new nano task timing, it's possible to create an element in the observer and that could create an issue.
dglazkov: When changed to a generic mechanism, but solved by queues. Need to look into this in more detail. Mutation observer observes per element, narrowed down. An element queue and a callback queue, and every element has an element queue, separating these out allows for handling this in a consistent fashion.
rniwa: Trying really hard to solve issue where removing the element itself.
dglazkov: Going to see them being called in the same order for consistency. If observing yourself, you see that you are being attached.
mjs: I don't think that's the biggest problem. The problem is that attaching can occur inside the attach.
... In attach callback that removes a node, inside the attach, document.body.appendChild(this). Inside that attach, you would insert back in the document, at which point you would be calling attach again.
dglazkov: The element queue solves this. While inside of the attach handler, you won't hear any callbacks until completion. What is the element that you're procesing and which is the callback you're processing is asked when there is an execution.
rniwa: Attach will be called, but the detach will be called later.
dglazkov: After finishing running callback of attach, then attach would occur.
... When using element callbacks, you have to rely on what the callbacks tell you, because the state is going to tell you either you're going to observe the outside world or only the callbacks that arrived. If you have been detached despite having been attached, it will work because you can trust the callbacks.
rniwa: In the custom code, there may be some event that asynchronously causes issues.
ArtB: Now going to break, coming back at 11.
<krisk> scribe: krisk
<smaug> (another meeting)
artb: proposes to have a meeting once in a while for web components
<ArtB> ACTION: barstow work with Dimitr re a Web Components calls/meetings [recorded in http://www.w3.org/2014/04/11-webapps-minutes.html#action01]
<trackbot> Created ACTION-727 - Work with dimitr re a web components calls/meetings [on Arthur Barstow - due 2014-04-18].
<scribe> ACTION: artb setup semi regular meeting for web components [recorded in http://www.w3.org/2014/04/11-webapps-minutes.html#action02]
<trackbot> Created ACTION-728 - Setup semi regular meeting for web components [on Arthur Barstow - due 2014-04-18].
UNKNOWN_SPEAKER: automatic upgrade of custom elements
dglazkov: I'd like to present a use case for this..
... after an element is registered
... section 7 in spec, step #7 (run element upgrade algo)
If an element in or outside of a tree when the registation comes around the element will take the right shape
The key use case was that when we would run queryselector would not work (shadow doms)
scribe: we wanted to make this easier for devs
The side effect is that a sync loaded document, framework devs want to get to a consistent state and don't want to do extra work
scribe: When I talked to amber, they were very unhappy I removed this from the spec (which I didn't) and then they were very happy
... They don't want to have to deal with ambiguity when this element will be completed
It's basically queryselectorall'ible everywhere
mjs: Some people from apple don't like this...
... You want to load some custom element - three problems
... web page load parse is slow, forces UA do display partial display
... Manually have to go check or manually upgrade these elements
If you just want to know when the state is done and complete
scribe: you could wait until all are done loading, not optimal, if one set if slow
The third option is what is in the spec, if you access the element before the upgrade has been complete you have a problem
scribe: which is a hazard - accessing an html element proto
... so you have to wait
Either way you better not do any scripting untill all is complete
dglazkov: The key part you can access this until the upgrade has completed
mjs: you can't save a ref
dgazkov: it will always be the same ref
scribe: we ensure the swizzle only adds more items on top of the proto
mjs: Let me ask a clarifying question..
dglazkov: you can't go from select to my custom select
mjs: can you not only do this with a generic html element?
dglazkov: you need to specificaly call to extend select
... this make sure that you only insert items at the top of the prototype chain
... Then you can save, set prop, to the elements, etc...
... before the upgrade
mjs: It seem that from the 3 possible choices, we don't want the bad perf.
... you have the hazard or you get the work done but the the proto-type may not be perfect until the upgrade is complete
... It's not required but a nice to have in the base system
dglazkov: We have to make sure that with multiple frameworks need a single 'go'
mjs: one for of this would be a single event for all is one possible solution, not that I'm saying this is the best solution
alex: feedback from users has been pretty strong that not having this ability is bad
mjs: how we choose to do 'science' compared to asks from feedback?
rniwa: For page that use the old style (display:none)..
dglazkov: that has never been the case - psudeo - unresolved whould be the 'match'
rniwa: so now if you have some component that load sync, you have to have some style that uses component
<slightlyoff> (I also added that strong feedback across multiple toolkits/users is distinct from weak feedback)
dglazkov: this is not a problem at least in webkit and blink
... the problem we have seen is you really can only do display:none or a block
rniwa: let me make my point
... if the author had to specify the style for an unresolved element, which will not be consistent on page load times
... Their is basically no way to get consistent results of the element rendering
dglazkov: This has nothing related to upgrade mechanism
mjs: one use case, could be a select control that shows up like a map
... before the upgrade it would look ugly until the upgrade has occured.
... even display: none would be ugly
... no real way exists to fix this problem
alex: we shoud ask css to help to get a mechanism to be in control of the display/paint/rendering can start
dglazkov: web devs do bad patterns to try to control this pattern, like in editing..
... one framework uses document.write...
rniwa: can we take this upgrade to the mailig list?
dglazkov: sure
rniwa: To help close on the flash of styling issues
<dglazkov> smaug: are you there?
<smaug> just a sec
yves will now scribe!
<Yves> scribe: Yves
<smaug> now
<smaug> good
<dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887
<dglazkov> https://etherpad.mozilla.org/RKukNtHHlO
rniwa: issue is about nested shadow dom
dglazkov: etherpad above has canonical examples
rniwa: why firing the event at the last insertion point is not enough?
dglazkov: as the insertion point is at the most nested place, the nesting shadow tree does not hear the event
one solution was to generate interim div to listen to the insertion point, which is bad as well
the specs breaks the invariant that item in the even path are always children of the next item
rniwa: is the spec bz's proposal?
dglazkov: no it's the other one
<smaug> ++ rniwa
(Hayato Ito describes the alg)
Hayato: the second algorithm has more complexity
dglazkov: I agree that preserving the invariant is desirable
<smaug> more ++ to rniwa
<smaug> rniwa: were you surprised somehow?
rniwa: to me, bz's proposal make more sense. Much easier for developers
ArtB: looks like we have a way forward here
maciej: how about discussing encapsulation?
<darobin> ScribeNick: darobin
<mjs> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0312.html
mjs: back in Dec 2012 we had a big discussion about Components and traversability of the shadow DOM and how that relates to encapsulation
... the upshot was this
... previous to that the shadow was not traversable from the outside, after it was
... we tentatively agreed that it made sense to provide both public and private modes, and even a more isolated mode
... I would really like it if at least the public and private mode could both be supported
... isolated mode has some design that needs to be investigates
... private might be the wrong name, give the impression of a security boundary, we could say open/closed
... I'd really like to address this before it's too late to make changes to how shadowRoots work
... what can I do to help move this forward?
dglazkov: I totally want to do these modes
... because of the opacity of the style engine we don't have a great way of controlling this
... in JS it's easy
... but for styling we don't have a way to prevent this
... I understand the need for it, I want to add it to the spec
... I can make it the next thing I work on
<dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144
dglazkov: the way I thought I'd tackle this problem
... today you don't pass anythin when you create a shadow
... we could pass in a property bag
mjs: I would suggest a string value so that we can add isolated later
dglazkov: maybe we could close style separately
mjs: there are interesting side effects with querySelection then
dglazkov: so it could be a single flag
... the ability to look inside is important because tools need introspection
mjs: it doesn't make sense to do these separately (matching selectors, looking into the DOM)
... because you can use one to do the other
dglazkov: I think that's reasonable
mjs: if it's a string, we can add one later. Scales better than bag of booleans
dglazkov: we have to prevent people to style into built-in element, so we have this mode
... to me it was literally a matter of getting to do this, got distracted
... I can start working on this
mjs: I'm willing to offer help with reading, implementing, etc.
... I'm very interested in getting this in
... I thikn it's a fundamental building block for fully isolated components, which I think are a great use case
dglazkov: I've also been looking at implementing all the HTML elements as custom elements
... so this is useful for that too
<hober> MikeSmith: I went to create a bug on the Shadow Styling spec, blocked on 20144, but there's no component for it in Bugzilla.
rniwa: should we discuss which should be the default?
[hilarity ensues]
mjs: let's do the uncontroversial part first, debate later
dglazkov: next?
mjs: isolation?
dglazkov: I would like insight
mjs: one thing I noted in the bug
... there are 2 things you need, DOM encapsulation, and a walled-off scripting environment
... no global namespace, clean prototypes
<falken> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16509
mjs: you also need sanitising paramters passed in and their return values from methods
... you need to rewrap DOM nodes across the boundary
... so you need Structured Clone Plus
... otherwise you can pass trapped values
dglazkov: I think you're right.... eventually
mjs: if you want the page to be protected, you need a support mechanism other than script tag
... you need to run script safely
... XBL2 has a way of addressing things, you can import things
... pretty different from HTML Import which has script run in your context
... for safe imports you need a different mechanism
dglazkov: there's a proposal for a DOMWorker
... a Worker that runs in your thread in step
... postMessaging only, can be loaded x-origin
... but once loaded is in its own worker
mjs: can it export its registration?
dglazkov: no, it works in its own shadow
... the worker manages the element
... the element acts from the outside as if it has a shadow tree but you can't get to it
... but from the inside it has a shadowRoot
mjs: that seems insufficient
... you need to be able to register from the inside and sanitisation at the boundary
slightlyoff: you can get that by reducing the surface area to attributes
... forward the attribute changes
mjs: if your goal is to implement HTML this is not enough, elements need to expose APIs
dglazkov: I feel that HTML elements don't need that
mjs: e.g. video and canvas are useless without APIs
dglazkov: yes, but HTML does not need isolation
... isolation is collaboration between components that don't trust one another
... it seems to me the HTML elements model is different
mjs: HTML elements certainly don't trust the page
... but I'm not sure that saves you a lot of complexity
... HTML element have a membrane where elements are sanitised, more than cloning since it supports DOM nodes and such
dglazkov: you could define an IDL for contract
rniwa: in a way yes, we can create a wrapper object for the prototype and function calls are forwarded after sanitisation
mjs: in and out values get converted in the same way as they do for JS/C++ communication
slightlyoff: only asynchronous?
mjs: that's not powerful enough to implement HTML
... do we need to be able to do HTML, or is "like HTML but asynchronous" enough?
dglazkov: I'd like to be able to implement HTML
... as an aspirational goal, though maybe not reached
mjs: I think it's not impossible
... XBL had something that was powerful enough
... it's a question of what you're willing to give up
... if DOM Workers are already in the same thread, then you don't lose much by allowing sync methods
... it's important to be clear on whether something is an actual goal
... as a reviewer I need to know what the goals are
dglazkov: so I think it's an actual goal
... is the [Like] button thing the same scenario
... as the built-in HTML elements
mjs: the like widget case it needs communication with the communication case
... it would likely not be a dealbreaker to be limited to async and certain data type
... HTML elements need sanitisation on the way in
... returning values also, don't want anyone to violate my internal prototype
... the only thing that the like widget stuff doesn't need is sync communication
... so I think they're similar enough that you could use the same plumbing
slightlyoff: we will probably have to rely on ES6 Proxies to define the membrane
rniwa: if we really want to make everything async, we could have the wrapper return a Promise, and resolve when the method returns
... there are many ways to solve the issue
dglazkov: structure this goal as this
... we at the limit want to implement all of the HTML elements in JS
... similar widgets with trust issues are lower-fidelity subcases of the same
rniwa: I'm not sure I agree with this, there are some really funky HTLM elements, do you want to implement <custom-script>?
mjs: it's hard because either they'd have to be implemented in terms of existing elements or you'd need new primitives
... also you don't want them to be able to change their parsing, e.g. reimplementing <table> or <script>
... altering behaviour of the parser is beyond membranes
dglazkov: the reason you need these membranes is because inside of the element are capabilities you don't want to leak to the author
mjs: that's a security issue
... but there's also a robustness issue where if you pass a bad value you don't want a component to barf all over itself
... you need a membrane for that
dglazkov: I don't think this is a major point
... I understand what you're saying
... agree 100% on the membrane ideas
... I'm signing up to do this
<krisk> s/idase/ideas/
mjs: we have to limit ourselves to createElement because the parser is funky, and we have to exclude some unsafe primitives like <input type=file>
... we need a more fleshed out spec for security review
slightlyoff: this sort of primitive allows for all sorts of attacks
mjs: there are some existing systems that take control of everything and try to sanitise everything
slightlyoff: our experience is that that's very brittle
mjs: I tend to be wary of things that are complex and need to be gotten exactly right
... we can make the method membrane isomorphic to postMessage, using the method name as a string
... so it's not necessarily a bigger surface than postMessage
[LUNCH]
<smaug> thanks all
<adrianba> scribe: BenjamP
<Yves> scribenick: BenjamP_
<sicking> rniwa: hey, sorry i didn't make it down today
<sicking> something came up
dglazkov: let's spend time on imperative api
<sicking> rniwa: imperative API ++
<dglazkov> https://gist.github.com/dglazkov/ce96f673b0b2ce7b8c55
the following is based on the doc linked above- Distribution Callback section.
dglazkov: we don't know when to run the callback
... this has to do with how the box trees compose. Previously, we don't have to compute style until later, we can defer it. But problem is we have to run it the callback when you query the property.
rniwa: I think it's worse
dglazkov: we have an array or add/remove methods. The array can be the filter. The problem is the author has to implement the distribution algorithm by hand. <details> has to set a mutation observer.
... another (bad) idea is selector-based routing. Insert children based on selector
<dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429#c4
dglazkov: this bug shows combination of passive array and selector-based rounting
... so 4 total ideas here. Looking for thoughts
rniwa: let's have a list of candidates and notify author when it changes.
dglazkov: we could get stuck in 2-resolution loop
rniwa: not necessarily. Distribution doesn't need to be synchronous. We could instead compose at the end and notify all. It's okay because we won't paint during the micro-task
dglaskov: we don't want it to return 0 because it hasn't rendered. [in steps], what is offset top? Would be zero. This gives ability to reason about what's happening when things are added to the DOM, and you'll see them later.
... author won't know if it has run or not
rniwa: similar to custom elements unresolved state
... don't want to expose timing in engine. Synchronous costs perf, async we'll have times when things aren't up to date
dglaskov: this doesn't matter for routing
... conceptual model is css
... run it at the end of micro-task. I don't think that's unreasonable. But let's make sure we not confusing users mental model
rniwa: selector-based routing has an expensive query, doesn't address random element use case
dglaskov: random is solved by selectors. When you create a router you define random
rniwa: you have to listen to mutations of your children
dglaskov: no you don't
rniwa: inserting elements should not break the selection
dglaskov: valid point
... you'll sometime have ocasional inconsistency with imperative. That's okay.
... style resolution after callback?
... you could trigger it, but it doesn't typically need to run before callback
rniwa: there are times you want to stay in sync and have them happen at the same time
dglaskov: insertion point needs an onDistrobution event
rniwa: I agree it's weird to get wrong offsetTop, but our options are limited
hayato: it's a tough issue
dglaskov: if you choose imperative, it may be difficult, but that's ok
... not sure if this is a problem in real life
ArtB: carbos for lunch syndrome
<krisk> +Bacon please
<dglazkov> https://gist.github.com/omo/9986103
dglaskov: let's talk about blocking rendering
<ArtB> https://gist.github.com/omo/9986103 -> HTML Imports: Discussion over Async/Progressive Loading
dglaskov: imports are modeled after stylesheets
... trying to enable asynchronous loading, but sometimes we have to block
... if you have a script block in you doc, your loading imports will be sync with script.
... without <script> it will load in parallel, and will then block on paint
Alex: this is not a rule
dglaskov: right, but everyone does this
<slightlyoff> BenjamP_: s/dglaskov/dglazkov/
dglazkov: *pounds fist*
... async loading makes other elements change. We've only had sync loading until now, so we didn't see this
... example: twitter doesn't want to block. So we invented async
... still some disagree about default sync/async
Alex: speaking for pro-async. Agree that there are 2 different types of users- own the whole page or don't
... even for not-own-whole-page: makes sense to enable doc fade-in. What does it take to achieve? With sync/async: you have little control so you write your own staging code. Works around sync/async order
rniwa: what are you ordering?
Alex: if building an app: need to pull in code, elements, etc, have an early moment when I want to control (inline script), then pull in dependencies (async). Should we paint early while it's loading, and then paint again when all is available?
... if you're small part of the doc, you want to be able to say when you're ready and provide a placeholder
rniwa: 3 state: unresolved, resolved, final
... which part are you talking about?
Alex: they're all related
... blocking causes you to have to choose what you are targeting
<slightlyoff> e.g., how would you reason about a hierarchy of things that all need resolution? As Jake Archibald phrases it, the "deeply resolved question"
dglazkov: example- if I'm a framework, you have to load basic concepts quickly and do first paint (loading screen?). Then do more things because I've notified the users I'm getting ready. With HTML imports you have 1 sync import that does the quick first paint.
... I want to allow developers to draw a line and say "i want to paint here". Everyone has a 2 phase approach
rniwa: this isn't unique to imports
<slightlyoff> one way to think about this is trying to provide explicit API for defining resolution
dglazkov: the problem is that they have to fall off the html train right away
... let's think abou this. we won' t solve it here
Alex: we're missing a primitve, We want to define resolution. sync/async allow us to create 2 moments- now and later. You're now missing the ability to describe what happens when you get to the resolution
rniwa: waiting is a special case; normal state is the final state.
Alex: there is a final moment that we should be able to reason about in the code. We don't have resolved/unresolved except for custom elements.
... we don't have a way to talk about dependencies
rniwa: if you implement a custom image element, the browser can't reason about when it's ready
... maybe we should load a pseudo element?
dglazkov: I'm fine letting developers solve this first and learn from it
Alex: decision at first paint needs developer control. Should be able to delay paint until dev is ready
<dglazkov> esprehn!!!
<esprehn> dglazkov: :)
<slightlyoff> scribe: slightlyoff
dglazkov: I forgot something about imports...will need to bring it up on the list
(discussion about next topic, perhaps inheritance)
rniwa: one problem we found with the current inheritance model is that if you have an element, say a <random-> element, if you have a subclass that wants to use a different distribution...the <random-> element wants to show the name it's subclassed distribution
... you don't have a way to add an insertion point in shadow DOM that's only available in the subclasses
... if I have some bit of content that needs to be transcluded in the shadow dom to the subclass from the parent class, how do you do that?
dglazkov: you have all the tools....
rniwa: how do I set an insertion point that's only for the subclass?
dglazkov: that will be coming from the light dom?
rniwa: no, it's coming from the subclass
... the way to do it today is to replace the entire shadow dom and place your own things inside it
dglazkov: yes, you have to make sure that your concrete subclasses aren't of other concrete classes
rniwa: even if you use an abstract class, the selectors that might match aren't constrained
... if you have a <uniformally-random> element and a <gaussian-random> element, and the superclass has a distributionName, you can't make sure that you only handle the property in the shadow dom of hte subclass, not the parent class
(esphren joins)
dglazkov: (revisiting distribution question since we have esphren)
esprehn: my issue with the delayed distribution is that it doesn't describe what <details> does
... today if you append to it and then query offsetTop, we'll give you answer immediately
... we only do this at recalc-style time
slightlyoff: we have a "takeRecords()" in O.o and Mutation Observer,s why istn't that model workable here?
esprehn: we don't have a defined time in the platform for this
slightlyoff: so we're missing an API for this kicking off callbacks?
dglazkov: so appendChild() is when thigns become real
esprehn: we'd need to make sure that children of the <details> element don't have layout information until rAF time
... we have a strong guarantee about shadow roots being unobservable, which isn't true today, and we'd be making it observable
... if we allow scripts to do arbitrary things, we need to define a time for it
slightlyoff: are those things (offsetTop, etc.) bugs or features?
esprehn: I'd like to make sure that <details> isn't magical
slightlyoff: agreed
(discussions of topics and group stamina)
<esprehn> sorry I have to run, but I'm happy to discuss further in the future
dglazkov: next issue: 3 quick bugs
... in my opinion, all of the import documents should be forced to be UTF-8
... we don't have the usual issues around legacy, so we'll just assume UTF-8...what say we?
<ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21275 -> [Imports]: Force utf-8
dglazkov: developers get unhappy about needing to include explicit encoding
(charset meta)
dglazkov: we'd like to be able to assume UTF8
MikeSmith: we're going to fallback to windows 1252 if you don't specify something else, which is wrong
hober: it's a bit weird because it's inconsistent, and the existing behavior isn't something we like...I can see this going either way
rniwa: what about XHR?
... matching behavior with XHR might be good. If this is truly odball, it might be confusing
dglazkov: (quotes annevk): "UTF8 should be used for anything new"
(HTML, a celebration of inconsistencies)
hober, MikeSmith: no objection in the room
<ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24349 -> [imports]: Import documents should always be in no-quirks mode
rniwa: I'm not sure I'd object
hober: webvtt is already always UTF8
adrianba: it's not HTML
MikeSmith: I'd recommend that if you feel strongly, participate in the bug
slightlyoff: (looking at bug history) when will this be resolved?
dglazkov: next topic: import documents should always be in no-quirks-mode
(not exactly resolved, 'because we can't do that)
dglazkov: next topic: blocking DOMContentLoaded while imports load
<ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23526 -> [imports]: blocking DOMContentLoaded while HTML imports are loaded
morrita: not sure about the context either...
... some folks are using this event without waiting for things like <img>
... there's no event that's similar to imports already
rniwa: presumably this is only for the sync case?
morrita: yes
dglazkov: I only got context on this recently and I don't know...do we need a new event?
slightlyoff: don't want to design a feature here, but I can see both cases
rniwa: <script defer> does block DOMCOntentLoaded
... this is similar to that
... in that sense, blocking it on imports seems right in the sync case
(starting gun fires)
ArtB: thanks to dglazkov for taking the time
dglazkov: I'll be getting back to spec work shortly, thank you
thanks to Brad Hill for hosting
(applause)
<MikeSmith> yeah much thanks to Brad and to PayPal for hosting
<dglazkov> THANK YOU EVERYONE!!!
<dglazkov> I <3 YOU!!!