See also: IRC log
<inserted> scribe: timeless
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
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
<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 ]
<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.
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.
<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 ]
<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> <::shadow>
<dbaron> <style>
<dbaron> my-component
<dbaron> :host { color: red; }
<dbaron> </style>
<dbaron> </::shadow>
<dbaron> <div>foo</div>
<dbaron> </my-component>
TabAtkins: if you take my-component, it won't set on this (the my-component)
<dbaron> er, now it's:
<dbaron> <my-component> <---------
<dbaron> <::shadow>
<dbaron> <style>
<dbaron> my-component { color: blue; }
<dbaron> :host { color: red; }
<dbaron> </style>
<dbaron> <div>foo</div>
<dbaron> </::shadow>
<dbaron> </my-component>
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
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
<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 ]
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: i/topic: Agenda Bashing/scribe: timeless Succeeded: s/#webapps// Succeeded: s/!seen chaals// Succeeded: s/hi!// Succeeded: s/travis l:/travis:/ Succeeded: s/nickkoteh? (sp)../MikkoT: Mikko Tero, ZZZ/ Succeeded: s/smaug: #serviceworker on freenode// Succeeded: s/(only IRC)// Succeeded: s/background/background (only IRC)/ Succeeded: s/Tero, ZZZ/Terho, Huawei/ Succeeded: s/is on the call/Adam Klein, I just joined, but I can't hear well/ Succeeded: s/muted// Succeeded: s/present +/present+ / Succeeded: s/MikkoT present+/present+ MikkoT/ Succeeded: s/Dan Appelquist/Dan_Appelquist/ Succeeded: s/Claude Dufourd (Institut Mines Telecom)/Claude_Dufourd_(Institut_Mines_Telecom)/ Succeeded: s/Mache/mjs/ Succeeded: s/?:/rniwa:/ Succeeded: s/+q/q+/G Succeeded: s/Break time, back at 11:15./[ Break time, back at 11:15 ]/ Succeeded: s/Break until 11:15/[ Break until 11:15 ]/ Succeeded: s/ie one hour, 13 minutes./[ i.e. one hour, 13 minutes ]/ Succeeded: i/summarized the 'Cascading/Topic: Agenda edits Succeeded: i/2nd topic/Report from Editing Taskforce Succeeded: s/Yoichi/yosin/ Succeeded: s/Report from Editing Taskforce/topic: Report from Editing Taskforce/ Succeeded: s/2nd topic// Succeeded: s/splut/split/ Succeeded: s/TImeless/timeless/ Succeeded: s/in cyrillic/in cyrillic [ght => бороться]/ Succeeded: s/arabic/hebrew, arabic/ Succeeded: s/?/koji/ Succeeded: s/ght => бороться/ltn => детей/ Succeeded: s/Its easy/It's easy/ Succeeded: s/or something else/... or something else/ Succeeded: s/a direct child/two direct children/ Succeeded: s/timeless/scribe/ Succeeded: s/mjs there are two cases/mjs: there are two cases/ Succeeded: s/tru./true/ Succeeded: s/ZZZ/another meeting/ Succeeded: s/QQQ/hayato/ Succeeded: s/.././ Succeeded: s/other than/other than Creation timing/ Succeeded: s/RRR/lifecycle callbacks/ Succeeded: s/heh// Succeeded: s/adrianba: hopefully// Succeeded: s/DZZ/dino/ Succeeded: s/MMM/ChrisLilley/ Succeeded: s/NNN/SimonSapin/ Succeeded: s/falken/fantasai/ Succeeded: s/mjs/hober/ Succeeded: s/UUU/zcorpan/ Succeeded: s/to .foo/to :host.foo/ Succeeded: s/UUU/jyasskin/ Succeeded: s/kochi/hayato/ Succeeded: s/hywe/hayato/ Succeeded: s/.../TabAtkins:/ Succeeded: s/YYY/astearns/ Succeeded: s/tue/ute/ Succeeded: s/mjs/hober/ Succeeded: s/.././ Succeeded: s/VVV/koji/ Succeeded: s/VVV/koji/ Succeeded: s/VVV/koji/ Succeeded: s/ryuske/ryosuke/ Succeeded: s/disucssion/discussion/ Succeeded: s/RRSAgent, draft mintues// Found Scribe: timeless Inferring ScribeNick: timeless Found ScribeNick: dcooney Found Scribe: Dan A. Found ScribeNick: dka Found ScribeNick: dcooney Found Scribe: timeless Inferring ScribeNick: timeless Scribes: timeless, Dan A. ScribeNicks: timeless, dcooney, dka Present: paulc hober kochi adrianba Karl_Dubost dom Koji_Ishii mathieucitrix MikkoT Dan_Appelquist xiaoqian Gary_Kacmarcik Jean-Claude_Dufourd_(Institut_Mines_Telecom) hayato Arnaud_Braud markw JT_Jung Josh_Soref dcooney Yves Wayne_Carr Sebastian_Kaebisch koji LJWatson Got date from IRC log name: 26 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/26-webapps-minutes.html People with action items:[End of scribe.perl diagnostic output]