TPAC 2016 Web Components -- 19 Sep 2016

Open issues with "web components"

At 11AM a11y folks will join to talk about ARIA

<dcooney> Note: meeting agenda page: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-19TPAC-1.md

Domenic: I'd like to discuss some v2 stuff

Custom elements feature requests

<Domenic> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-19TPAC-1.md#custom-elements

Domenic: should we add more callbacks?
... user agent-type stylesheets?
... allowing more parsing modes than just parsing like <asdf>

annevk: which callbacks?

Domenic: cloning is not exposed atm, e.g., <input> preserves internal state, you cannot duplicate that with custom elements
... cloning seems fairly trivial to add

bz: the main implementation issue is the callback throwing

dcooney: when cloning you already have to deal with the constructor throwing

bz: so... not a new issue

dcooney: I think you get an element back, but it's in a failed state of sorts

(nodding in the room)

dcooney: there's a question of when the cloning steps run

Domenic: they'd run after the tree is cloned, all at once
... seems doable

(some more nodding)

bz: do we want to run them in tree order? before or after its kids?

dcooney: callbacks run after everything is cloned
... the simplest way would be parents before children

bz: might want to discuss with components authors

Domenic: motivation is emulating builtins
... those don't depend on children

koji: can those callbacks mutate the tree?

Domenic: yes, but it's well-defined
... I'd like to add them in tree order

annevk: like

chaals: like

dcooney: we could get some more feedback and decide Friday
... just to double check

Domenic: SGTM

weinig: I don't think we're against it, sounds fine
... there's a question of how often it's used

bz: it would help to have actual use cases

Domenic: if HTML modules takes off, you really need cloning
... so need to get some more feedback
... but generally sounds acceptable

dcooney: are there other hooks?

annevk: I think cloning is the last

bz: there's a callback for all attributes being set from the parser

annevk: also a callback for end tags seen by the parser (for <script>)

bz: [describes how <img> only starts fetching once all attributes are set]
... all-attributes-set callback is used by form, media elements for mute flag (seems like impl detail), menuitem elements have something
... don't see anything for <img> actually in Gecko's code

rniwa: to get back to cloning, it's weird that when the callback runs you already have children

Domenic: I think that's inherent to the custom elements design

esprehn: I noticed that the parser is super spammy compared to innerHTML with a bunch of microtasks

bz: [notes that <img> does do it]

esprehn: I'd like for the HTML parser to do this less, and only run constructors when the parser yields
... I'm not suggesting that the parse would no longer synchronously construct elements

dcooney: oh, so you're talking about when the microtasks run with respect to the callbacks

Domenic: the design of microtasks is that they run after a callback
... it sounds like you're proposing when to run microtasks during parsing, which would be less deterministic

esprehn: you already have this weirdness due to innerHTML, which is used by the application after the initial parse

bz: this is the same as with DOM event handling
... you get microtasks between listeners if the UA dispatches the event, but not when script does

esprehn: the parser used to have a single microtask point whenever the parser yields
... with lots of custom elements you might get thousands of checkpoints

Domenic: is an empty checkpoint slow?

esprehn: with mutation observers, if you observe the document...

Domenic: DON'T OBSERVE THE DOCUMENT!

[it's common]

smaug: I don't like the inconsistency

esprehn: it's already true, with innerHTML

smaug: then you have JS on the stack

esprehn: I think when we did microtasks we didn't envision this many callbacks

annevk: microtasks will run when the parser yields, custom elements or not
... so it's already non-deterministic
... the only difference here would be to not run microtasks after custom element creation and callbacks during parsing

weinig: can we quantify the problem?

[the problem being the spammyness of microtasks]

esprehn: I guess you have to take my word on there being thousands of custom elements on the page
... C++ spec is written using them

weinig: not impressed

dcooney: empty microtask isn't free, but fairly cheap, so interested in hearing about document-wide mutation observers

esprehn: [couple of cases]
... global attributes is a thing that people use them for, but separate problem

weinig: maybe it isn't, if we solve that, they might not need global observers

esprehn: it's hard to quantify, but not doing 20k checkpoints is going to be cheaper

dcooney: what's the cost of callbacks vs the microtask checkpoint? I haven't looked at it much yet, but curious

esprehn: depends, more callbacks is also more expensive

rniwa: is the main reason performance?

esprehn: I also think it's [better]

rniwa: since this is a brand-new API, it's hard to say whether the proposed behavior is better

ojan: is there a use case for the current behavior?

Domenic: that's the point of microtasks, to run asap once the stack is clean

smaug: yup

esprehn: I thought the reason was mostly that the page can be in a consistent state [missed]

smaug: yes, but I think we should maintain the original invariants

esprehn: so let's generalize, why don't microtasks run between function calls?
... arguably custom element callbacks are function calls

chaals: consistency argument is not convincing, web isn't

rniwa: reason for microtasks was not batching, but was that mutation observers wouldn't step on each other
... big problem with mutation events was that you could easily end up with recursion

esprehn: another thing, Fx still doesn't implement promise handling correctly
... so folks can't depend on this
... so I don't buy consistency, since it's been broken forever
... [cites Safari bug I missed]

dcooney: I buy the argument that custom elements synchronous mode is novel territory and we could run into problems

Domenic: I think a good next step would be to write this problem up, discuss with developers, and ideally quantify it a bit

dcooney: hard to get that since folks don't build infeasible things

Domenic: they build slow things though

bz: they also build bizarre workarounds for infeasible things

chaals: do as Domenic says

smaug: could this be indicative of a problem with custom elements rather than microtasks?

esprehn: [censored]

weinig: could give developers control over when they run

esprehn: keep giving developers more control over low-level things, but they require fairly sophisticated libraries
... as developers take more control, microtask checkpoints run less
... so perhaps giving control over running them synchronously, or batching, would help

<Domenic> https://github.com/w3c/webcomponents/issues/113

<Travis> scribe: Travis

Domenic: Some HTML elements do weird things that some people like. (Template, etc.)
... may require some weird symbols...
... folks aren't sure that we should mess with the parser.
... what do folks think?

rniwa: Definitely not for v1.
... for v2, better off not doing it (I could be convinced--maybe). Show me the use case.

dcooney: Lots of polymer folks wrap template
... templates for stamping shadow dom

esprehn: I'm fine punting to later version. is attribute works for this.
... example: polyfil some css feature.

tobie use cases for template binding--I think this

rniwa: not convinced adding parser hooks are the right way to solve those use cases.

Domenic: Understand this is a little redundant with 'is' attribute.
... should we encourage custom tag names, or encourage 'is'?

esprehn: unconvinced that we want to expose parser extensibility.
... script/style/template use with 'is' is fine.
... self-closing tags are the only thing maybe worth exploring?

dcooney: worried the behavior might be a surprise to authors.

bz I don´t know?

esprehn: we have a Proof-of-concept that shows one direction is fast (23x)
... xml-like (basic parsing)

<esprehn> attribute quoting required, all tags require closing, etc.

bz parser can tokenize fast without knowing what script tags...

dcooney: foo-bar#! (only parse-ible in template mode)

rniwa: "show me the use cases"

esprehn: OK... but should we ban tag names that end with certain symbols (e.g., !)
... v1 spec is very flexible.

Domenic: use cases also served by not modifying the parser.
... would love to land with "not doing this"

chaals: anyone wish to do this? (hoping for someone to speak up)

annevk: some folks found that maybe a mode switch (at the beginning) would be tenable?

esprehn: separate topic of allowing a doctype-switch that puts you in a different world...
... doesn't address other cases (PCDATA and other states)
... slightly orthogonal discussion.

rniwa: whether ! is allowed... doesn't appear to be allowed per the grammar.
... can be safely allowed, but is an incompatible parser change. Use cases have to demonstrate the need.

Domenic: CAN WE FIX createElement???
... createElement is more restrictive than the parser.

annevk: it's already more permissive than XML (can use a ':')

esprehn: first letter has to be lowercase... (Looking at implementation...)

Domenic: we investigated why first letter has to be lowercase.

<Domenic> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/YyqxpIPU-0E/k5gu7i9dBwAJ

annevk: re: createElement: after a long thread nobody wanted to do the research to see if it was compatible.

dcooney: looking for data on the web compatibility of fixing createElement.

bz: what is the compat worry? have createElement throw in fewer cases... and this is a concern?

dcooney: maybe a browser should try it...

bz: we can put some telemetry in case.

Domenic: will file a Chrome bug; everything will be happy :-)

dcooney: new callbacks wanted
... code never knows when it is getting the last attribute changed callback.
... ex: input knows its type when the element is created.
... 2nd case: end-tag-done.
... cite: script element end tag (which does lots of interesting things)
... if the markup does one-time processing at the end this is a good use case for you.
... we see native elements doing this.
... ex: youtube comment example using anchor tags (want to process like a macro)
... it's basically performance, but there is also a semantic difference

bz: ex: <object> doesn't try to figure out what to do until it has all its children.
... <select> picks the selected item (if none are marked selected) when all options are available.
... <textarea> detects form-state restoration.
... <title> elements--this is just optimization

rniwa: all those cited examples must detect dynamic changes via DOM api?
... I'm more comfortable with a children-changed callback

esprehn: don't want to add another child-changed callback...
... users won't expect half of a select control to render, etc.

rniwa: I'm less comfortable with adding a specific callback for end-of-element parsing, than for fixing mutation observer.

dcooney: we can imagine a children-changed callback (maybe with a flag--this is the last one)

rniwa: maybe a single callback could work? when all children are known?

dcooney: could maybe make it work for attributes too.

[discussion of how attributes are not known before element is created]

bz: img tags ignore all there attribute sets until the image is added to the document.

<esprehn> the spec wants you to do it at mictotask now IIRC, blink doesn't look at the img attributes until then I think

rniwa: might need an argument on connectedCallback to say it was done by parser.

bz: what about document fragments?

<rniwa> +q

dcooney: connectedCallback fires for any document (authors expected to check defaultView)
... for the flag--it would represent the entire subtree

bz: going back to what img is doing...

rniwa: maybe the flag is needed at construction
... the flag would indicate created-by-parser.

bz: script uses this flag today.

dcooney: If you use selector-checking right after the super() call, you can detect some things
... it's a hack.

esprehn: crazy suggestion: how about a parserSetAttributes callback--it gives you all attributes in a list.
... its in place of the other attributeChanged scenario.
... just sayin'

[bikeshedding the new idea]

dcooney: all the expensive work will be done, not a perf concern

Domenic: nice solution for attributes, not sure for children

dcooney: for <input>...

Domenic: any other examples?

<rniwa> +q

annevk: there is no concept in "standards" that the all-attributes-present flag is there.
... not sure we should expose to script.

weinig: we don't expose--it's for optimization

bz: cloning uses the same thing the parser does.

<jcraig> scribe: jcraig

ISSUE-552

https://github.com/w3c/webcomponents/issues/552

HTML 1:1 Role Parity for Custom Elements

RS: summarizes other proopsal for extensibility

<annevk> Accessibility Object Model is here: https://a11y-api.github.io/a11y-api/spec/

RS: Dominic Denicola mentions extensibilit. I

aboxhall: AOM look at the explainer not the spec: https://github.com/a11y-api/a11y-api/blob/master/explainer.md

RS: UIAutomation has done something like this for WAPA

denicola: About roles mapping, we'd like each html element mapped

for example, color pickers

not frameset

<IanPouncey> jcraig: this was one of the goals for ARIA 1.1, to have HTML role parity so we added cell.

<IanPouncey> We didn't get close to 1:1 partity.

<IanPouncey> For things like video elements there was no way to get parity

<IanPouncey> Problem with existing role like sliders the only way to control this is through keyboard events.

<IanPouncey> Hopefully we'll get ways to get direct attribute manipulations

<IanPouncey> If we have mapping with every HTML elements, it's the functional elements where we need ways of interacting with the native control methods.

domenic: would it more harmful to have custom video elements that don't use those roles?

we'd like like to do both

jcraig: I'm happy with the staged approach

RS: everything today uses propagation of [physical] events (click etc)
... We'd need to may device-side changes???

<rniwa> +q

travis: video cited as an example.. why is that not a problem for sliders?

jcraig: it is.

RS: lists "pause video" as an example... could be from physical media keys

no way to respond to that from a custom elements

discussion re: event bubbling

anne: for event delegation (e.g. which video element to pause)

<Zakim> jcraig, you wanted to ask which device side changes

<IanPouncey> jcraig: there would be device side changes necessary, I don't know what they would be. The problem is that there is no way to, for example, manipulate a slider. On the platform side these exist. If we added actions for custom changes there would need to be changes on the device side.

RS: associating specific data with a control pattern: MS UIA

IndieUI associated increment with sliders

rniwa: I don't see that that the API is necessary wrt this topic (HTML 1:1 role mapping) we need a general control mechanism for manipulating custom elements.

<chaals-ordhord> ack steq+

<Zakim> jcraig, you wanted to mention IndieUI tried and failed to do that

<dcooney> scribenick: dominicc

<dcooney> stevef: re: the 1:1 mapping and reaching parity for elements which have a display-sense meaning

<dcooney> that does not seem to be an agreed concept

<dcooney> annevk pushed back on that and did not want to recreate roles or features in HTML

<dcooney> how much consensus is there on thatL

<dcooney> ?

<dcooney> domenic: annevk pushed back but everyone else is in favor

<dcooney> annevk: I think the main pushback was that the idea was we need those roles for standalone SVG documents for example which I don't think... it seems weird. You can't use CE in SVG

<dcooney> chaals: what if you get them in HTML inSVG

<dcooney> we tried to do this in indie UI. we are trying to do this piece by piece, do you want this incrementally

<dcooney> annevk: I think I changed my mind about adding a role for figure

<dcooney> if figure has a role today, then sure, having a role value for that makes sense

<Zakim> jcraig, you wanted to mention a 1:1 mapping would not require platform role changes

<dcooney> but if there's an element that doesn't have a role like div we shouldn't add one

<dcooney> jcraig: this doesn't necessarily mean there would be a pltaform role change to have a 1:1 mapping

<dcooney> dpub WG which specifies epub added a bunch of rolse

<dcooney> es--bibliography link--to programatically manipulateepub

<dcooney> we're not going to handle that differently in the product/platform side

<dcooney> the user knows if they're in a bibliography the link there is a bib link

<dcooney> but there should be a single "generic" role for span and div generics

<dcooney> and for web components

<dcooney> to differentiate div and group

<dcooney> And that should map to the platform APIs

<dcooney> rich: You can use an aria figure as a container

<dcooney> rich:

<dcooney> rich: your point earlier about (rniwa) about making it for everything not just a11y

<dcooney> msft basically piggybacked on top of automated testing so they have patterns for everything eg slider

<dcooney> instead of reinventing the wheel can we use that

<dcooney> msft has been using this as a standardized platform across desktop, xbox, across the board

<dcooney> can we pull that out to javascript?

<dcooney> we should at least investigate it

<dcooney> travis: UIA is really a simple simple simple concept

<dcooney> it's three things--a concept label, related states and related actions

<dcooney> it's a package with event handlers and property values you can attach onto things

<dcooney> a lot of that is baked into html already

<dcooney> it has elements, attributes and properties, and events and event handlers

<dcooney> what's missing is the conveyance of the context

<dcooney> I like starting with, let's take HTML and make sure it's fully experssive

<dcooney> there's the context, when you create web components you compose them in new ways

<dcooney> but how do I express the context for things like video, a sighted user can click on an area they see for pause

<dcooney> but there may not be a way for ax tech to know about pause

<dcooney> with a web component you're using the platform but the intent is to create a semantically new thing

<jcraig> axk r

<dcooney> so there needs to be a way to express the new context and new states

<dcooney> rich: aria is one way, saying something is a video tag is not enough

<dcooney> for a list box you can do best practices

<dcooney> but aria ran out of gas asking how do you do this in a device independent way

<dcooney> for example controlling where you are in a listbox or a gesture

<Zakim> jcraig, you wanted to respond re: properties used with the event handlers and to say e.g. min/max/step value for sliders, various properties for media elements

<dcooney> so rather than having device-specific handlers, if you could do this in a device independent way

<rniwa> +q

<dcooney> that's the whole picture

<dcooney> jcraig: slider and video are hard to make accessible today so I keep brining them up

<dcooney> the slider may have platfor mevents like increment and decrement and a value

<dcooney> but the platform should be able to set the value, query for the value, min, max and step

<dcooney> we had all of those in aria, not sure about step

<dcooney> but look at video, it has available tracks, media properties like tracks, are they audio descriptions,

<dcooney> the native properties have that

<dcooney> but the complexity skyrockets

<dcooney> I like the idea of a general interface for properties and actions

<dcooney> and then for each control we say, here's the set of properties and actions you need to have to give people full control

<dcooney> over a custom video for example

<dcooney> chaals: travis, you said UIA tells you what you can do, not what it is, eg starship-controller versus a bundle of button like fire missiles.

<dcooney> jcraig: but maybe the browser knows aircraft and you can extend it

<dcooney> travis: I use pokemon as an example

<dcooney> chaals: say I make aircraft, can ryosuke take that and extend it to make starship control, or is it a bag of buttons

<dcooney> how do you do that discoverability

<dcooney> and do you need to

<dcooney> ?

<dcooney> maybe the individual controls are enough

<dcooney> travis: I think "no" because we as sighted users can do the inference step to examine how it is composed and what it is

<dcooney> unsighted users don't have that

<dcooney> jcraig: aria-role description does that to some extent

<dcooney> it's in 1.1 but not supported on every platform

<LJWatson> +1 Travis

<dcooney> any events or queryable properties should be associated with an explicit role

<dcooney> eg container for a slide in slideshare is a generic group but you can describe it as a slide for assistive tech users

<dcooney> rniwa: travis' point that custom elements poses a new challegnge is a good point

<dcooney> but that was always the case, web authors always come up with ways to express their content

<dcooney> we added media, article in the past 5 years

<dcooney> the platform should provide the building blocks, people build random things, and then the platform should consolidate the common patterns

<dcooney> so media controls, sliders, calendars we should support

<dcooney> but we also should provide a way for authors to describe actions users can take

<dcooney> accessibility API is a good API for that latter part--describing what a user can do with a control

<dcooney> we need to bridge the gap with a mid tier API

<dcooney> jcraig: by accessibility API do you mean AOM?

<dcooney> rniwa: yes Accessibility object model

<dcooney> rich: THe most expensive thing a developer has to do to add accessibility is adding keyboard support

<dcooney> removing that cost would make it much easier to add

<dcooney> so what are the next steps?

<rniwa> +q

<dcooney> jason white (IRC?)

<dcooney> jasonjgw: i am involved in IAC global (missed)

<dcooney> makes accessibility/interactions for education

<dcooney> have to reoder elements or create ordered pairs of elements from two sets

<dcooney> these are not common actions on the web

<dcooney> they would be well suited as web components

<dcooney> you can make accessible implementations of them with ARIA

<dcooney> but they don't fit into the predefined widget categories

<dcooney> if we add IMS' use cases

<dcooney> then web application authors in domains like education

<dcooney> will continue bespoke interaction types

<dcooney> can we devise robust specifications

<dcooney> so the interactions are accessible without going through the standardization process

<dcooney> so this is a voice in favor of thinking carefully how extensibility is provided

<dcooney> and there are domain-specific interactions outside

<dcooney> janina: plug for 1pm session on the need to identify the contextual information

<dcooney> eg this is starship controller, this part is the warp drive, this is the viewscreens

<dcooney> that turns out to be a wide use case

<dcooney> digital publishing needs ... something

<dcooney> longdesc

<dcooney> we're trying to move beyond it and have it apply to more than just images

<dcooney> we can associate a description with something

<dcooney> harvard admission test

<dcooney> here's a butterfly

<dcooney> print out a braille diagram of it, what can you say about it?

<dcooney> we need a way to make these containers and we need annotations,

<dcooney> we have it covered with aria-details

<dcooney> there are a lot of disability use cases where people don't use accessibility tech

<dcooney> I want to point out it is a wide queue

<dcooney> rniwa: going back to brand new components, the comment we need an extensible API

<dcooney> despite what I said earlier there are some things that's hard to support without standardization

<dcooney> say someone wants to make a math equation editor

<dcooney> on some platforms there may be a native one the browser can hook up

<dcooney> how do you describe that in absence of an aria role for math eqn editor

<dcooney> I don't know how you describe that without the role

<dcooney> on some obscure platofrm there may be an ancient egyptian text editor

<dcooney> but how do you convey that without a role?

<dcooney> the AOM API must let you build and customize the accessibility tree

<dcooney> but I don't think we can support any concieveable widget, human imagination can come up with a lot of crazy stuff

<dcooney> one path forward is adding more aria roles, there are many that could be easily added like article

<dcooney> questions about frameset, canvas which don't have semantic meaning

<dcooney> we should judge them case by case

<Zakim> jcraig, you wanted to mention interaction pattern mix-ins and to say (from IndieUI)

<dcooney> but elements with roles, we should describe the roles

<dcooney> jcraig: jason white jgw mentioned there are lots of controls like math editor, infinite expanding treees

<dcooney> it would be challenging to make these types of things

<dcooney> maybe they just expose latex and as long as you can edit that you can do whatever you want

<dcooney> for those cases we come up with new APIs, we'll look at things that exist and then talk about standardizing

<dcooney> We may not know what someone will create but a lot extend metaphors

<dcooney> this was part of indieui or intentional events

<dcooney> eg we don't know this map but it has scale and zoom; this one has pan or move

<dcooney> so the idea of behavioural mixins like activate (effectively click) or value change

<dcooney> then we can infer the context in the same way as a sighted user infers the visual presentation

<dcooney> lisa: facilitator of accessibily TF

<dcooney> when we made the first version of ARIA in 2006 we made a high level abstraction

<dcooney> to get the model of interativitiy

<dcooney> this is just going to specification now (1.1)

<dcooney> even though the presentation changed, we have a high level representation

<dcooney> you can often reduce very different things to these core concepts like selected option

<dcooney> I think aria addresses a lot of these core concepts well if you look at what you can model instead of worked examples

<jcraig> lisa: Lisa Seeman, facilitator of Cognitive TF for Accessibily

<dcooney> chaals: the path forward, it sounds like there's agreement about digging into HTML, listing the pieces they have like pausing a video or picking a day in a date controller

<dcooney> we just want to be able to do that stuff and tell people what that is.

<dcooney> Who agrees?

<richardschwerdtfeger> +1

<dcooney> seems to be general agreement, sense of where we are

<rniwa> +q

<dcooney> when we have labelled all of the things we know what to do, people will come up with new things like video before there was media element; when people add math editing and butterfly testing things

<dcooney> then we can standardize those

<dcooney> we have a way of "just give me a straight out text description" and that's horrid but in theory it works

<dcooney> you get descirption, instructions, the instructions don't quite work and they are in a foreign language

<dcooney> like a flying car controller

<dcooney> so you start there with the description which is better than nothing

<dcooney> but is there anything more useful we can do until there are millions of these?

<dcooney> rich: when you have one of these objects you want to know how to interact with it

<dcooney> so we need to define these as a starting point showing people how to interact with these

<dcooney> this will save developers a ton of money and time if they don't have to deal with device specific issues

<dcooney> how do our working groups interact?

<dcooney> can we tie AOM and this new API for describing the interaction pattern together

<dcooney> We need to tie together the semantic description and the bundle of interfaces

<dcooney> I think this is a Web Platform thing we should be working on together

<dcooney> It was going to be done in an incubator group

<dcooney> the accessibility object model seeds the effort; what do we do today?

<dcooney> matt king facebook, aria WG member

<dcooney> matt: there are certain aspects we're discussing that are bing massively overcomplicated

<dcooney> think of the user

<dcooney> you talk about starship, video, slider

<dcooney> in all of those cases you can't make any assumption. You see the slider on the screen and there is visual communication which hints what you can do.

<dcooney> slider is a hint to an inexperienced person who has seen some UIs may know what a slider is but slider is just a word, it's meaningless in itself

<dcooney> there should be no distinction between the general and specific cases

<dcooney> we should think about how does the user discover what the actions are, complete the actions, and extract information that is relevant to them

<dcooney> we should be thinking about that generic problem

<dcooney> there may be a default action or gesture, there's something that gets done by that

<dcooney> what is it that gets done? how do they discover that?

<dcooney> increment/decrement to set upper/lower limits on an integral

<dcooney> a particular component has a particular vocabulary

<dcooney> authors should be able to develop applications that communicate in the context of the application

<dcooney> the general (starship) and specific (slider) problems are the same and should have uniform solution

<dcooney> rniwa: suggestion, I don't want to start a long discussion

<dcooney> perhaps we should add a default aria role to custom elements

<jcraig> +1 to default aria role

<dcooney> to define a default aria role , people need to add a tag and a role attirbute which seems redundant

<dcooney> domenic: it's a 60-80% use case; the a element switches its role depending on href; input switches on type; setting a default role is not enough, it is 80%

<dcooney> rniwa: it doessn't solev everything but would work for article

<Zakim> jcraig, you wanted to discuss action items: role parity (i think we're in agreement). and to say action/events/query custom props within web components (general agreement but no

<dcooney> domenic: support but does not want to preempt AOM

<dcooney> jcraig: it seems everyone is on board with role parity and changed role for a web component

<dcooney> I want to clarify, is everybody generally in agreement that we want to make an extensible API for actions, events and queryable properties so we should work on that in our respective domains

<dcooney> AOM may be the vehicle but it is limited in scope

<dcooney> we have a proposed session on wednesday for that

<dcooney> aboxhall: noone said affordances yet but that is really what we are talking about with roles

<dcooney> travis was talking about the same thing without using that word

<dcooney> a starship controller is not an affordance, it is built out of affordances

<dcooney> these evolve over time

<dcooney> typically the visual affordance came first

<dcooney> it would be good as we are building visual affordances it would be great to have a way to build that

<Travis> dcooney: got feedback from polymer that they were interested in the default role.

<Travis> .. also that components would like a tabindex

<dcooney> dominicc: polymer wants role and tabindex

<dcooney> domenic, etc.

<dcooney> domenic: noted, it is complicated later

<dcooney> jcraig: it's complicated, scoping, etc.

<slightlyoff> excited to see role parity

<Travis> scribe: Travis

custom elements--what to do when constructor throws during upgrade, cloning, etc.

rniwa: report error, or propagate an exception.
... prefer throwing, but maybe we should discuss this.

dcooney: I think the spec (today) makes sense (in this area)

<Domenic> https://github.com/w3c/webcomponents/issues/525

dcooney: in cases where there is script on the stack, it says to report an exception, which I think is the right thing to do.
... I think reporting exception is more helpful to authors.
... Spec is doing the best it can...
... Currently reports exceptions synchronously as much as possible.
... cloneNode: can clone lots of custom elements.
... exception throws, what happens to the next [queued] constructions/callbacks

bz: event dispatch depends (who/how this was started)
... to the web author this is not very predictable.

dcooney: cloneNode has no early exists.
... [today]

Domenic: it's not an early exit, its an interruption of the custom element queue.
... [thinking out loud] you have to do some kind of clearing of the queue...

<Domenic> https://github.com/w3c/webcomponents/issues/525

rniwa: I agreed for innerHTML (makes sense for parser).
... for DOM API, I don't think that matches author expectation.

dcooney: Are we talking about the constructor running specifically, or an issue with all callbacks?

Domenic: I think we're talking about splitting into two things parser vs. DOM API.

rniwa: Parseerror vs other.
... propagating an exception is more inline with authors.

bz: seems easier to avoid inconsistent state in the cloneNode case than innerHTML case.

annevk: should we re-throw in the adoptNode case?
... appendChild would throw?

rniwa: Still think propagate the exception.

Domenic: Don't like that one failure stops everyone else from running.

tomek: +1

dcooney: I think createElement already threw--and you're only creating one object.
... for appendChild that's not the case--there are multiple ones.

rniwa: I think it's weird to have constructor not throw, but everywhere else throw

dcooney: there are options for "aborting".
... I don't think we need to do that.
... operations that didn't throw exceptions still won't.

annevk: parser/createElement--we invoke the constructor as part of the call--it's sync.
... other things are deferred actions.

chaals: consistency is a hard argument.

rniwa: just report exception breaks down...
... it's hard for author to anticipate what will happen when the constructor has an issue -- there is different behavior depending on scenario.

bz: you might want consistent behavior depending on how a library was implemented...
... but that's probably not feasible.

rniwa: it's about what the author can expect.
... how about createElement should not throw?

Domenic: Here's my model.
... parser/createElement sync create elements.
... parser has nowhere to throw to.
... createElement does, just sugar for the constructor, so it throws.
... is it too confusing to have the sugar?

dcooney: createElement is a special case?

rniwa: I think it would be preferable for createElement to use CEReactions

Domenic: We wanted to have as many scenarios as possible for authors to have a consistent world view wrt attributes/children

annevk: My be different if we change createElement to take attr params...

<chaals-ordhord> dcooney - new has to throw, because ECMAscript

<chaals-ordhord> BZ: we could change that, but yeah.

dcooney: new has to always throw...

Domenic: anyone NOT want createElement to use CEReactions

dcooney: I think what the spec says is fine.

Domenic: like a try/catch around the createElement and report the exception (or return an HTMLUnknownElement)

rniwa: parser does create an unknown element.

annevk: suggest we record an issue.

Domenic: I think CEReations is the right plan.

dcooney: They'll call createElement, it'll "work" but not return a custom element as expected (delaying the error case)

annevk: cloneNode/adopt cannot be made sync

createElement is a better experience if we make it sync.

annevk: we can embrace the inconsistency

Travis: can we come up with something that notifies the author of the bad construction (async)?

rniwa: the exception in sync case isn't going to help the component be more robust.

Travis: what did we do for promises?

Domenic: That was the unhandledPromise thing. Not really useful here.
... we can solve this in developer tools?
... vs. add some new blame property?
... recap: let's swap createElement for CEReactions

rniwa: We could keep sync flag set during createElement, so not propagate the exception (just like the parser)

annevk: still needs CEReactions for 'is'.
... if it can be the same code-path as the parser, that would be nice.

[Chaals calls for a break]

<AlexD> ScribeNick: AlexD

<kochi> https://github.com/w3c/webcomponents/issues/468

Domenic: It's an old proposal, let's agree or kill it. It'd be nice if you could have a custom element that behaves like this, then you could have something like a UA stylesheet that can override it

<rniwa> +q

The point against this is you could always add a Shadow DOM style sheet, but the cascade is different

This gives us lightweight syntax

rniwa: we discussed this, it adds yet another way to add styles. Makes it harder to find out where style has come from.

Cost of adding this feature seems disproprtionately high compared to the benefit

esprehn: Perhaps we don't change the cascading order

e.g. n-th child is about the shape of the DOM, so in a non component world, it makes sense. But when you insert into the shadow root, you push the order out. You want to ad styles sheets to the DOM without adding a node

Domenic: It's treated as a UA style sheet, same order in the cascade as if you appended it at the bottom

bz: You could treat it in 3 different places. You have problem of selector specificity. You can end up with UA default styles overrding the custom style

Domenic: No, you can only style the custom element itself

bz: May or may not be good enough

esprehn: 2 things there - 1 is I want to style stuff in the shadow root, 2nd is I want to style things globally (?)

If your custom element has no shadow root, there's no way to add styles

rniwa: I suggest we leave for V2

esprehn: We already see lots of people using custom-elements and adding style inside shadow root

Once you're several levels down in shadow roots, there's no way to get styles to apply to your component

You can't do it with a global style sheet, cause there's no way to drill down to your shadow root (button example)

rniwa: In order to judge the cost benefit of this feature, how many components have a shadow root just to ad style

annevk: It's a little silly there's no API to add a style sheet

esprehn: We should pull things apart a bit

It's not that bad you have to add a shadow root to add a slot

rniwa: In that API, how you going to get the style sheet?

bz: There's been talk is CSSWG about interface to get style sheet. It's reasonable for the platform anyway

esprehn: Tab is already speccing a constructable style sheet thing anyway
... having to get an element to get a CSS OM seems silly

style is special, it's dynamic - you act immediately if you add/remove it

rniwa: why don't we then wait for that API to be specced?

we need something like this, but the cost to bring to the platform is high

weinig: it's not that high

annevk: what's the observable difference between this and adding stylesheet to the shadow root?

Domenic: If the UA says color: blue, but if this says color: red, it'll be red, but if it's in the shadow root it'll be blue due to precedence

rmiwa: It's a different cascading order

esprehn: we need Tab to answer this question

annevk: if the cascading order was a problem, we could add more rules later

Domenic: If the cascading order is still good with host, then that's OK, should we punt until later?

annevk: The user agent could create an optimization path for this

dominicc: As a strawman, we need constructable style sheets no matter what

Once we have implementor experience, we can look at syntactic sugar, etc.

These style sheets won't touch the DOM tree

Subject: FORMS

dcooney: If you want a custom element that participates in the form, you need to maintain in parallel with your custom element instance, some parallel input elements that submit their content

You shouldn't have to keep track of some inputs changing state in the light DOM that ride along with your form submission

annevk: why do you need to keep track?

dcooney: they need to reflect the state

domenic: for validation? No one likes validation:-)

dcooney: a lot of browsers auto-fill forms.

esprehn: you can also do auto-restore

annevk: you want to expose type, e.g. ccard

esprehn: right now you have to put a bunch of attributes on your element to get the behaviour you want

if you hit the back button, then forward, we'll restore the form content

<rniwa> https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html

rniwa: we did make a proposal in Feb 2014 covering this

we're happy to support this, and adding more behaviours

dcooney: Looking at your proposal, looks like it's a bit different to how form association works today

It's just a detail

rniwa: this is a very preliminary proposal

you could do something like form data callback, so you can serialize it

bz: submission vs. state restoration. submission needs some key value/pair thing, so it's more complex

Domenic: my initial thought is use the form object to do this, append to it, merge, etc.

annaevk: form data only supports blobs/strings

[Travis asked about form structure]

rniwa: There are cases where the element could produce more data than entered, e.g cloning, dirty flags

maybe submission data is a subset of what you need to clone

annevk: we just need whatever API to return the name/value object or similar. Maybe we use form data and merge them

rniwa: using the form data makes sense, maybe the function should support either string or form data

Domenic: I'm worried about the ergonomics of authors getting the name correct

rniwa: that's why we say why not serialize everything as JSON

Domenic: I feel we're all excited about this and should take it to github and work on it

annevk: someone should do some refactoring in the HTML spec

We could have form data steps.

Domenic: I'll do it

<scribe> ACTION: Domenic: create form steps for the HTML spec [recorded in http://www.w3.org/2016/09/19-webapps-minutes.html#action01]

rniwa: It'd be good to have a callback to serialize a custom element

annevk: focus is the other one

CSS psuedo-classes for your form elements, stuff like that

weinig: capture behavior when you go into suspended state (non active browsing state)
... you could get away with multiple onshow/onhide handlers. [Travis asked about suspended state]

<kochi> https://github.com/w3c/webcomponents/issues/187 is the bug for form submission

<esprehn> scribe:

<esprehn> scribe: esprehn

dcooney: In the old ancient times you wrote markup, and then later you wrote markup and script and style, and now...
... with shadow dom... webcomponents...

annevk: /trolls

dcooney: apps are made of component and each one is style,script and markup, we think there's a use case for loading a definition of a component and would like an API that makes this neat and easy

<Domenic> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/HTML-Imports-and-ES-Modules.md

dcooney: we've seen a bunch of component based apps at google , we tried this with imports, but that didn't have much impl interested we want to try again with new api

bz: how does this work? what do you mean?

dcooney: page wants to say "hey I want this component" or component wants to say "hey I want this other one"
... seems like a good time to discuss integration with es modules, we didn't have them before

bz: are we talking about a declarative api for components?

dcooney: we don't know what the shape of the solution is yet, but I want to make a distinction between a comp and a custom element, comp has other stuff, script library, markup to put into shadow dom, all tied together
... just define a custom element or attachShadow is not enough, you want the whole component
... there's a define call in there somewhere, but a component is a unit with a script, style markup together

Domenic: component declarative vs imperative: we want to integrate with es modules and those support both
... definitely should integrate with es modules

rniwa: I think the use case makes sense, been saying like forever dawg
... while it's true that modules is now stable and could be integrated with html, I'm not convinced we have enough uses in the while st. we have enough knowledge to come up with a sensible import proposal and see what frameworks and libraries use
... want to evaluate the ecosystem

annevk: is this just that we want to enable folks to use more markup? or also want to support renaming things while importing?

dcooney: that does sound appealing
... polymer uses all this stuff, including html imports
... they wish it was in other browsers
... we want something interoperable

ojan: *talks loudly*
... is there something specific you want to see out of frameworks rniwa ?

rniwa: es modules defines specific module graph, we're not sure how authors will use that
... cascading load events slows down page load, maybe combining scripts to mitigate that
... people are experimenting with how to use them and we don't have enough to judge

ojan: as an example your fear is that people are finding ways to concat scripts together?

rniwa: lets say you're trying to define a component in a module, one way is to put a string in a stylesheet, another way is to extend the import semantics to import css as a separate file, hard to tell what authors will need

dcooney: we have good experience at google doing this in various frameowrks (polymer and others) that want this, but yes theres some new terriroty
... is this the same use case to packaging

dcooney: or is this something else? seems like maybe separate

tomalec: we already experienced that authors have chosen one way, using document to provide scripts/style/markup and html imports or modules make sense since they're already doing this

rniwa: sure, if you're going for familiarity, but we're discussing what should be the best api, talking about the next 50 years
... will everyone use es modules? we don't know, maybe people will hate them

Domenic: /is sad

ojan: my experience with html imports is that it completely changed my way of writing web apps
... felt like a huge change
... I'd like to see something, not comfortable just waiting
... we can start designing it now and if in 6 months no one is using es modules we can reconsider, dont' feel comfortable just sitting on it

rniwa: what I'm saying is that you're more than free to come up with a proposal but I can't give feedback since I don't know what author expectation will be

annevk: I think it's reasonable to start working
... want to avoid shipping too soon before we agree

smaug: what's the status of es modules implementations?
... do we have real feedback? firefox hasn't implemented them yet we're not sure about it

annevk: some disagreement about how they should be implemented, folks that disagree haven't created an issue yet

Domenic: this is just mozilla

rniwa: we are implementing them right now

smaug: not shipping though?

rniwa: right
... but all major browsers will support soon

dcooney: so I'm not sure of blink's exact status here, v8 is working now, but don't have blink integration yet, not shipping yet
... I think this might be a good time to look at this
... given the feedback that we should integrate with modules, if we do that how do we know? maybe mime type?

bz: what does it mean to integrate with loading?

dcooney: we're not sure yet
... maybe if you have a component that depends on a module, maybe it can wait on the load first
... if you have a script lib that depends on a component, it can include the html modules and block on them

annevk: if loader happens, how does this integrate?

dcooney: yeah lets talk about this sooner rather than later

rniwa: also big difference runs the script as if it's in the main document
... in html imports today

Domenic: modules also use the same global

rniwa: right, but less chance of leaking by mistake to global
... also scripts are forced into strict mode

dcooney: +1
... maybe html modules only allow more html modules

<Travis> esprehn: Concern I had; we shipped HTML Imports; if we don't come up with a solution soon, they'll be some workaround and we'll be constrained to standardize whatever was done.

<annevk> (We added a closing tag to <canvas>)

rniwa: concerns also about polyfill churn in the api, polyfill does one thing, but spec changes
... we have concerns because modules haven't shipped, we appreciate feedback from google and experience
... but we also want feedback from others too

dcooney: I agree more feedback is better, but I also agree with esprehn that we want to deprecate html imports and remove them

annevk: could republish that spec as a deprecated thing

dcooney: not sure where the future spec should be, we could just reuse the html imports spec to be the new html modules thing

challs: By reusing the spec we can inject uncertainty

<rniwa> Here is an old proposal by Dimitri: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/HTML-Imports-and-ES-Modules.md

annevk: in terms of messaging I think it's clearer to just mark the imports one as dead
... new one can have "html modules" as the name
... we ended up with v0, v1 naming in shadow dom, but more clear if we just use a new name

Travis: did we already enumerate specifically the things we don't like about imports?

dcooney: not sure there's a published list, ex. stylesheets apply to main document, not sure how it integrates with es modules

Domenic: my issue is that it has this weird document with a half way browsing context

dcooney: yeah there's this strange document thing that runs script

<tomalec> +q

rniwa: can people at google, ex. polymer come up with issues they had with imports?

Domenic: does magic things with custom elements

dcooney: that's well spec'ed but doesn't work well with new sync v1 elements
... I had a set of requirements on the web components proposals

tomalec: one down side of the current spec (not related to polymer) is that importing a script dependency, if you import two different docs that import the same script it gets executed twice
... found that importing a document is very useful

rniwa: It would be very useful to have that list of things you liked about it somewhere so we can eval a future proposal against it

chaals: okay break

<rniwa> scribe: rniwa

hayato: I hope this will be the year of shadow DOM.

<annevk> Shadow DOM, <iframe>, and history: https://github.com/w3c/webcomponents/issues/184

kochi: There is an issue with shadow DOM and navigation histroy
... right now, the navigation history is merged across all shadow trees with the main document.
... perhaps we can discuss it tomorrow in a breakup session.

Travis: can we discuss it now?
... what is the summary of the iframe & navigation histroy?

kochi: the navigation that happens inside an iframe creates a joint session history with the rest of the page
... it affects back and forward buttons as well as some APIs such as history.go(-1)
... which is accessible outside the shadow tree
... the question is whether we want to exclude page navigations in a shadow tree from the rest of the session history

chaals-ordhord: presumably, there are some cases in which you want to combine the session history

annevk: The basic principle of shadow DOM is that it doesn't leak but this leaks.

smaug: We could add properties to an iframe to create its own session history
... so that we can avoid merging the session history with that of the rest of the page whenever needed

kochi: can we discuss that after this session with a small group of people instead?

chaals: what's the question?
... is this hard to do?

smaug: the question is what is the right thing to do
... the important question is how we can still make the browser UI functional in the case of a separate session history

annevk: In some cases, you want to isolate session history as well as browser UI; e.g. ads
... maybe for v1, we can tackle shadow tree case where you want to have a separate session history for a shadow tree
... without integrating with the session history of the rest of the page
... we probably need to make a recommendation as to whether a session history inside a shadow tree should be reflected in browser back button or not

chaals-ordhord: the question is whether browser should let user go back using back & forward button.
... once browsers ship, developers may start depending on whatever behavior browsers have shipped
... there is one question. When a shadow tree contains an iframe e.g. for ads, does it allow user to go back inside a shadow tree e.g. by a context menu?

annevk: yeah, that's the thing we need a recommendation for.
... it's probably good to discuss it separately. we don't need the whole group for this.

chaals-ordhord: what are other topics?

hayato: one issue is adding back /deep/ combinator to static profile
... last year, we had a consensus to remove the combinator from dynamic profile for styling purposes
... However, /deep/ is not just for styling. It's also used for querySelector
... A few websites raised a concern about the lack of /deep/ combinator for when adopting shadow DOM v1 API.
... This is an issue because we'd like for developers to migrate to v1 API.

annevk: On github, hayato said we need to wait to get data as to whether we need this feature or not.

esprehn: we have authors telling us they can't switch to v1 because they don't have this feature
... there is a long list of features that can be implemented using /deep/

weinig: is this the encapsulation breaking feature? didn't we say we don't want this?

hayato: we only want this in open shadow tree

weinig: a person could implement a polyfil that does this

esprehn: this doesn't expose new capability because developers can use shadowRoot property but for the same reason querySelector exists, this will be useful

weinig: we removed from styling, but we want this?

esprehn: because we saw that some abuses of styles reaching into shadow tree to style things

weinig: but we don't expect people to do the same?

esprehn: we've seen that people use /deep/ very infrequently

<bkardell_> this is me

<esprehn> ^ in the querySelector sense, it's for particular global libraries, but not really inside per components

bkardell_: even if it weren't for imperative data, people would use in much fewer cases because the difference in the way styling and querySelector are used

hayato: the reason we wanted to remove /deep/ from dynamic profile was that it was causing a lot of performance issues
... we don't expect the same issue to happen in static profile

weinig: could you clarify what the difference is?

esprehn: there are two types of selector matching
... there are two distinct ways of applying a single rule to multiple elements versus multiple rules to multiple elements

weinig: I guess you're saying that certain implementations have trade offs
... I still don't get why if there was an issue with styles, there won't be an issue with scripts

esprehn: It's because /deep/ can reach into a shadow tree and modify style inside a shadow tree

weinig: our experience doesn't match with that.

<dcooney> scribe: dominicc

<dcooney> annevk: we reached a conclusion in the issue thread that Google would get experience with this, I don't think they have, why is it reopened? Can't v0 users use a polyfill to move to v1?

<dcooney> esprehn: performance

<dcooney> annevk: so they must have used it a lot

<dcooney> rniwa: If it is 5x slower that shouldn't matter because you're not using it much

<dcooney> esprehn: Inside a click handler if you're taking 1/2s versus some msec then that' an appreciable difference

<dcooney> weinig: so don't do that

<dcooney> esprehn: also translation framework these authors are using needs to query the whole document

<dcooney> weinig: maybe we need a selector for thing swith shadow roots

<dcooney> esprehn: Authors are stuck and not sure how to upgrade to v1 because they need this better way of doing what you already could have done inefficiently

<dcooney> rniwa: I'm not convinced we need this feature if we can write polyfills for it; it's only for perforamnce

<dcooney> bkardell_: I think the concern is performance, the polyfill is really slow

<dcooney> hayato: users can polyfill this by traversing every element; imagine if I proposed we should remove querySelector because it is polyfillable everyone would object.

<dcooney> supporting this feature natively improves the performance

<dcooney> weinig: does anyone have a succinct answer to annevk's question--do we have enough implementation experience or is this premature?

<dcooney> esprehn: We have it implemented; what more do we need?

<dcooney> hayato: We have v0 implementation experience but we didn't do it in v1 because it was controversial.

<dcooney> rniwa: there's one author commenting in the issue who is doing top-down query to send a message to components

<dcooney> this is the use case we don't want to support

<dcooney> hence we should not do this; this is what you find in the dynamic profile. There's nothing preventing people use this.

<dcooney> esprehn: That's an argument againts lots of things, css custom properties can cause large invalidations; you can write a slow for loop

<dcooney> you have to querySelector(*) and walk, it's slow

<dcooney> rniwa: that assumes deep is your first selector

<dcooney> Travis: if there was a selector to identify elements with open shadow roots attached; you could just recurse on those n=5 elements

<dcooney> did you change the behavior of the API so it's the same name, it now just goes through shadow roots?

<dcooney> esprehn: there were two versions, :shadow and :deep, one was one level down, one was N levels down

<dcooney> tomalec: If we use shadow for style for all the elements that want custom style then selecting open shadow roots will be a lot of elements

<dcooney> esprehn: it's like saying you could polyfill descendant selectors by iterating in querySelector, but we did implement it inside querySelector because we can do something way faster

<dcooney> annevk: the other thing rniwa brought up, there's some disagreement about how often ShadowRoot will be used

<dcooney> it's a bit different to descendant selector; we don't know how often people will go across the boundary

<dcooney> rniwa: we want a concrete use case of developers who can't use v1 api, saying a lot of people are saying it doesn't tell me anything; show useful specifics of this website

<dcooney> esprehn: We did this already; that's why we added deep. there was a meeting, with use cases, CSS WG added deep to support those use cases.

<dcooney> rniwa: I've never seen it, provide those to us

<dcooney> weinig: I'm confused. The timeline is, there was no deep, CSS WG went through use cases and added deep. It was determined too fragile and removed.

<dcooney> esprehn: deep was removed from the dynamic profile, but still in static

<dcooney> weinig: now, we have an issue in shadow DOM to reinstate deep fully

<dcooney> but there's some concerns in implementer feedback which we don't understand

<dcooney> in parallel the Chrome team

<dcooney> is getting feedback from adopters that they need this feature to upgrade

<dcooney> is that the timeline?

<dcooney> esprehn: Yes, sort of, in the meantime there was communcation to authors that deep would still be in the static profile.

<dcooney> annevk: there's no question about bringingi it back fully?

<dcooney> esprehn: (missing)

<dcooney> weinig: can we have specifics on people still seeing an issue who haven't been able to upgrade and why they need it in their use cases. That's it.

<dcooney> If we're going to add/not remove/etc.

<dcooney> ... we need that.

<dcooney> chaals: that's the story esprehn told us--people using translation attributes and wanting to find them without dom walks

<dcooney> annevk: that doesn't work for closed shadow roots

<dcooney> weinig: that's a broken use case

<dcooney> esprehn: they don't use closed shadow roots

<dcooney> annevk: but they may not control that

<dcooney> esprehn: the framework is part of chrome UI

<dcooney> they want to upgrade to implement this translation system but it's too much of a perf hit

<dcooney> Travis: Is the provider the same as the conusmer? So there's a lot of flexibility.

<dcooney> esprehn: yes; there's lots of people using this for the same purpose who want to upgrade to v1 but they're stuck.

<dcooney> rniwa: Why do they need deep? They could just do translation some other way.

<dcooney> esprehn: It's a separation of concerns. I don't understand.

<dcooney> rniwa: You're breaking encapsulation; the idea that I need to transnlate and need to go through all the shadow boundaries doesn't seem like a good pattern to me. it seem slike an antipattern . we want to discourage authors from doing this.

<dcooney> hayato: We have open and closed shadow roots and let authors decide. If they choose open, they have a reason to use deep combinator. open shadow roots aren't offering complete encapsulation.

<dcooney> rniwa: But the argument I heard in the past is open shadom DOM is closed for people working on Polymer

<dcooney> but walking shadow roots seems to break encapsulation completely

<dcooney> if you're localizing components, components should support localization and not rely on dom walks. That seems like a legacy approach to translation. Each component should have an API to respond to translation requests.

<dcooney> esprehn: Maybe. The content exists, we are asking them to come to our party but we haven't given htem the right hats to wear. We want people to use this.

<dcooney> Separate to that, everyone in devtools wants to find elements in the page.

<dcooney> Travis: write it in devtools

<dcooney> weinig: devtools aren't the web

<dcooney> annevk: (missing)

<dcooney> esprehn: We're going to end up with some way to do this anyway

<annevk> I said that if devtools needs it, they need it for closed shadow trees too

<dcooney> chaals: I'm hearing Google say we really really need this

<dcooney> everyone else, not a good idea

<dcooney> are there any non-Google advocates?

<dcooney> how serious is the opposition?

<dcooney> bkardell_: the worry is it's a footgun

<dcooney> Travis: Where do you stop? Do you need getElementById?

<dcooney> chaals: You stop at some arbitrary point of concensus until that changes.

<dcooney> I'm not seeing any consensus outside google.

<dcooney> annevk: We're not sure how far we want to embrace open shadow roots, we need to see what developers are doing and what the patterns are

<dcooney> with iframe history, the argument was we should just allow it because we already leak a bit anyway

<dcooney> bkardell_: so why not leak everything...

<dcooney> annevk: so the non-google parties are a bit more conservative

<dcooney> chaals: there's no consensus to do this, you need to add this to devtools and beat consensus out of people

<dcooney> esprehn: We got feedback and we're reporting it

<dcooney> chaals: That wasn't convincing

<dcooney> rniwa: It's hard to judge without specifics, reach out to those people and ask them to share feedback

<dcooney> Travis: You made a good point about these people not coming to our party, maybe their use case is not a component scenario, I know we want it to be widely used

<dcooney> hayato: the second item is supporting ::part, custom pseudo elements

<dcooney> esprehn: I thought I changed the text of this, but...

<dcooney> we have from authors that they want the ability to style custom elements

<dcooney> annevk: this is issue 300?

<esprehn> https://docs.google.com/presentation/d/1ZE73bQ0VVRcMNwPmqAJ3V4t7brg3a2PsUOmxuqOOFxE/edit#slide=id.g16b44b8be8_0_58

<annevk> https://github.com/w3c/webcomponents/issues/300

<dcooney> https://github.com/w3c/webcomponents/issues/300

<dcooney> (people look for adapters for vga, etc.)

<dcooney> rniwa: Are we talking about issue 300?

<dcooney> (all): yes

<dcooney> esprehn: https://docs.google.com/presentation/d/1ZE73bQ0VVRcMNwPmqAJ3V4t7brg3a2PsUOmxuqOOFxE/edit#slide=id.g16b44b8be8_0_58

<dcooney> rniwa: is anyone against this?

<dcooney> we're very interested in this

<dcooney> esprehn: we wanted to discuss the problem space a bit

<dcooney> Domenic: I want to learn how it overlaps with apply

<dcooney> esprehn: (referring to slides) there are use cases

<dcooney> theme my page, theme a complex subwidget, theme a region of a page

<dcooney> library authors want to expose sub component styling points

<dcooney> big libraries want hooks, which is well supported by custom properties eg light theme, dark theme

<dcooney> widgets want to expose subwidget parts, custom properties have spooky global effects

<dcooney> part is better for the subwidget use case

<dcooney> but it interacts badly with theming, there needs to be a republishing mechanism to take a part and re-export it as your API surface

<dcooney> annevk: makes sense

<dcooney> esprehn: (example of selector which drills through component parts)

<dcooney> theming works well with custom properties

<dcooney> authors seemed happy with this

<dcooney> so we probably need both parts, custom properties and ::part

<dcooney> we should work together for syntax for republishing parts

<dcooney> Travis: custom properties don't do that?

<dcooney> esprehn: they're globally inherited

<dcooney> parts expose an entire thing

<dcooney> annevk: expose an element in a shadow tree; custom properties style everything including in shadow trees

<dcooney> esprehn: (describes how to do part with custom proprties but it is bad)

<dcooney> part lets you explicitly publish

<dcooney> Travis: custom properties are part of your API

<dcooney> styling API

<dcooney> rniwa: custom properties work in one direction outside in; part is exposing something from the inside out

<dcooney> esprehn: We need both of these, for the two different kinds of use cases

<dcooney> separately we looked at a mixin feature called @apply, see slides

<dcooney> it is hard to optimize

<dcooney> the use case is limited it helps you avoid typing a set of variable declarations at the site

<dcooney> but we should do part first because the use cases are different and we may not need it

<dcooney> Domenic: Why not?

<dcooney> esprehn: Because there's no way to target the right thing.

<dcooney> Say you have up steppers and down steppers.

<dcooney> Domenic: You do @apply up-stepper and down-stepper

<dcooney> esprehn: But if you use properties to theme them, then they apply to broadly

<dcooney> Domenic: You do the variables in the upstepper block.

<dcooney> esprehn: And redeclare them everywhereL

<dcooney> esprehn: ... example coming to IRC ...

<dcooney> esprehn: that does work, but it's a different API contract; as you compose deeper and deeper components the variable still apply

<dcooney> part lets you expose upstepper and downstepper but not other things

<dcooney> Domenic: (missing)

<dcooney> esprehn: But people end up using variables...

<dcooney> Domenic: Custom pseudoelements might look better but I want to understand if they're different

<dcooney> esprehn: I think it breaks down if you're nesting

<dcooney> Travis: Rossen was nervous about implementing this because it requires a bottom-up percolation in CSS cascade

<dcooney> I talked to him about part (in CSS WG) not @apply; did not talk to him about @apply. @apply is still top down.

<dcooney> esprehn: We thought part seemed good, variables seemed good, authors seemed happy about that

<dcooney> s/rosyn/Rossen/

<Domenic> https://gist.github.com/domenic/fa84dddf918014b2fd9c853ba9b4aa86

<dcooney> annevk: the last time we talked about this, adding part, maciej brought up having some way to restrict which properties apply, for example color not abspos.

<dcooney> weinig: our experience is that's useful, all of our controls--builtins--require that.

<dcooney> Travis: builtins

<dcooney> weinig: Yes, what does it mean to make the text placeholder element position: fixed ; it's not reasonable

<dcooney> Travis: (missing), weinig: missing

<Domenic> updated https://gist.github.com/domenic/fa84dddf918014b2fd9c853ba9b4aa86 to show how they seem equivalent to me

<dcooney> esprehn: Maybe we need to have a whitelist. the platform uses !important for most things at this level. there were some discussion of whiteslist which allowed *

<dcooney> weinig: and potentially it can go deeper, is it just properties or specific values?

<dcooney> Domenic: I wrote some sample code,

<dcooney> to show why they seem equivalent to me

<dcooney> you have up-stepper inside a shadow root and you'd apply it from the outside.

<dcooney> then you'd alternatively expose the part from script and write ::part

<dcooney> esprehn: If you then build a widget that contains two steppers, and then high up in the document you apply up stepper, the variables inherit across shadow boundaries.

<dcooney> Domenic: isn't that like *::part?

<dcooney> esprehn: Encapsulation is different.

<scribe> scribe: rniwa

hayato: the shadow DOM specification in the past had this feature
... We removed this feature because we invented /deep/ combinator
... but then we removed the /deep/ combinator

chaals-ordhord: Are there other issues?
... are people have a thought on whether we want @apply?

Domenic: I think the conclusion was to do it at least later

weinig: is the spec far enough?

esprehn: the CSS WG wrote a spec and we implemented @apply but we'd like to pull back and instead discuss :part.

rniwa: rniwa: Approaching :part makes sense to me.

Domenic: Let's talk about global custom attributes
... people had interests in Github, and this may avoid some of the concerns people had with is=
... you can apply multiple lifecycle callbacks on a single element per attribute
... so each attribute can get callback for connected, disconnected, and attributeChanged

annevk: would callbacks be per custom attribute?

weinig: is the idea that document.registerCustomAttributeObserver
... and any time an attribute of that name is added to an element, the callback is called?

Domenic: People want to use this feature to listen to lifecycle callbacks on an arbitrary element
... people who use is= attribute can describe this use case better

annevk: Some kind of i18n attributes can be implemented across shadow boundary for example
... This may take way reasons having to use open shadow trees

bkardell_: can mutation observers across shadow boundaries?

annevk: no, they're scoped to each tree

dcooney: This is a pretty light weight feature that benefit use cases
... If an element want to refer to another element via an attribute, they'd like to track all these attributes globally
... and having this attribute would help implementing such a feature

annevk: that's like how id attribute works
... they need to update mapping whenever id attribute changes

dcooney: id might be a special case in blink because we do work laizly

annevk: we can do a similar dash (-) syntax and expose it

dcooney: if you're paranoid custom element author, then restricting attribute name to dashed names, they can avoid leaking internals

annevk: well but if you override the prototype of objects, they can still leak property

dcooney: custom elements would operate in closed shadow trees so it makes this global custom element to work across shadow boundaries
... It would be shame if people started adding callbacks to all the elments
... in the early days of web components, there was a proposal for decorators
... to be able to add and remove callbacks on elements and some vendors thought this was a bad idea
... is this a deal breaker? do we not want people to give this anti-pattern?

chaals: we can continue discussing this with four people who are interested in this idea
... we can take a break now and talk about it later

annevk: I'd like to hear Apple's opinion on this

<dcooney> scribe: dominicc

<dcooney> rniwa: when we heard about use cases of is attribute we talked about htem a lot

<dcooney> all the use cases are mixin use cases

<dcooney> it was obvious to us in those cases you have to be able to add multiple mixins

<dcooney> like localization, or form submission participation

<dcooney> you have to be able to apply multiple

<dcooney> so we felt is was not good for that

<dcooney> so we prefer this approach

<dcooney> however we haven't reviewed a detailed proposal so we're not sure

<dcooney> the use case sounds OK but there's only one vague proposal

<dcooney> this area sounds interesting and preferable to the is attribute

<scribe> scribe: rniwa

Domenic: I'd like to hear from Microsoft

Travis: I think we're generally okay with is= proposal
... I'd like to understand more about this new proposal.

Domenic: This would be a top-level custom element thing. You probably pass in a set of callbacks instead of a class
... and they get callbacks only when a given attribute is present on an element

esprehn: why not a class?

Domenic: because there will be no construction of the class.

smaug: Could you write some pseudo code to show us the idea?

Domenic: Okay, let me try to describe the processing model.
... It certainly has connected and disconnected callbacks

Travis: is connected callback for element or attribute

Domenic: for element

dcooney: this may end up storing data on maps element
... so using a closure function might be fine

Domenic: if we can figure out when & where to run constructor, then maybe class is okay
... however, this has an issue because "this" no longer refers to element

esprehn: Storing states on element would avoid leaks

annevk: if we use composition for state but for styles we have to manipulate, we're only solving half the problem
... if we're going to composition route, you have to own the problem space.
... If composition is the pattern we adopt here, then we should be using composition everywhere
... composition means keeping all the states and styles related to a custom attribute in one object
... and removing all of them altogether when the attribute is removed

Travis: Matching lifecycle of an attribute per element might be important
... Unlike custom element, here, you get constructor when an attribute is added to an element

Domenic: when I said mixin earlier, I meant ES6 mixins

annevk: Once you register a new attribute, should we also automatically add an IDL attribute?

dcooney: in some use cases, it does require modifying prototype e.g. adding property

Domenic: we could let authors do it themselves
... we don't want to spec reflection in browser
... another problem people are asking is namespacing for attributes
... we may not need it but we need to pay attention to it

esprehn: it's unclear what authors need since we haven't implemented such a feature

annevk: data- is the only example here and it's a very special attribute

dcooney: It seems like there is a consensus that this isn't really an awful idea
... so we should go ahead and try to prototype it

esprehn: This also removes the use case for /deep/ and global mutation observer
... In some pages, it's important to wait for some special element to appear in the page for telemetry
... using a custom attribute would avoid having to pierce through shadow trees to find all special elements

annevk: this would probably help solve the previously stated chrome UI use case for /deep/ which needed i18n attribute

chaals: thanks everyone

- DRAFT -

TPAC 2016 Web Components

19 Sep 2016

Attendees

Contents

Open issues with "web components"

Custom elements feature requests

ISSUE-552

custom elements--what to do when constructor throws during upgrade, cloning, etc.

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output