Web Platform WG F2F -- 26 Oct 2015

<inserted> scribe: timeless

Agenda Bashing for Tuesday

chaals: now is your chance to say "let's have more of ..."

mvickers: Mark Vickers, Comcast
... seems the chartering process, there was a document on at one point, and dropped at one point, "Sourcing in Band Data" it's referenced in HTML5
... process problem
... I think it would be done here
... like you said, I didn't want it to get forgotten, and it's now not forgotten

adrianba: I think that's a question for the Timed Media WG Chartering Process
... conclusion of discussions there will determine whether it's there or here

chaals: We've inherited everything from HTML except Media stuff
... future of Media stuff is unclear
... more generally, this group will only exist for less than a year
... by next year we will have to recharter
... it's quite possible we will recharter
... what goes into that group and how we build it, no one really knows
... we're looking for people's input
... one of the things I think the chairs are looking towards
... we don't want to have stuff that no one's interested in
... if no one is going to work on something, then it obviously doesn't matter
... if you're waiting for the Web Platform WG to do something you think is important, then you're doing it wrong
... the Group won't do it unless you say that you're going to do the work
... and if only one person says that, we'll say there's one person and they should go off and do a PhD
... this is an industry, if you don't get the web working, we don't want it
... we want input on the web
... one of those things is what do we do about HTML
... what does HTML need?
... what bits are broken and should be actually fixed
... if you think none, then, ...
... I expect the editing guys to find time and put themselves in our agenda
... I don't see any hands

ES Modules and HTML

chaals: I'm blaming hober

hober: rniwa is on a train and won't be here until 9:30

adrianba: we also need to figure out how to dial into the WebEx

chaals: our staff contacts who provide tech support are going to be asked to make sure we get onto WebEx, yves...

yves: ...

chaals: let's wait until 9:30

[ Break ]

<hjin> #webapps

<dcooney> present

ES6 modules and HTML

<adrianba> ScribeNick: dcooney

<JakeA> hober: mjs: are either of you coming to the SW meeting?

rnwia: we are interested in proceeding with ES6 module integration with HTML

rniwa: we have completed our ES6 module integration

<smaug> JakeA: curious, is there an irc channel for SW stuff? I might lurk somewhere in the background (only IRC)

Does anyone know the status of how integration into HTML works?

<Mek> smaug: #serviceworker on freenode

chaals: We don't really know. There are things we want to put in including not limited to ES6 modules. but we need to find a path forward.

adrianba: The key question: Mozilla had comments about lack of interest in HTML imports because of the conflict; there's a whatwg loader spec that talks about how to load modules.
... the critical common feature is both try to find out the dependency chain of modules to load them
... it does not make sense to have two; we have to find out how to integrate them

travis: I looked at the loader document; it has many todos and details without scenarios
... I agree with adrianba it is essentially a way to load dependencies--scripts that load modules
... it aspires to be a generic mechanism for transitive loading with hooks and interceptions for transformation
... not sure it is ready yet and whether all of those use cases are requirements for getting a basic module loader done
... Mozilla perhaps wants to comment because of some concerns
... I don't know that theres a problem with having HTML Imports and Loader running simultaneously; they both order things. Imports does interesting things with executing script in html in the context of the page which makes the case seem a bit orthogonal to loader.

adrianba: they're not coincident but there is overlap
... if there's an algorithm for walking the dependency chain, working how it integrated with HTTP2, so there's one way. Especially since HTML Imports has the ability to include script.
... we should not pursue in parallel; they need coordination

travis: but it's not rocket science; there's a list, it is deduped

adriandba: (missed something)

MikkoT: Mikko Terho, Huawei
... there are a lot of problems in web of things, internet of things, with the hierarchy of loaders
... my preferred personal approach is Linux/C++ at the base, a standalone JS engine on top, browser as the third layer
... all loaders should have defences against malicious software
... this is the largest issue for the web platform IMHO and IoT
... I recommend parallel loader work that only depends on JavaScript and not HTML

chaals: trivial response, is the web platform part of the internet of things? Yes. Otherwise we're going to see Big Issues down the line.
... I agree they have to line up; who's going to do the work?

<JakeA> smaug: Notes are in https://docs.google.com/document/d/1AyfTNw8TyOXPNP4nk1Y93XMqdTt6PTbeE39NyCP_J5M/edit#heading=h.twg98oxj5t9s

adrianba: The issue is the ECMAScript committee has said how modules get loaded is dependent on the host

<yusukesuzuki> i think we need to discuss,

adrianba: I don't think it is feasible to have an independent module loader that exists outside the browser.
... It would be fine to have some similaritites but the practicalities of how you get to the modules depends on the host environment.
... browser needs to coordinate script, css, etc. and node.js does not have these concerns; the situation is different.

<yusukesuzuki> 1. fix the module tag syntax. how to write the module tag? src="" / import=""? how to care about the old script tag's charset, crossorigin, etc.?

rniwa: are you suggesting no standards, multiple standards?

<yusukesuzuki> https://github.com/whatwg/loader/issues/83

adrianba: when loading ES modules in the browser, how do we coordinate with other resources? That's what alignment with HTML Imports is about.
... The idea we can spec that at a layer lower than the browser, if I'm loading modules in node, it doesn't need to worry about loading CSS.
... My understanding about ES6 standard it describes how modules interact but not how they are loaded; that varies by host environment.
... We should think about it from a web platform point of view. Different host environments have different considerations.

<rniwa> https://github.com/whatwg/loader/issues/83

rniwa: see yusukesuzuki's comment re: GH issue 83

<yusukesuzuki> 2. how to integrate the other non-JS modules into the module loader? we have wasm and i believe that we need to load it through the module loader.

rniwa: I agree there's an issue with loaders in general. We don't have a concrete spec. We don't need to spec 100% of that to make the common module use case to work.
... if we can agree on the part how scripts are loaded, each module are loaded, that is sufficient. We don't need to define the interrelationship between loading resources.

travis: Is the process of loading modules expected to be synchronous? load foo, can the next statement depend on foo?

rniwa: Async I think. ... There's a mechanism where you load all the dependencies asynchronously and run them synchronously in such and such an order.

<yusukesuzuki> And, for (1), i believe that we need to specify some part of module loader tag in the HTML spec to start implementing it.

travis: HTML has a script running order, it may do some things async, so you need to make it consistent that's the issue

rniwa: We don't want to run scripts in a random order

travis: The Loader spec doesn't cover that; and HTML does not describe how to handle modules.
... do you extend HTML? Do you split it out and try to extract the HTML things into a separate document that also includes the module things?

chaals: One way or another we need to pull the pieces out, write them down, and implement them the same way.

<yusukesuzuki> 3. deterministic execution order between multiple module tags. https://github.com/whatwg/loader/issues/85 script tag's async like? or defer like? should we wait DOM content loaded like defer?

chaals: my general sense is lets not go on editing a 1,000 page document than nobody has read entirely.
... pull out the pieces that you need and make an extension or change piece of what we have.
... and produce a smaller thing that someone can read because that bit matters.

travis: a union of what's in loader and what's in HTML is complex

chaals: chair hears travis volunteer

rniwa: two issues--how to integrate web assembly into loading; other is deterministic module load order between multiple module tags
... ES6 does not have the situation HTML has with multiple script tags
... (this pertains to issue 83)

<aklein> btw, am trying to join via various means

<yusukesuzuki> https://github.com/whatwg/loader/issues/83#issuecomment-143143195

travis: the loader spec had started talking about builtin modules with name/subname eg std/math for the math module; there's at early attempt at least. Incomplete.

rniwa: That's slightly different; if you have @import std/stuff you can still conceptually treat that as loading a module.
... whereas outside of a script, you may have multiple ones that need to be ordered, for example async script does not guarantee ordering.
... issue 83 is suggesting that in the case of modules we need to have deterministic order
... and the first comment suggests treating it as script defer where it is async but the order is guaranteed.

travis: I see that random order, full async is an issue.

chaals: How is it a problem?

travis: In HTML when you use async the contract is that nothing the async script does depends on anything else. It might be the JS module pattern or something. It might have the requirement of coming in before the load event.
... in es6 modules you might be able to use modules loaded before you; I'm not sure how it works with std modules.
... unless you opt-out of that requirement you should get it.
... So you don't introduce dependency modules.

aklein: Adam Klein, I just joined, but I can't hear well

chaals: dominic is a WONDERFUL scribe, he's awesome.

travis: who is the author of the current loader spec? domenic denicola? there's no author listed but it is his style

chaals: one question--can we leave that to run its course? Do we need to try to make a spec?
... you know what comes next

travis: If the loader continues in its current path, it won't address what we care about, ie HTML loading of things plus module loading of things

chaals: we need someone to write this up

rniwa: is mozilla here? chaals: probably at Service Workers dominicc: annevk had regrets on irc
... is this the right WG to work on this, at least?

chaals: yes.

rniwa: One thing we need to figure out is the editor and main contributors are not here. Maybe we need to take this offline.
... Figure out who could be specing module resolution, script resolution.

<adrianba> +1

rniwa: Whether that be in what WG, web platform, etc.

travis: Who did it in HTML Imports? Dimitri?

hayato: We are looking for a new editor; there is no active editor for HTML Imports.

chaals: Please put present+ and your name; we did not do introductions. Today is going to be disjointed.
... will rniwa take an action to talk to domenic denicola or whoever authored imports?
... suggest we wrap up, without the right people in the room

[ Break time, back at 11:15 ]

chaals: after we are back, a short agenda request, status of editing. "Almost no problems" except how to deal with IME.
... Watch the agenda for changes. We might have another addition.

[ Break until 11:15 ]

[ i.e. one hour, 13 minutes ]

Agenda edits

<hayato> I've summarized the 'Cascading Order for Shadow DOM v1' proposals: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order-in-v1.md

<hayato> That will be one of the topics today. Please take a look at it before the session: CSS and Shadow DOM.

<dka> Scribe: Dan A.

<dka> ScribeNick: dka

Charles: topics, pointer events or touch events - do they need to be updated?

… & should the working group add them to the list of things we’re doing?

… we have a charter that describes the work we can do. We can add things to it by sending a proposal to w3c members for review.

… we cannot do work that is not on our charter [because patents].

… so shoul we take this on? and if we do, will w3c members let us do it here?

… it seems clear given that we work on e.g. ui events, keyboard events that other interaction events are part of our scope. Question is should we put these into our chater?

… any opinions?

[stony silence]

… my view as Yandex is that it would be useful to work on this. Yandex formally objected to pointer events spec [for reasons] so we would like a new piece of work to bring that stuff together. I would like it to go in this charter.

mjs: Apple would object.

charles: no driving desire to have this work done.

RESOLUTION: do not add pointer / touch events to charter at this time.

Report from Editing Taskforce

chaals:

Johannes: im an invited expert - i’ve been working on one editor since 2012. We tried to get browsers to fix things so we ended up in this task force. Task force was established in June 2014… goal to allow for complex editors to override default behavior of content editiable.

… problem with content edititable is that it’s not well specified, behaves differently in every browser and it’s broken on many levels. At the same time you cannot make an editor that does not use it at some level.

… The amount of editors that exist is not that large. 10-15 that have almost all market share. Most people think it’s easy to make such an editor but [it’s not.]

… We want to make it slightly easier.

… what have we done since last year? There are many strong opinions here. We’ve had 3 meetings [to get consensus] - one at the Extensible Web Summit.

… current state - we’ve figured out we want to have device independent events - events fired when the user wants to do some action.

… we do not define what triggers these events. Browser developer has to figure out what triggers it. We do specify 2 events for each one before and one after the change to the DOM.

… The properties it has is data. If you add something it will be the charater you add. It will have a target range [relating to selection].

Chaals: find & replace is another example.

Johannes: edit type; isComposing; cancelable.

… some things are not cancelable.

… we tried to make a basic level that javascript can hook into and create an editor on top. We’ve defined 3 levels: (1) just events (2) caret - same plus caret movement (3) typing - caret + add characters to text nodes & delete content

… “True” combines all of them.

… might take 150 years to define. It’s future work.

… So what still needs to be figured out? Names of events; list of edit types; IME support

… main important things on IME support - 1) we need to be able to add new content when the composition starts 2) atomic commits (e.g. in collaborative editor)

… 3) when recomposing words… handled differently on desktop and mobile [browsers]

… 4) a proposal to allow the movement of the carot into a shadow DOM element.

… (feedback from Google is that this is problematic)

… 5) [another proposal documented on slides]

<scribe> ?: new proposal I made was to let web apps modify the dom - you want to give full control of dom to webapps but if you want to make IME functional - specifically in japanese and chinese IME behaves differently. One approach is to let webapps communicate this back to browser but this is fragile. Easier way is for browser to look at contents. As long as webapp can keep the text in the DOM then … [?]

… some open questions ....

Johannes: last question is - which is the mode we will focus on most? Events, caret or typing?

… we have a meeting tomorrow. Most editors for some reason based in Europe. I suspect we will have a lot of voice calls.

Chaals: If we have a f2f likely to be in Europe.

… any questions?

… my question: you’d like to do the most complete one we can get?

Johannes: I think typing only makes sense if it makes sense for the IME.

… otherwise the editor people think caret movement is important. I personally don’t think it’s so important, but majority thinks it is. So we might go for caret instead.

?: the reason we tried to do typing - intiially we wanted to do events. We couldn’t figure out how to do IME.

[debate on IME]

IME stands for Input Method Editor.

rniwa: because of that we went to input=typing to work around that we couldn’t expose styling information.

<karl> https://en.wikipedia.org/wiki/Input_method

rniwa: in advanced word processors you can use custom justification. if you want to do that in web [it’s complicated]. If you did that [it would be complicated for the IME].

kochi: in Android IME tries to see the whole editing text. For example if you type in some characters adding to previous text - then Android keyboard IME tries to read it. It needs to communicate… in addition not just getting previous text - if you start in the middle of a word - if you start composition - so when you start typing the keyboard may underline whole word.

Johannes: that’s been one of the compications. It not only does that.

… … that’s one of the most problematic chases we’re trying to solve.

rniwa: while in the common case [that is unique to android] in the case where you want to do recomposition you still have that problem. The android problem could be modeled as recomposition (of the entire word).

Chaals: a spell checker or gammar checker does the same thing.

Johannes: the spellchecker in Androind has different word bounderies than the IME. In some cases words can cross DOM bounderies. But some DOM bounderies have a meaning you cannot just cross.

<dcooney> yosin (not in IRC?)

yosin: question on selection ranges in the document - replacement of existing dom nodes?

Johannes: if something is sleected and then you start typing - two events - one to delete and another to add new characters.
... editors now a-days all implement deletion of [content content selections]… editors are fine with doing this. Rather they do it than browsers do it.

Yosin: browser has default action for typing.

rniwa: all those actions are incompatible among browsers. we don’t want browser to modify dom.

Yosin: what is the difference between typing and events?

rniwa: we just fire the event and browser modifies the dom.

Chaals: in content editable typing you have to split it up: first you delete and then you start adding content.

… the deault…

… in events the browser doesn’t put the characters into the document.

Yosin: typing does the replacement?

Johannes: say you select something - 2 paras. Then you start typing. First you get a delete event. Javascript has to handle the deletion. Then the browser does the part of inserting the character.
... editors can do weird stuff and we can’t stop them.

timeless: an editor might take a “P” and turn it into a cyrilic, hebrew, arabic, etc.. letter.

Chaals: In Yandex we do this. If you type latin characters we might auto-complete in cyrillic [ltn => детей].

?: The IME interaction is quite complex. We still have some issues. We can’t figure out all of them to work with JS> As far as I can remember - Microsoft doesn’t want JS to handle [koji]. I want to make sure we are in consensus tomorrow.

rniwa: we cannot make webapps always … ?

<rniwa> make web apps respect editing actions requested by IME

Johannes: everyone is invited to (TPAC breakout) tomorrow on this topic.

CHaals: Lunch!

<rniwa> because web apps can always prevent all keydown events or always set innerHTML of the editor every time keyup fires

… next topic will be Web Components.

Web Components

<dcooney> ScribeNick: dcooney

chaals: Where do we start?

hayato: Is there an agenda? No? Let's start with a status update.
... In Blink, we are implementing SHadow DOM v1.
... We have a plan no deprecate Shadow DOM v0 after shipping v1. I will announce when that happens.
... Custom Elements: No significant progress. Another F2F in December.
... HTML Imports: No significant progress. We should integrate it with ES6 modules.

rniwa: It's good to have an overview of all the specifications and check the status of each WC spec.
... In terms of WebKit we have finished implementing Shadow DOM v1 except styles which we are talking about later today.
... We are prototyping Custom Elements but there are questions about instantiating viz ES6 classes, upgrade timing, whether attributes are present, whether things are in the tree or removed which have implications for iframes
... We would like to make it synchronous, it looks feasible in WebKit, we would like to know about other implementers.

travis: What is the result of prototyping with cloning trees. Is it synchronous?

rniwa: Yes.

travis: No major updates on MSFT implementation status; still preparing to start Shadow DOM.

rniwa: There are three specs, let's go over their status.
... Mozilla objected to WG chartering HTML Imports, is that right?

chaals: That is roughly correct.

rniwa: (... only Google supports HTML Imports) should we remove it from the charter?

chaals: It's easy to just not work on something and turn in into a Note. If only Google is interested in it that is a useful thing to do; it creates a record. We can recommend people don't use it. We can call for consensus on this.

travis: HTML Imports does bring benefits to components because it can contain HTML; ES6 modules are primarily script. So there is that advantage to imports.

rniwa: Do you think we should keep working on it?

travis: We should not throw it out until we figure out modules + imports + loader.
... there is a bit of overlap in dependency resolution but we don't need to throw it out yet.

rniwa: If we put HTML Imports aside and decide to bring it back later we can concentrate on ES6 module integration with HTML without the added complexity of imports.

adrianba: can Apple explain why they deprioritized imports?

rniwa: We did not have ES6 modules, ES6 modules have a big impact on how authors package scripts, we wanted to get a more firm grip about how ES6 modules are used in the wild first and then define how Imports work.

adrianba: So it is not that you're opposed to imports but you see ES6 modules as a prerequisite; you're not opposed to the declarative aspect. Personally (not for MSFT) I think declarative resonates with web developers and we should not throw away the concept but it remains to be seen if the current HTML Imports draft is the way forward, or ES6 modules is,
... or something else.
... So it should be a chartered work item, not a priority to work on the spec, but we should not forget about this use case.

rniwa: We are interested in declarative for cross origin loading; you need declarative because you can't run a scripted loader in the same origin. (refers to proposal of a few years ago?) Like you said, we need to (focus on the ES6 module case first.)

chaals: Should we park HTML Imports spec?

hayato: In Google we think HTML Imports and ES6 modules have a lot of overlap but that they solve different problems. One is for markup, etc. and one just for script. We object to removing them from the charter.

chaals: Not hearing much support to remove this from the charter. Google can continue to work on the spec, but CR promotion looks rocky because other vendors are not sounding interested.

rniwa: I would hate HTML Imports to block ES6 module -HTML integration which would be bad for web developers.

chaals: That seems reasonable; as adrianba suggested it would be nice, without it blocking, it does not seem like a good idea to ignore the question in specifying the loading.

rniwa: sure

chaals: Let's see where we get to before deciding to throw something out. Other specs?

hayato: Shadow DOM, we agree essential parts of Shadow DOM v1; there are no significant contentious bits. We're on (or in) the same boat.

rniwa: we are largely agreeing on the big picture; later today we can talk about scoping order, cascading order, I hope we will be completely ready to implement it fully.

kochi: I want to raise an issue about focus, focus movement when you hit tab keys.
... the order is usually controlled by tabindex but if Web Components have some fields that may be focused the tabbing order may be disrupted.
... the v1 spec has some notes about how tabbing order should work, but there could be additions to make it work more naturally.
... currently the tabbing order is defined as DOM tree order; if a focusable node is distributed within a component the focus order may move inside-outside-inside-outside and look random.
... we would like to have some consensus on how we should move forward on this problem.

chaals: What kind of component would have this weird focus problem?

kochi: A component has slots; some input is distributed into the slot; then tabbing should navigate from outside to inside.

(kochi goes to the whiteboard)

rniwa: If you have tabindex on a node, and its parent has shadowroot and that node is distributed into a slot in the shadow root.
... If you are tabbing from outside you can have another element before it in the tab index; where should the focus go?
... Ideally in the user's perspective, the user sees the composed tree, you should do tabbing in the composed tree.
... Using composed tree makes more sense to me; we should move the focus in composed tree order.

kochi: Agree; imagine this case:
... <input>,<div> w/ SR { slot 1, slot 2 }
... this div also has two direct children
... and input, input
... input1 in slot 2; input 2 in slot 1

rniwa: so you have an element that reorders light children in the shadow dom using slots.
... So the question is should we respect the light dom order or the reordering done by the shadow dom?

hayato: I agree using composed tree is a good user experience; but here's a problem. tabindex is not a boolean; it's a number.
... it is very difficult to get components to coordinate the indices.
... imagine a component with a very high tab index?

rniwa: didn't we say using anything with a tabindex > 0 a bad idea anyway? I have a hard time thinking of a use case when the component has a tabindex > 0?

chaals: The use case is: complex ordering structure. If you scatter elements with CSS, it is helpful to direct the focus order.
... the reason we recommend people don't use this, is that it is easy to break.
... but people who use it carefully can get a vastly superior result.

rniwa: What's the use case for reordering in a component?

chaals: First, date picker. Date pickers are awful.

The idea than navigating a document in linear order is a good thing collapses when you have a dozen points.

<Zakim> timeless, you wanted to talk about date picker

I have been taking the images out of shadow DOM, svg, and making them navigable for a screen reader. and it is bat**** insane.

<timeless> ack

timeless: I have worked on a date picker
... You can have RTL fun and the order stops being the way you expect, you might want to start on the right and exit on the left, but not do the reordering with CSS.
... or doing really shiny styling, or responding to language changes and doing these sways; I doubt Shadow DOM encourages you to tear down and rebuild the entire tree; you would use CSS and update tabindexes.
... I think that covers your datepicker nicely.

chaals: I see the problem that can arise but I am not sure of the use case that leads to this probelm.
... I see they could create a component where the navigation is more sensible; but I don't see how navigation would break.

<rniwa> +1

chaals: Allowing people to do stupid things is reasonable; it does not seem like a dangerous trap.

rniwa: I imagine we could treat shadow DOM like iframe; if you specify tabindex inside iframe it is a nested iframe, the scopes are different. We could do something like that. Specify tabindex inside shadow dom and move in that order inside the shadow DOM.

timeless: that seems reasonable to understand, I didn't understand the other thing

hayato: that's what's in the current spec

adrianba: Seems important (obvious?) for component reuse.

[ e.g. outbound and return flight dates ]

chaals: One question: Being able to do scoped tab indexing would be really really good for navigation.
... In Shadow DOM is great; doing it in general would be great. Dumb, linear, all things navigation is a big failure of the web.
... Having Shadow DOM allow it is a step.
... Maybe changing HTML is OT.

kochi: We have another scope of tab ordering. The input element's tab index scope is still the document tree's scope.

(chaals notates the diagram to put tabindex on slots AND inputs)

kochi: Slot itself is not focusable by default. Web authors may think specifying tabindex on slot influences tab navigation but it does not, at least not in Chrome today.

rniwa: I don't understand what the problem is? You want to change the ordering of the tab index in Shadow DOM, based on which slot it is assigned to?

kochi: Specifying tabindex on slot element does not control the order of tab navigation over the slotted input elements.
... The input element tab index order is controlled by the input element itself, which is the insertion point.

rniwa: Two qs: Are there use cases where you need to specify tabindex on slot? This is similar to the problem of slot not generating a CSS box. Like that, you could wrap it in a span.
... second q, when a node is assigned to a slot, we need to create other nested tab index scope for each slot, it needs to be isolated both from the slot and the shadow dom

mjs: there are two cases: what if you want to control order in the shadow dom? the nested tab index shadow scope thing is a solution.
... what if, in this case, if the tab indices are specified or not, both answers--using the tab index in the page might be reordered; if you apply the nested tab index specially you... (missing) there's no way for the consumer to not become dependent on the implementation details of the component. You need to be able to override.
... Say I have a custom element with an input element and a content slot.
... In its light DOM you have an input element that puts it into the slot.
... Say they both have an explicit tab index. How do you resolve them?
... If you apply the nested scope thing, then the abstraction is violated because the consumer has to be aware of tabindices inside the component.
... On the other hand, if you do it naively the tab index is surprising
... You need a tab index override.

<timeless> (makes sense to me)

mjs: I guess rniwa's proposal of having the slot scope tab index will work; slots are not tabbable but you could put a tabindex on it.
... hopefully I understand the problem-

hayato: that's the problem. Today, current spec, light children are navigated after navigating all elements in the shadow tree.
... It does not depend on distribution or not. (reiterates spec.)
... I know this is not ideal but we don't have an idea how to meet the user's expectation which is the composed tree based navigation order.
... ... distribution breaks everything because light children are later in document order. It's a huge unresolved problem. We need to answer this.

mjs: this thing (you described) are you suggesting it should work that way, or what the spec says. It's a terrible behaviour when light and shadow DOM have focusable stuff; even if the light and shadow dom author collude they can't get a good result. rniwa's proposal gives control, sensible results, etc.
... composed tree order is a sensible default but it is not enough, for example, if there's a table. The default order will not be what you want.
... ... seems to me (rniwa's proposal) gives a clear answer. Realize you don't have to recompute tab cycle every time, you only need to have it when the user tabs.
... The fact that it interacts with distribution does not matter, when you hit tab you look am I in the shadow tree, have I been distributed into a slot, etc. this seems like a clear answer to the problem.

rniwa: ditto, plus
... we should solve this by defining tabindex scope at the shadow root boundary and the slot boundary and then it works by always working on the composed tree.

kochi: I'll file a bug with some examples and we can work on updating the spec.

hayato: Nobody has spent much time on this, I welcome work on this, etc.

chaals: likes the proposed solution, it seems to make a lot of sense, have not thought about it carefully

rniwa: related to focus, selection
... since I edit that specification it is my interest
... there's a question whether the user can select across the shadow boundary; what happens when they copy paste?

travis: yes; it should work

hayato: This has been a multiyear problem in blink. yosin?

yosin: Current Blink defines selection in the composed tree. Blink does not support deleting; cut does not work in the shadow tree. Deleting from a composed tree is hard to define. We have no idea what the API surface is, we need a specification. That's the status.

rniwa: I think the fundamental issue is Shadow DOM is vague about selection.
... Say you have an element with SR and users select from outside the element and stops the selection inside of it. How is that exposed to author scripts? Where should the ending boundary be? Does it contain the element outside the shadow dom or does it point inside the shadow dom, violating encapsulation. Seems bad.
... Or does the author know, seeing selection end at the element, know to go inside there and search.

yosin: We need deep anchor node and deep offset.
... Exposing selection in shadow tree is from shadowRoot.getSelection, limited to shadow tree, a deep version of anchor and focus position would be easier to use for web authors.

rniwa: How is that easier?

yosin: Iterating over. We need to provide compare position on composed tree or shadow tree or something.
... Most operations on selection iterates the nodes.

rniwa: What's the use case of iterating over selection?

yosin: For caret, authors insert or delete at the caret position. Exposing a node and offset is enough.
... For ranges, authors want to copy or delete the seleceted range.
... Then we need to iterate.

rniwa: You are still talking about editing?

yosin: Yes; and copying serializiation.

rniwa: Why is iteration better? Use a DOM walker and as soon as you hit the end, check if it has a shadow dom you created, and iterate inside of that tree.
... Whereas if all you have is container and deep offset, you need to find a node that is in your dom that is the deep end or start of your container.
... If you are iterating dom in dom dom dom dom order ... why would you want to go into and modify the shadow dom? when editing it is not because you want to put each paragraph in shadow dom; you might have icons in shadow DOM and want to treat it as atomic.
... It depends on the use case, etc.

hayato: We should be careful not to expose deep node api because it does not work with closed mode.

yosin: My main application is scoping selection and selecting partial node in shadow tree. copy should serialize selected node and not entire shadow tree or ignore it

rniwa: There's no specification for serializing selections across shadow tree; and what happens if that happens within contenteditable.
... It is unclear if ... contenteditable state would not propagate into shadowdom. So if you are trying to delete things it kind of fails because it is in in some sense in a weird rainbow state.

yosin: contenteditable is not well defined, so can we not define something for shadow dom?
...

just say shadow in contenteditable is not defined

chaals: we can; should we?

rniwa: Effectively that is what we have today. Nothing is defined about contenteditable.
... We could disallow contenteditable at all within shadow DOM for now, just like we disabled mutation events. This is a rare opportunity to disable features we do not like.
... Do you not like that chaals?

chaals: It does not make me happy; nobody is happy about contenteditable. Yet people use it. Components can create editors.

rniwa: You could create an iframe.

timeless: Can you put a slot in an iframe?

rniwa: You could, but it does not do anything because the iframe is a separate document and the slot is in the regular known shadow dom; you can create a shadow dom inside the iframe too... but that is not what you are asking.
... Should we keep this as an open issue? We should at least have a git hub issue about how selection works and how contenteditable inside shadow dom works. We need something defined before all the browsers can ship.

chaals: It is nice to not have things end up in the magic rainbow state; delete should delete things, users will be crazy face

rniwa: When you have a clear user friendly scenario, when you select outside the shadow dom to inside, if the user asks to delete, it is weird to delete the whole shadow dom (and something)
... when a deletion happens, something should happen

chaals: Something should go away. If you delete half way into a table, what goes away? That's not interoperable or well defined; editing people don't trust browsers to do it and they work to specify their own behavior.
... We could specify "you should delete something" and work it out as part of contenteditable1=true
... We should have an issue and engage editing people for help.

hayato: We have ancient bugs for that, I closed them for lack of recent activity. We are aware of these problems but they are unresolved. There are discussions on the bug. I will reopen the bugs.

rniwa: Let's discuss Custom Elements.
... We have been prototyping in WebKit. Doing everything synchronous is not that bad.
... There were a couple of places to fix but it seems better than alternatives like proxies, faking APIs to ignore elements, remove and reinsert, move native properties
... Those are much, much harder to implement.
... Do other vendors have experience with this, prototyping other designs?

travis: We have done a bit of exploration; code analysis and thought experiment, not experimentation. Similar results, we think synchronously instantiating during parsing, and that is because we have already paid the tax of running MutationEvents.
... It might introduce a lot more context switching from parsing to script. I don't see a way around that.

<timeless> scribe: timeless

chaals: other things?
... run to half past...

rniwa: there was a request to have another meeting, eliot from Google couldn't attend TPAC
... does anyone have a preferred date?
... perhaps in two weeks
... alternatively first/second week of December

chaals: I have a preference for notice, two weeks is not
... I'd assume a meeting would be in California
... if you want Berlin, I could do it sooner, but I doubt you'd want that

Travis: I'd agree w/ chaals
... the proposal submitted in the email was something we'd already talked about
... not sure there was new content to discuss
... not sure there won't be
... i'd like to meet again, after the holidays
... perhaps a little further out
... (January)

chaals: so, late January

hayato: another F2F in December
... we could host
... about Custom Elements
... there are still incoming proposals

chaals: Chairs should take an ACTION item to gauge interest

rniwa: when we last had a meeting in the spring, there were open questions of what can be implemented
... to answer that, people need to prototype or inspect their engines to see what could be implemented
... i have some confidence that I could get it done before next month
... Microsoft?

Travis: not sure I can
... thinking about what's going on next month/next little bit

ACTION chaals to look into next F2F

<trackbot> Created ACTION-759 - Look into next f2f [on Charles McCathie Nevile - due 2015-11-03].

chaals: do people have more for Custom Element?

Travis: is there any other significant issue in Custom Element other than Creation timing

rniwa: no other issues
... creation is the entirety of Custom Elements

dcooney: this isn't very controversial, but there's some question of "ancestor-changed" v. in-/out- of document

mjs: not fully resolved last time, besides initial timing of creation
... question of supporting upgrade/after-the-fact-upgrade
... general consensus was to support it, but not sure how given Constructor()
... exact timing of lifecycle callbacks
... not totally resolved

chaals: we'll be back to talk about CSS and Shadow DOM at 3pm
... I won't be back at 3pm
... I'd like to thank you all, and especially those who scribed

[ Break until 3pm ]

CSS and Shadow DOM

<astearns> CSSWG almost ready to come over

rniwa: a couple of questions we need to resolve for Shadow DOM before we can implement the feature

<rniwa> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order-in-v1.md

rniwa: we have a list, we can go through it
... go through each issue first
... first: combinators, and changes to them
... we don't want deep or shallow combinators
... rename ::content to ::slotted
... still have :host and :host-context

Travis: I don't object

rniwa: I think we don't want :host-context

Travis: :host is a shadow/guide

mjs: could we have explanations of :host and :host-context

<TabAtkins> https://public.etherpad-mozilla.org/p/webapps

TabAtkins: I brought up an edit pad
... I'll draw up an example real quick

[ tab draws ]

[ adrianba increases the font size ]

TabAtkins: if you're inside the shadow
... as this style is, and you try to have a my-component selector
... this component, this div, this style

<dbaron> Tab draws:<my-component>

<dbaron> my-component

<dbaron> :host { color: red; }

TabAtkins: if you take my-component, it won't set on this (the my-component)

<dbaron> er, now it's:

<dbaron> <my-component> <---------

<dbaron> my-component { color: blue; }

<dbaron> :host { color: red; }

TabAtkins: from inside the shadow root, styles can only see other things inside the shadow root
... the other stuff outside is in control of the user, not the shadow author
... you do still sometimes want to be able to style your host element
... to say make it a flex-box
... that's what :host is for
...: host-context is a little different
... say you want to style things based on whether your anchor is class="light-theme"
... you can't do `.light-theme div {...}`
... you could do `:host(.light-theme) div {...}` this would only match the host if it matches
... it's a function() because ...
... host.light-theme doesn't work, because .light-theme doesn't work
... removing a simple selector from a compound selector will never select "less"
... by CSS Selectors definition
... things with more selections must select not more than the other, it's more specific
... it can't be a wider match
... .light-theme div #2 -- doesn't match anything
... then :host.light-theme div #1 -- can't match more than #2
... it's more specific, it can't match less
... you can't select less than 0
... so we have to use a function argument -- :host(.light-theme) div ...

dino: what does :host { color: red } do ?

TabAtkins: it selects the host object (<my-component>) and sets the color property to red
... a more reasonable example is :host { display: flex }
... because you need to use flex-box layout
... does that sufficiently clarify functional host?

mjs: additional question, when you use the descendant selector, what does it select

TabAtkins: PPP

mjs: :host selects the host element, but if you select a descendant, it only selects things in the shadow

TabAtkins: yes, for the purpose of selectors, :host selects two things, the host, and the shadow dom, descendants select inside only

leaverou: why not a psuedo element?
... there's a flaw that :host is a UUU and not a psuedo

TabAtkins: the reason it wasn't a pseudo is that it does exist

ChrisLilley: the projection exists, but the object doesn't exist

TabAtkins: but i'm styling the real element

leaverou: if you can't select it with * then ...

TabAtkins: no...

mjs: * would select everything except it

TabAtkins: * is not everything, it's all tag names in this tree

leaverou: any other examples?

TabAtkins: no, this is the first one

SimonSapin: do you agree *:host is equivalent to :host ?

TabAtkins: it is not
... if you wrote * { color: grey}
... it selects every element in the shadow tree

SimonSapin: same as ...

TabAtkins: *:host is bad, it won't select anything

SimonSapin: defining this way is inconsistent, as with 1/2

TabAtkins: 1/2 both match nothing

mjs: point w/ *, every other psuedo class, *:whatever is exactly equivalent to :whatever
... but for pseudo elements, that isn't the case

<hayato> We had a similar discussion https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0295.html

mjs: although :host sort of refers to a real element, it sort of doesn't
... descendant refers to something after refers to something it wouldn't normally would
... the fact that it's weird kind of makes it a psuedo element

TabAtkins: it wouldn't be inconsistent, but i felt it leaned heavier to this style

hober: all selectors for forever have been scoped to a tree, we didn't know that because there was only one tree
... now we have more than one tree
...: host projects from one tree to another
... it's true it's inconsistent, but we're doing something before
... but this entire argument is `:` or `::` and i don't care

TabAtkins: if you are ok w/ a full selector after a psuedo element?
... then I'm ok

dbaron: I just want
... we use psuedos for things where we don't want to fully explain the dragons
... to mjs, you stick a * in front of it, and that doesn't change anything
... true for psuedo classes and not for psuedo elements
... but it's true for both
... before this proposal, it was true for both

TabAtkins: psuedo elements are always of another element
... but what element is this a psuedo of?

mjs: what is ::selection a psuedo of?

TabAtkins: open question, but there are valid answers for it

[ laughter ]

dbaron: there's no spec for ::selection saying how it works

fantasai: just wrong, I haven't published it
... we do have a spec for that now

TabAtkins: what element does *::host(*) match?
... just serves as the host host, but we've reinvented the host

fantasai: a pseudo element has an element w/ its own set of styles

<kochi> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp&q=%5C*:host&sq=package:chromium&type=cs&l=571

fantasai: but you're trying to cascade all of the classes from outside and inside to the same element
... taking both scopes as an input and cascading together
... an element gets styles, and the psuedo gets its own styles, they're independent entities w/ independent styles

TabAtkins: correct, your styles get merged (outside + outside-inside)
... I think I need to put an explainer into the spec
... we're sticking w/ single colon

<zcorpan> how about dropping the colon(s)?

hober: TabAtkins, I think you've answered this question multiple times in the past
... why not `:::` ?
... "this is a weird thing", it should look different
... I swear i'm not trolling

TabAtkins: I considered it, but the single-double is the single worst thing of CSS

hober: we could do ::: so that people don't come w/ a preconceived notion

Simon: drop a `:` and just have a function

TabAtkins: we could have a function, it isn't defined as allowed for simple selectors yet
... maybe it would be clearer?

fantasai: it would look more like a tag name

zcorpan: it would be better because you can't put a star in front of it

TabAtkins: that's good

mjs: now that we've colored the bike shed, can we go back to semantics?

[ laughter ]

Travis: :host-context

TabAtkins: selector to host(...)
... but we figured there were UCs for contexts higher up
... e.g. body.light-theme
... host-context() let's you try to select against the host element or any of its ancestors

rniwa: afaiu, that would be defined in CSS Var
... why do we need a separate very similar to address the same UC?

TabAtkins: using Variables is the right solution if you want to do your own theme
... an element that's openly themeable, but if you want a predetermined thing
... this lets you ...

rniwa: that seems wrong
... we don't have any other elements like that

TabAtkins: we absolutely do
... just like :host(.foo) > div -- is equivalent to :host.foo > div
...: host-context(.foo) > div -- .foo div

rniwa: no host element styling different based on ancestor

TabAtkins: :host-context lets you put anywhere in a tree

hober: disagree w/ that
... for .list-theme case
... typical page, we use class div
... you stick in header v. main content (light/dark)
... you could see a push/pull question
... is component pulling in
... or is the page pushing in
... I think that's the typical case (one of them -- unclear which)
...: host-context is a pull model, currently things don't do that
... make sense?

TabAtkins: not a lot, but ok
... it's about predefined styles from the component, vs. the page poking in its own styles

hober: i think you can do your own stuff w/o this

TabAtkins: only if you use :host w/ ...

hober: i don't think so

mjs: :host-context, you could imagine a UC for it, but it seems like a box-checking exercise...
... it's true that built in classes

TabAtkins: do things disable themselves based on fieldset?

[ yeah ]

mjs: fieldset isn't a good case

dbaron: <ul type=...>

rniwa: disabled you can't rely on ancestor
... element disabled by label

TabAtkins: correct, it's more complicated than that
... it's not nothing, forms can get more complicated

hober: <ul type="a"> could be done w/ :host

TabAtkins: not if the <li>s are the shadows

dbaron: <table rule> changes things on borders of <td>s

TabAtkins: the idea that there's no example is laughable

[ agreed ]

mjs: still seems too obscure
... I still think we could start w/ :host and see if real UCs in the field demonstrate a need

<dbaron> also the list style rotation for nested ul

mjs: so much of this isn't read

TabAtkins: I'm down w/ that

hober: let's get yelled at

BBB: theming isn't a good UC?

mjs: I think adding it there isn't a good UC
... and I think theming is dumb anyway
... and CSS Vars seem like a better way

dbaron: this is widely used as a developer practice

jyasskin: Polymer is using something like CSS Vars

rniwa: i want to point out that we asked people using Web Components
... anecdotal says that people have no use of :host-context

TabAtkins: our usage is below our kill threshold, so ...
... I recognize :host-context is a lower value, i don't think it's necessary for v1
... i'm ok w/ deferring to later

Cascading Models

<kochi> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order-in-v1.md

<kochi> Could you project this?

hayato: summary of proposals of how cascading model should work
... see the end of the document
... proposal 1, 2
... element in shadow tree
... we have 5 nodes
... we have tree of trees
... dom tree w/ nodes
... tree of tree
... A is a tree, B is child of A
... element in document tree host, shadow host is B
... C is child tree of B
... shadow host in B, hosts shadow tree C
... in shadow ... we have a special selector
... like :host, or ::slotted
... we have a proposal for some pseudo elements
... suppose an element in shadow tree B
... there are a lot of possibilities
... for selectors applied to B
... we should define how cascading should be applied
... if multiple selectors apply to the same element
... ... element B
... element B can have an attribute
... B stye-attribute

mjs: I don't understand any of this
... how do A, B, C, D, E relate to the markup example?

hayato: <html>=A
... it's a shadow host
... shadow tree hosted by A is B

rniwa: in the original markup, the things outside shadow dom is A
... host one has B
... three has C
... if you look outside outer host one
... there's a node projected through 4

TabAtkins: host 4 is a light-dom child of host 2
... host 3 is a shadow child of host 2
... need target items to understand this

mjs: not sure anyone here can fully understand this example
... i think i'm more confused w/ further explanation
... if D is a shadow tree nested in C, nested in B
... how can a selector in D affect something in B?

rniwa: that's a case where a light dom node in B is getting slotted in C in turn slotted into D
... cascading slotting
... so selectors from B could apply
... and selectors from C could apply
... and selectors from D could apply

mjs: ok

[ group finally understands ]

<Samliu_> minutes

hayato need to consider ...

mjs: how is B's style attribute affecting children in shadow dom of b
... I can understand through inheritance, but not cascading
... a node that's a descendant element or ?

PPP: host element has ...

mjs: i wish the numbers in the markup matched the letters

hayato: maybe we need more time to understand

fantasai: maybe we need an application

TabAtkins: we could use my example, it's simpler and more consistent

<TabAtkins> https://github.com/w3c/webcomponents/issues/316#issuecomment-149735841

TabAtkins: tinier example, expresses almost everything from the bigger example
... element in question is a menu item example
... should express most of the items
... menuitem is a light dom child of menu
... there's a style trying to turn it red
... style element trying to turn itself yellow
... style on the shadow trying to turn it green
... then there's a style inside trying to turn it blue
... the winner was yellow
... ordering is determined by a couple of principles of how to resolve this
... style= attributes win
... shadow styles are the opposite
... don't need to guard
... normally styles are treated like defaults
... opposite using !important inside shadow root
... styles from outside would lose
... this gives defaults and invariants
... page rule beats content rule, and page rule beats host rule
... example has things labeled
... the ids on the styles
... the inline style isn't labeled, i can't attribute that
... rules from outside win over inside
... page rules beat content rule
... page rules win over :host

mjs: remove inline yellow, what color?

TabAtkins: red from page

mjs: outermost styling scope wins?

TabAtkins: wins against normal shadow rules
... whenever we conflict w/ normal shadow rules
... outside ones win since they don't usually intermix
... so we treat them as intentional

mjs: i don't follow your logic

TabAtkins: it was more obvious when we had shadow piercing

mjs: if we're not overriding
... if you set :host { display: inline}
... and it would otherwise have {display: block}
... it won't work

TabAtkins: that's why i mentioned invariants (!important)

mjs: what about UA style sheet?

TabAtkins: yes, they lose at the origin step
... everything in page win over UA at origin step
... cascade is several independent steps
... origin, author beats ua
... then style...
... then scoping
... then specificity
... then sequence

mjs: and importance?

TabAtkins: important is origin
... they'd be in the same origin
... and important inside shadow would win

rniwa: other people have other questions about this example?

TabAtkins: besides mjs

hober: what I was originally going to say was covered
... i think this works, i think it's difficult to follow
... but it's fine

jyasskin: a host rule is kind of like a UA style sheet for a shadowed element?

TabAtkins: that's the way you should think of it
... originally it was all elements since you could poke
... but now you only can target the host

adrianba: that's all the time we allocated
... how much more time do you want to spend on this?

TabAtkins: what else is there for CSS to do?

astearns: Animations

adrianba: ok, 20 minutes

TabAtkins: one thing unordered
... eliminate page rule, and style attribute
... you're left w/ content/slotted fighting w/ host-rule
... i didn't have something, it's described by rune's proposal
... general intuition, i think content should win against host

hober: yep

TabAtkins: so w/ remainder, you'd get green

hober: i think it's the right answer, it's consistent
... i'd love to hear disagreement

[ None ]

rniwa: element slotted through multiple shadow doms
... element, inline
... each slot element is a separate shadow dom
... each could have different styles
... all need to be ordered consistently
... i heard you had an idea for this
... e.g. not styling some...
... what was the conclusion

hayato: we haven't ...
... first redistribute shadow tree wins
... if we agree w/ rune's proposal

rniwa: outer shadow, then inner shadow
... style from outer would win over inner

mjs: that seems backwards from what you said
... oh wait, it's consistent
... another algorithm would be only your final position
... maybe simpler to compute
... not sure it handles your UCs
... hard to tell which is more useful

rniwa: consider <listview>
... maybe you have another component inside that has two extra items :before, :after
... styles applying to slots

mjs: already lost

rniwa: list of countries
... <listview> [list of countries] </listview>
... you have a preferred countries
... lightdom has some countries (china, japan)
... then you have outside USA which it's contributing at the top

mjs: can you put slot markers in?

Travis: I think we need to see this example in working browsers

mjs: outer things can't see into light children's shadow dom
... maybe we should give up inventing this example and do it offline

[ laughter ]

rniwa: ignoring intermediary shadow doms seems like a bad idea
... intermediary doms may need to add styles to nodes

hayato: we should define how slotted ...
... current spec says all styles should be applied when redistribution happens
... because slotted elements apply to distributed nodes
... distribution depends on how slotted psuedo element
... slotted element applied to distributed node of slotted element (??)
... you might want to add a comment to the issue about slotted element
... make sense?

rniwa: no
... current spec only allows final destination?

hayato: not only final

rniwa: ok, i think we should keep [allowing others to apply style]
... in addition to TabAtkins 's proposal, there's rune's proposal, and ...
... what are the differences?
... it's not obvious how they're different
... what's the motivation for each proposal

hayato: differences ...

rniwa: what are the motivations (for other proposals)

hayato: proposal 1 is from rune (Opera) guys
... this makes implementation easier
... rune prefers style= should be treated
... in same way as style in same node tree
... reason same attribute is next to B

mjs: don't we want to have style= consistent w/ in a top level document
... it should be the same order in a shadow tree, or it's rediculous

rniwa: TabAtkins 's proposal, rune's proposal
... no difference
... was his proposal in response to opinion 2?
... afaict, TabAtkins 's and rune's proposal preserve the invariants that we want
... style rules / style= from same tree next to eachother
... not sure who's opinion 2 is
... your proposal violates that by putting style= in a different thing
... given we went through the exercise to understand TabAtkins 's rational

mjs: TabAtkins 's proposal doesn't contain all the letters
... hard to tell how it's different from the others
... do A+D never apply in TabAtkins, or are they ...
... and E isn't used, does that mean they can't apply in Option 2?

TabAtkins: my proposal doesn't have A

mjs: before next time we discuss this, could someone write this up w/ the same set of letters/possibilities
... i can't tell if it's agnostic, say it won't apply, written against different example
... hard to understand how to pick

koji: sorry, proposal 1 is rune's
... ryosuke didn't understand that rune's proposal

mjs: is rune's the same as TabAtkins 's?

koji: TabAtkins 's covers style=, rune's didn't
... hayato add's nested to TabAtkins 's example

hober: all one proposal, different levels of detail in the writeup?
... three proposals, one didn't cover everything, one added a layer, the next added the next layer

koji: TabAtkins 's added a corner case
... just an improvement over rune's

rniwa: i think this situation is way too confusing for us to conclude at this time
... if one is a superset of another, we don't need the subset proposals

mjs: the way TabAtkins wrote his up was a lot easier to understand than A, B, C, D, E
... please write all the proposals up that way
... 1. explain proposals
... 2. explain reasoning for differences
... doing 2 first wouldn't help

adrianba: out of time
... glad we waited until the end of day 2 to talk about this
... we accomplished some progress
... conclusion is a bit more explanation of proposal, broken down in small pieces, thanks all for the discussion
... end of WebPlatform WG Meeting
... thanks to CSS WG people who came

[ Applause ]

[ Adjourned ]

- DRAFT -

Web Platform WG F2F

26 Oct 2015

Attendees

Contents

Agenda Bashing for Tuesday

ES Modules and HTML

ES6 modules and HTML

Agenda edits

Report from Editing Taskforce

Web Components

CSS and Shadow DOM

Cascading Models

Summary of Action Items

Scribe.perl diagnostic output