- From: Yves Lafon <ylafon@w3.org>
- Date: Fri, 11 Apr 2014 21:19:43 -0400 (EDT)
- To: public-webapps@w3.org
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