W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

[April2014Meeting] Draft minutes for April 11

From: Yves Lafon <ylafon@w3.org>
Date: Fri, 11 Apr 2014 21:19:43 -0400 (EDT)
To: public-webapps@w3.org
Message-ID: <alpine.DEB.2.00.1404112117140.22597@wnl.j3.bet>
The Draft minutes from WebApps' April 11 f2f meeting are at the
following and copied below:

<http://www.w3.org/2014/04/11-webapps-minutes.html>

Corrections, comments, etc., are welcome.

Thanks very much to the various scribes and special thanks to Kris for 
handing me the missing minutes.


W3C

- DRAFT -

WebApps f2f Meeting (San Jose CA US)

11 Apr 2014

Agenda

See also: IRC log

Attendees

Present
anssik, [Paypal], +1.301.460.aaaa, Arnaud_Braud, Takeshi_Yoshino, krisk, 
dglazkov, israel, hilerio, Art_Barstow, Anssi_Kostiainen, Ali_Alabbas, 
Yves_Lafon, Chris_Wilson, israel_hilerio, Feras_Moussa, MichaelTmSmith, 
John_Hazen, Matt_Falkenhagen, Ben_Peters, Adrian_Bateman, Hayato_Ito, 
Zhiqiang_Zhang, Olivier_Potonniee, Gene_Lian, Jungkee_Song, Maciej, 
Laszlo_Gombos, Alex_Russell
Regrets
Chair
ArtB
Scribe
Art, israelh, Ali, krisk, Yves, BenjamP, slightlyoff
Contents

Topics
Web Components
Custom Elements
Shadow Dom
imports
conclusion
Summary of Action Items
<ArtB> ScribeNick: ArtB
<scribe> Scribe: Art
<dglazkov> 
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0074.html
<smaug> hello all
Web Components

<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> 
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Element.idl
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].
Custom Elements

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


.The swizzle doesn't modify the change...
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

Shadow Dom

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

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

conclusion

<MikeSmith> yeah much thanks to Brad and to PayPal for hosting
<dglazkov> THANK YOU EVERYONE!!!
<dglazkov> I <3 YOU!!!
Summary of Action Items

[NEW] ACTION: artb setup semi regular meeting for web components [recorded 
in http://www.w3.org/2014/04/11-webapps-minutes.html#action02]
[NEW] ACTION: barstow work with Dimitr re a Web Components calls/meetings 
[recorded in http://www.w3.org/2014/04/11-webapps-minutes.html#action01]

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-04-12 01:14:50 $


-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves
Received on Saturday, 12 April 2014 01:19:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC