07:22:05 <RRSAgent> RRSAgent has joined #webapps
07:22:05 <RRSAgent> logging to http://www.w3.org/2016/09/19-webapps-irc
07:25:02 <xiaoqian> zakim, this is Web Platform WG: Web Components
07:25:02 <Zakim> got it, xiaoqian
07:28:17 <smaug> smaug has joined #webapps
07:40:01 <tantek> tantek has joined #webapps
07:51:39 <dom> dom has joined #webapps
07:53:12 <anssik> anssik has joined #webapps
07:53:54 <xiaoqian> xiaoqian has changed the topic to: Web Components: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-19TPAC-1.md
08:02:12 <chaals-ordhord> chaals-ordhord has joined #webapps
08:02:16 <Gus> Gus has joined #Webapps
08:03:52 <Gus_> Gus_ has joined #webapps
08:04:24 <Hyunjin> Hyunjin has joined #webapps
08:04:33 <taekyu> taekyu has joined #webapps
08:04:39 <annevk> annevk has joined #webapps
08:04:54 <dcooney> dcooney has joined #webapps
08:05:05 <bz> bz has joined #webapps
08:05:11 <dcooney> +present Dominic Cooney, Google
08:05:39 <koji> koji has joined #webapps
08:06:08 <yoichio> yoichio has joined #webapps
08:07:16 <aboxhall> aboxhall has joined #webapps
08:07:41 <kochi> +present Takayoshi Kochi, Google
08:08:01 <xiaoqian> present+ xiaoqian (Cindy), W3C
08:08:43 <kenneth_> kenneth_ has joined #webapps
08:09:39 <annevk> Scribenick: annevk
08:09:42 <hjlee> hjlee has joined #webapps
08:09:56 <nolanlawson> nolanlawson has joined #webapps
08:10:02 <xiaoqian> present+ Hayato Ito (Google)
08:10:10 <xiaoqian> present+ Takayoshi Kochi (Google)
08:10:14 <IanPouncey> IanPouncey has joined #webapps
08:10:19 <weinig> weinig has joined #webapps
08:10:22 <tomalec> tomalec has joined #webapps
08:10:22 <annevk> Topic: Open issues with "web components"
08:10:25 <LJWatson> LJWatson has joined #webapps
08:10:31 <xiaoqian> present+ Chaals (Yandex)
08:10:41 <annevk> At 11AM a11y folks will join to talk about ARIA
08:10:50 <xiaoqian> present+ Léonie Watson (TPG)
08:10:52 <kborchers> kborchers has joined #webapps
08:10:59 <xiaoqian> present+ Dominic Cooney (Google)
08:11:11 <dcooney> Note: meeting agenda page: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-19TPAC-1.md
08:11:16 <yosi_google> yosi_google has joined #webapps
08:11:17 <annevk> Domenic: I'd like to discuss some v2 stuff
08:11:31 <annevk> Topic: Custom elements feature requests
08:11:36 <xiaoqian> present+ Boris (Moz)
08:11:38 <plh> plh has joined #webapps
08:11:39 <Domenic> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-19TPAC-1.md#custom-elements
08:11:47 <xiaoqian> present+ annevk (Moz)
08:11:55 <annevk> Domenic: should we add more callbacks?
08:11:57 <cabanier> cabanier has joined #webapps
08:12:02 <annevk> Domenic: user agent-type stylesheets?
08:12:23 <annevk> Domenic: allowing more parsing modes than just parsing like <asdf>
08:12:33 <annevk> annevk: which callbacks?
08:13:05 <annevk> Domenic: cloning is not exposed atm, e.g., <input> preserves internal state, you cannot duplicate that with custom elements
08:13:10 <xiaoqian> present+ Domenic Denicola (Google)
08:13:25 <annevk> Domenic: cloning seems fairly trivial to add
08:13:34 <annevk> bz: the main implementation issue is the callback throwing
08:13:55 <annevk> dcooney: when cloning you already have to deal with the constructor throwing
08:14:02 <annevk> bz: so... not a new issue
08:14:19 <annevk> dcooney: I think you get an element back, but it's in a failed state of sorts
08:14:24 <annevk> (nodding in the room)
08:14:34 <chaals> chaals has joined #webapps
08:14:42 <annevk> dcooney: there's a question of when the cloning steps run
08:15:12 <annevk> Domenic: they'd run after the tree is cloned, all at once
08:15:13 <chaals> rrsagent, make minutes
08:15:13 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html chaals
08:15:22 <annevk> Domenic: seems doable
08:15:26 <annevk> (some more nodding)
08:15:31 <xiaoqian> RRSAgent, make log public
08:16:07 <annevk> bz: do we want to run them in tree order? before or after its kids?
08:16:32 <annevk> dcooney: callbacks run after everything is cloned
08:17:12 <annevk> dcooney: the simplest way would be parents before children
08:17:21 <annevk> bz: might want to discuss with components authors
08:17:33 <annevk> Domenic: motivation is emulating builtins
08:17:38 <annevk> Domenic: those don't depend on children
08:18:04 <jamesn> jamesn has joined #webapps
08:18:28 <annevk> koji: can those callbacks mutate the tree?
08:18:37 <annevk> Domenic: yes, but it's well-defined
08:18:49 <yosin> yosin has joined #webapps
08:18:52 <li_lin> li_lin has joined #webapps
08:19:08 <xiaoqian> present+ Koji_Ikuno
08:19:20 <xiaoqian> present+ hober
08:19:33 <annevk> Domenic: I'd like to add them in tree order
08:19:42 <annevk> annevk: like
08:19:44 <annevk> chaals: like
08:20:16 <annevk> dcooney: we could get some more feedback and decide Friday
08:20:21 <annevk> dcooney: just to double check
08:20:25 <annevk> Domenic: SGTM
08:20:44 <annevk> weinig: I don't think we're against it, sounds fine
08:21:11 <annevk> weinig: there's a question of how often it's used
08:21:30 <annevk> bz: it would help to have actual use cases
08:22:27 <annevk> Domenic: if HTML modules takes off, you really need cloning
08:22:58 <annevk> Domenic: so need to get some more feedback
08:23:18 <annevk> Domenic: but generally sounds acceptable
08:23:46 <annevk> dcooney: are there other hooks?
08:24:32 <Florian> Florian has joined #webapps
08:25:05 <annevk> annevk: I think cloning is the last
08:25:31 <annevk> bz: there's a callback for all attributes being set from the parser
08:26:20 <annevk> annevk: also a callback for end tags seen by the parser (for <script>)
08:26:58 <chaals-ordhord> present+ AleD, Eliott
08:27:02 <jcraig> jcraig has joined #webapps
08:27:07 <chaals-ordhord> s/AleD/AlexD
08:27:26 <annevk> bz: [describes how <img> only starts fetching once all attributes are set]
08:28:23 <annevk> bz: all-attributes-set callback is used by form, media elements for mute flag (seems like impl detail), menuitem elements have something
08:28:34 <annevk> bz: don't see anything for <img> actually in Gecko's code
08:28:39 <jungkees> jungkees has joined #webapps
08:28:59 <esprehn> present+ esprehn
08:29:23 <weinig> weinig has joined #webapps
08:29:25 <annevk> rniwa: to get back to cloning, it's weird that when the callback runs you already have children
08:29:34 <annevk> Domenic: I think that's inherent to the custom elements design
08:30:14 <annevk> esprehn: I noticed that the parser is super spammy compared to innerHTML with a bunch of microtasks
08:30:31 <annevk> bz: [notes that <img> does do it]
08:31:17 <annevk> esprehn: I'd like for the HTML parser to do this less, and only run constructors when the parser yields
08:32:21 <annevk> esprehn: I'm not suggesting that the parse would no longer synchronously construct elements
08:32:58 <annevk> dcooney: oh, so you're talking about when the microtasks run with respect to the callbacks
08:33:20 <annevk> Domenic: the design of microtasks is that they run after a callback
08:33:53 <annevk> Domenic: it sounds like we're changing when to run microtasks during parsing, which would be less deterministic
08:34:28 <annevk> s/we're changing/you're proposing/
08:34:29 <Gus> Gus has joined #webapps
08:34:40 <kborchers> present+
08:35:01 <annevk> esprehn: you already have this weirdness due to innerHTML, which is used by the application after the initial parse
08:35:13 <annevk> bz: this is the same as with DOM event handling
08:35:31 <annevk> bz: you get microtasks between listeners if the UA dispatches the event, but not when script does
08:35:55 <annevk> esprehn: the parser used to have a single microtask point whenever the parser yields
08:36:11 <annevk> esprehn: with lots of custom elements you might get thousands of checkpoints
08:36:17 <annevk> Domenic: is an empty checkpoint slow?
08:36:42 <annevk> esprehn: with mutation observers, if you observe the document...
08:36:50 <annevk> Domenic: DON'T OBSERVE THE DOCUMENT!
08:37:07 <annevk> [it's common]
08:37:26 <annevk> smaug: I don't like the inconsistency
08:37:41 <sangwhan> rrsagent, make minutes
08:37:41 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html sangwhan
08:37:42 <annevk> esprehn: it's already true, with innerHTML
08:37:50 <annevk> smaug: then you have JS on the stack
08:38:33 <annevk> esprehn: I think when we did microtasks we didn't envision this many callbacks
08:40:26 <annevk> annevk: microtasks will run when the parser yields, custom elements or not
08:40:32 <annevk> annevk: so it's already non-deterministic
08:40:51 <annevk> annevk: the only difference here would be to not run microtasks after custom element creation and callbacks during parsing
08:41:02 <annevk> weinig: can we quantify the problem?
08:41:29 <annevk> [the problem being the spammyness of microtasks]
08:42:24 <annevk> esprehn: I guess you have to take my word on there being thousands of custom elements on the page
08:42:30 <annevk> esprehn: C++ spec is written using them
08:42:33 <annevk> weinig: not impressed
08:43:01 <annevk> dcooney: empty microtask isn't free, but fairly cheap, so interested in hearing about document-wide mutation observers
08:43:22 <annevk> esprehn: [couple of cases]
08:43:37 <annevk> esprehn: global attributes is a thing that people use them for, but separate problem
08:43:49 <annevk> weinig: maybe it isn't, if we solve that, they might not need global observers
08:44:49 <annevk> esprehn: it's hard to quantify, but not doing 20k checkpoints is going to be cheaper
08:45:11 <annevk> dcooney: what's the cost of callbacks vs the microtask checkpoint? I haven't looked at it much yet, but curious
08:45:19 <annevk> esprehn: depends, more callbacks is also more expensive
08:45:33 <annevk> rniwa: is the main reason performance?
08:45:39 <annevk> esprehn: I also think it's [better]
08:46:54 <annevk> rniwa: since this is a brand-new API, it's hard to say whether the proposed behavior is better
08:46:56 <chaals-ordhord> present+ Ojan
08:46:57 <esprehn> present+ ojan
08:47:12 <annevk> ojan: is there a use case for the current behavior?
08:47:27 <annevk> Domenic: that's the point of microtasks, to run asap once the stack is clean
08:47:31 <annevk> smaug: yup
08:48:09 <annevk> esprehn: I thought the reason was mostly that the page can be in a consistent state [missed]
08:48:29 <annevk> smaug: yes, but I think we should maintain the original invariants
08:48:48 <annevk> esprehn: so let's generalize, why don't microtasks run between function calls?
08:49:06 <annevk> esprehn: arguably custom element callbacks are function calls
08:49:21 <annevk> chaals: consistency argument is not convincing, web isn't
08:50:09 <annevk> rniwa: reason for microtasks was not batching, but was that mutation observers wouldn't step on each other
08:50:54 <annevk> rniwa: big problem with mutation events was that you could easily end up with recursion
08:51:27 <annevk> esprehn: another thing, Fx still doesn't implement promise handling correctly
08:51:35 <annevk> esprehn: so folks can't depend on this
08:51:45 <ToddKim> ToddKim has joined #webapps
08:51:54 <annevk> esprehn: so I don't buy consistency, since it's been broken forever
08:52:06 <annevk> esprehn: [cites Safari bug I missed]
08:52:24 <Todd> Todd has joined #webapps
08:52:46 <annevk> dcooney: I buy the argument that custom elements synchronous mode is novel territory and we could run into problems
08:53:19 <annevk> Domenic: I think a good next step would be to write this problem up, discuss with developers, and ideally quantify it a bit
08:53:30 <wilsonpage> wilsonpage has joined #webapps
08:53:30 <annevk> dcooney: hard to get that since folks don't build infeasible things
08:53:41 <annevk> Domenic: they build slow things though
08:53:59 <jcraig> jcraig has joined #webapps
08:54:04 <annevk> bz: they also build bizarre workarounds for infeasible things
08:54:23 <annevk> chaals: do as Domenic says
08:54:30 <Byungjin> Byungjin has joined #webapps
08:54:54 <annevk> smaug: could this be indicative of a problem with custom elements rather than microtasks?
08:54:59 <wenyu_dong> wenyu_dong has joined #webapps
08:55:05 <annevk> esprehn: [censored]
08:55:19 <tantek> tantek has joined #webapps
08:55:26 <annevk> weinig: could give developers control over when they run
08:56:08 <annevk> esprehn: keep giving developers more control over low-level things, but they require fairly sophisticated libraries
08:56:53 <annevk> esprehn: as developers take more control, microtask checkpoints run less
08:57:08 <annevk> esprehn: so perhaps giving control over running them synchronously, or batching, would help
08:57:40 <xiaoqian> RRSAgent, make minutes
08:57:40 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html xiaoqian
08:59:21 <xiaoqian> s/Koji_Ikuno/Koji_Ishii
09:01:24 <xiaoqian> present+ weinig_Apple, Niwa_Apple
09:01:47 <xiaoqian> RRSAgent, make minutes
09:01:47 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html xiaoqian
09:03:27 <IanPouncey> present+ IanPouncey
09:07:15 <jungbin> jungbin has joined #webapps
09:10:34 <jcraig> jcraig has joined #webapps
09:12:09 <Domenic> https://github.com/w3c/webcomponents/issues/113
09:13:33 <rniwa> rniwa has joined #webapps
09:14:16 <Travis> scribe: Travis
09:14:42 <Travis> Domenic: Some HTML elements do weird things that some people like. (Template, etc.)
09:15:10 <Travis> .. may require some weird symbols...
09:15:22 <Travis> .. folks aren't sure that we should mess with the parser.
09:15:27 <Travis> .. what do folks think?
09:15:49 <Travis> rniwa: Definitely not for v1.
09:16:38 <Travis> .. for v2, better off not doing it (I could be convinced--maybe). Show me the use case.
09:16:59 <Travis> dcooney: Lots of polymer folks wrap template
09:17:11 <Travis> .. templates for stamping shadow dom
09:17:30 <Travis> esprehn: I'm fine punting to later version. is attribute works for this.
09:18:02 <Travis> .. example: polyfil some css feature.
09:18:41 <Travis> tobie use cases for template binding--I think this
09:19:14 <tomalec> tomalec has joined #webapps
09:19:38 <Travis> rniwa: not convinced adding parser hooks are the right way to solve those use cases.
09:19:44 <chaals> rrsagent, draft minutes
09:19:44 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html chaals
09:20:09 <Travis> Domenic: Understand this is a little redundant with 'is' attribute.
09:20:21 <Travis> .. should we encourage custom tag names, or encourage 'is'?
09:20:52 <Todd> Todd has joined #webapps
09:20:53 <Travis> esprehn: unconvinced that we want to expose parser extensibility.
09:21:09 <Travis> .. script/style/template use with 'is' is fine.
09:21:32 <Travis> .. self-closing tags are the only thing maybe worth exploring?
09:22:29 <Travis> dcooney: worried the behavior might be a surprise to authors.
09:23:08 <Travis> bz ..?
09:23:20 <chaals-ordhord> s/../I don
09:23:39 <chaals-ordhord> s/don/don´t know
09:23:40 <Travis> esprehn: we have a Proof-of-concept that shows one direction is fast (23x)
09:23:55 <Byungjin> Byungjin has joined #webapps
09:23:59 <Travis> .. xml-like (basic parsing)
09:24:08 <esprehn> attribute quoting required, all tags require closing, etc.
09:24:29 <Travis> bz parser can tokenize fast without knowing what script tags...
09:25:43 <Hyunjin> Hyunjin has joined #webapps
09:25:47 <Travis> dcooney: foo-bar#! (only parse-ible in template mode)
09:25:55 <Travis> rniwa: "show me the use cases"
09:26:21 <Travis> esprehn: OK... but should we ban tag names that end with certain symbols (e.g., !)
09:26:35 <Travis> .. v1 spec is very flexible.
09:26:51 <taekyu> taekyu has joined #webapps
09:26:56 <Travis> Domenic: use cases also served by not modifying the parser.
09:27:05 <Travis> .. would love to land with "not doing this"
09:27:20 <Travis> chaals: anyone wish to do this? (hoping for someone to speak up)
09:27:42 <Travis> annevk: some folks found that maybe a mode switch (at the beginning) would be tenable?
09:28:01 <Travis> esprehn: separate topic of allowing a doctype-switch that puts you in a different world...
09:28:13 <Travis> .. doesn't address other cases (PCDATA and other states)
09:28:20 <Travis> .. slightly orthogonal discussion.
09:28:41 <Travis> rniwa: whether ! is allowed... doesn't appear to be allowed per the grammar.
09:29:04 <Travis> .. can be safely allowed, but is an incompatible parser change. Use cases have to demonstrate the need.
09:29:11 <Travis> Domenic: CAN WE FIX createElement???
09:29:28 <Travis> .. createElement is more restrictive than the parser.
09:29:50 <ohs5197> ohs5197 has joined #webapps
09:30:03 <Travis> annevk: it's already more permissive than XML (can use a ':')
09:30:37 <Travis> esprehn: first letter has to be lowercase... (Looking at implementation...)
09:31:04 <Travis> Domenic: we investigated why first letter has to be lowercase.
09:31:29 <Domenic> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/YyqxpIPU-0E/k5gu7i9dBwAJ
09:31:31 <Travis> annevk: re: createElement: after a long thread nobody wanted to do the research to see if it was compatible.
09:32:08 <Travis> dcooney: looking for data on the web compatibility of fixing createElement.
09:32:35 <Travis> bz: what is the compat worry? have createElement throw in fewer cases... and this is a concern?
09:32:49 <Travis> dcooney: maybe a browser should try it...
09:33:02 <Travis> bz: we can put some telemetry in case.
09:33:11 <yoichio> yoichio has joined #webapps
09:33:28 <Travis> Domenic: will file a Chrome bug; everything will be happy :-)
09:33:50 <Travis> dcooney: new callbacks wanted
09:34:25 <Travis> .. code never knows when it is getting the last attribute changed callback.
09:34:32 <li_lin> li_lin has joined #webapps
09:34:37 <Travis> .. ex: input knows its type when the element is created.
09:34:47 <Travis> .. 2nd case: end-tag-done.
09:34:59 <Travis> .. cite: script element end tag (which does lots of interesting things)
09:35:20 <Travis> .. if the markup does one-time processing at the end this is a good use case for you.
09:35:56 <Travis> .. we see native elements doing this.
09:36:33 <Travis> .. ex: youtube comment example using anchor tags (want to process like a macro)
09:36:59 <Travis> .. it's basically performance, but there is also a semantic difference
09:37:24 <Travis> bz: ex: <object> doesn't try to figure out what to do until it has all its children.
09:37:50 <Travis> .. <select> picks the selected item (if none are marked selected) when all options are available.
09:38:09 <Travis> .. <textarea> detects form-state restoration.
09:38:18 <Travis> .. <title> elements--this is just optimization
09:38:41 <Travis> rniwa: all those cited examples must detect dynamic changes via DOM api?
09:39:06 <Travis> .. I'm more comfortable with a children-changed callback
09:39:21 <Travis> esprehn: don't want to add another child-changed callback...
09:39:50 <Travis> .. users won't expect half of a select control to render, etc.
09:40:18 <Travis> rniwa: I'm less comfortable with adding a specific callback for end-of-element parsing, than for fixing mutation observer.
09:40:47 <Travis> dcooney: we can imagine a children-changed callback (maybe with a flag--this is the last one)
09:41:29 <Travis> rniwa: maybe a single callback could work? when all children are known?
09:42:20 <Travis> dcooney: could maybe make it work for attributes too.
09:42:43 <Travis> [discussion of how attributes are not known before element is created]
09:43:54 <Travis> bz: img tags ignore all there attribute sets until the image is added to the document.
09:44:45 <esprehn> the spec wants you to do it at mictotask now IIRC, blink doesn't look at the img attributes until then I think
09:44:45 <Travis> rniwa: might need an argument on connectedCallback to say it was done by parser.
09:45:45 <Travis> bz: what about document fragments?
09:45:47 <rniwa> +q
09:46:33 <Travis> dcooney: connectedCallback fires for any document (authors expected to check defaultView)
09:47:00 <chaals-ordhord> ack rn
09:47:07 <Travis> .. for the flag--it would represent the entire subtree
09:47:30 <Travis> bz: going back to what img is doing...
09:47:53 <Travis> rniwa: maybe the flag is needed at construction
09:48:15 <Travis> .. the flag would indicate created-by-parser.
09:48:23 <sangchul> sangchul has joined #webapps
09:48:27 <Travis> bz: script uses this flag today.
09:48:53 <Travis> dcooney: If you use selector-checking right after the super() call, you can detect some things
09:48:58 <Travis> .. it's a hack.
09:49:42 <Travis> esprehn: crazy suggestion: how about a parserSetAttributes callback--it gives you all attributes in a list.
09:49:58 <Travis> .. its in place of the other attributeChanged scenario.
09:50:03 <Travis> .. just sayin'
09:50:30 <Hyunjin> Hyunjin has joined #webapps
09:50:40 <Travis> [bikeshedding the new idea]
09:51:21 <Travis> dcooney: all the expensive work will be done, not a perf concern
09:51:32 <Travis> Domenic: nice solution for attributes, not sure for children
09:51:50 <Travis> dcooney: for <input>...
09:51:55 <Travis> Domenic: any other examples?
09:52:03 <jungbin> jungbin has joined #webapps
09:52:26 <rniwa> +q
09:52:35 <Travis> annevk: there is no concept in "standards" that the all-attributes-present flag is there.
09:52:48 <Travis> .. not sure we should expose to script.
09:53:09 <Travis> weinig: we don't expose--it's for optimization
09:53:15 <xiaoqian> ack rniwa
09:53:44 <Travis> bz: cloning uses the same thing the parser does.
09:55:48 <jamesn> jamesn has joined #webapps
10:00:14 <richardschwerdtfeger> richardschwerdtfeger has joined #webapps
10:00:50 <jnurthen> jnurthen has joined #webapps
10:03:38 <WalterTamboer> WalterTamboer has joined #webapps
10:03:40 <jcraig> jcraig has joined #webapps
10:04:47 <chaals-ordhord> chaals-ordhord has joined #webapps
10:05:01 <tomalec> tomalec has joined #webapps
10:05:49 <tripu> tripu has joined #webapps
10:05:56 <MichaelC> MichaelC has joined #webapps
10:06:06 <LJWatson> rrsagent, make minutes
10:06:06 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html LJWatson
10:06:18 <jcraig> scribe: jcraig
10:06:30 <AlexD> AlexD has joined #webapps
10:06:48 <jcraig> TOPIC: ISSUE-552
10:06:49 <jcraig> https://github.com/w3c/webcomponents/issues/552
10:07:23 <jcraig> HTML 1:1 Role Parity for Custom Elements
10:07:41 <LJWatson> Meeting: TPAC 2016 Web Components
10:07:49 <jcraig> RS: summarizes other proopsal for extensibility
10:07:52 <LJWatson> chair: Chaals
10:07:57 <LJWatson> rrsagent, make minutes
10:07:57 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html LJWatson
10:08:04 <annevk> Accessibility Object Model is here: https://a11y-api.github.io/a11y-api/spec/
10:08:24 <jcraig> RS: Dominic Denicola mentions extensibilit. I
10:08:46 <jcraig> aboxhall: AOM look at the explainer not the spec: https://github.com/a11y-api/a11y-api/blob/master/explainer.md
10:09:21 <jcraig> RS: UIAutomation has done something like this for WAPA
10:09:28 <yoichio> yoichio has joined #webapps
10:09:43 <yosin> yosin has joined #webapps
10:09:49 <jcraig> denicola: About roles mapping, we'd like each html element mapped
10:10:11 <jcraig> for example, color pickers
10:10:19 <jcraig> q+
10:10:28 <jcraig> not frameset
10:11:04 <IanPouncey> jcraig: this was one of the goals for ARIA 1.1, to have HTML role parity so we added cell.
10:11:19 <IanPouncey> We didn't get close to 1:1 partity.
10:11:32 <hjlee> hjlee has joined #webapps
10:11:34 <IanPouncey> For things like video elements there was no way to get parity
10:11:40 <SteveF> SteveF has joined #webapps
10:12:00 <IanPouncey> Problem with existing role like sliders the only way to control this is through keyboard events.
10:12:17 <IanPouncey> Hopefully we'll get ways to get direct attribute manipulations
10:12:23 <chaals-ordhord> q+
10:12:31 <chaals-ordhord> ack jc
10:12:39 <chaals-ordhord> q-
10:12:52 <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.
10:12:59 <richardschwerdtfeger> q+
10:13:07 <weinig> weinig has joined #webapps
10:13:23 <jcraig> dominic: would it more harmful to have custom video elements that don't use those roles?
10:13:39 <dcooney> s/dominic/domenic
10:13:44 <jcraig> we'd like like to do both
10:14:13 <chaals-ordhord> ack ri
10:14:19 <jcraig> jcraig: I'm happy with the staged approach
10:14:36 <tantek> tantek has joined #webapps
10:14:43 <jcraig> RS: everything today uses propagation of [physical] events (click etc)
10:14:52 <Hyunjin> Hyunjin has joined #webapps
10:15:11 <jcraig> RS: We'd need to may device-side changes???
10:15:30 <jcraig> q+ to ask which device side changes
10:15:36 <weinig_> weinig_ has joined #webapps
10:15:37 <rniwa> +q
10:16:25 <SteveF> q+
10:16:57 <jcraig> travis: video cited as an example.. why is that not a problem for sliders?
10:17:02 <jcraig> jcraig: it is.
10:17:33 <chaals-ordhord> q+
10:17:55 <jcraig> RS: lists "pause video" as an example... could be from physical media keys
10:18:07 <jcraig> no way to respond to that from a custom elements
10:18:54 <jcraig> discussion re: event bubbling
10:19:29 <jcraig> anne: for event delegation (e.g. which video element to pause)
10:19:31 <chaals-ordhord> q-
10:19:46 <jcraig> ack me
10:19:46 <Zakim> jcraig, you wanted to ask which device side changes
10:20:10 <richardschwerdtfeger> q?
10:20:46 <richardschwerdtfeger> q+
10:21:38 <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.
10:22:09 <jcraig> RS: associating specific data with a control pattern: MS UIA
10:22:38 <chaals-ordhord> ack rn
10:22:42 <jcraig> IndieUI associated increment with sliders
10:23:12 <richardschwerdtfeger> q+
10:23:46 <jcraig> 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.
10:24:06 <chaals-ordhord> ack steq+
10:24:09 <jcraig> q+ to mention IndieUI tried and failed to do that
10:24:15 <jcraig> ack me
10:24:15 <Zakim> jcraig, you wanted to mention IndieUI tried and failed to do that
10:24:47 <dcooney> scribenick: dominicc
10:25:06 <dcooney> stevef: re: the 1:1 mapping and reaching parity for elements which have a display-sense meaning
10:25:16 <dcooney> that does not seem to be an agreed concept
10:25:29 <dcooney> annevk pushed back on that and did not want to recreate roles or features in HTML
10:25:35 <dcooney> how much consensus is there on thatL
10:25:36 <dcooney> ?
10:25:45 <dcooney> domenic: annevk pushed back but everyone else is in favor
10:26:10 <ericc> ericc has joined #webapps
10:26:12 <jcraig> q+ to mention a 1:1 mapping would not require platform role changes
10:26:17 <jcraig> ack steve
10:26:21 <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
10:26:31 <dcooney> chaals: what if you get them in HTML inSVG
10:26:37 <LJWatson> LJWatson has joined #webapps
10:26:54 <dcooney> we tried to do this in indie UI. we are trying to do this piece by piece, do you want this incrementally
10:27:04 <dcooney> annevk: I think I changed my mind about adding a role for figure
10:27:20 <dcooney> if figure has a role today, then sure, having a role value for that makes sense
10:27:30 <jcraig> ack me
10:27:30 <Zakim> jcraig, you wanted to mention a 1:1 mapping would not require platform role changes
10:27:31 <dcooney> but if there's an element that doesn't have a role like div we shouldn't add one
10:27:49 <dcooney> jcraig: this doesn't necessarily mean there would be a pltaform role change to have a 1:1 mapping
10:28:00 <dcooney> dpub WG which specifies epub added a bunch of rolse
10:28:20 <dcooney> es--bibliography link--to programatically manipulateepub
10:28:32 <dcooney> we're not going to handle that differently in the product/platform side
10:28:46 <dcooney> the user knows if they're in a bibliography the link there is a bib link
10:28:54 <dcooney> but there should be a role for span and div generics
10:28:57 <dcooney> and for web components
10:29:05 <dcooney> to differentiate div and group
10:29:11 <dcooney> And that should map to the platform APIs
10:29:24 <dcooney> stevef: You can use an aria figure as a container
10:29:28 <jcraig> s/be a role for span /be a single "generic" role for span /
10:29:32 <dcooney> rich:
10:29:48 <jcraig> s/stevef:/rich:/
10:29:56 <dcooney> rich: your point earlier about (rniwa) about making it for everything not just a11y
10:30:16 <dcooney> msft basically piggybacked on top of automated testing so they have patterns for everything eg slider
10:30:26 <dcooney> instead of reinventing the wheel can we use that
10:30:36 <chaals-ordhord> ack r
10:30:40 <dcooney> msft has been using this as a standardized platform across desktop, xbox, across the board
10:30:45 <dcooney> can we pull that out to javascript?
10:30:49 <dcooney> we should at least investigate it
10:31:04 <dcooney> travis: UI is really a simple simple simple concept
10:31:14 <koji> s/UI/UIA/
10:31:16 <dcooney> it's three things--a concept label, related states and related actions
10:31:28 <dcooney> it's a package with event handlers and property values you can attach onto things
10:31:30 <richardschwerdtfeger> q+
10:31:34 <dcooney> a lot of that is baked into html already
10:31:44 <dcooney> it has elements, attributes and properties, and events and event handlers
10:31:51 <dcooney> what's missing is the conveyance of the context
10:31:57 <jcraig> q+ to respond re: properties used with the event handlers
10:32:04 <dcooney> I like starting with, let's take HTML and make sure it's fully experssive
10:32:21 <dcooney> there's the context, when you create web components you compose them in new ways
10:32:40 <dcooney> but how do I express the context for things like video, a sighted user can click on an area they see for pause
10:32:42 <jcraig> q+ to say e.g. min/max/step value for sliders, various properties for media elements
10:32:52 <dcooney> but there may not be a way for ax tech to know about pause
10:32:53 <chaals-ordhord> q+
10:33:09 <dcooney> with a web component you're using the platform but the intent is to create a semantically new thing
10:33:16 <jcraig> axk r
10:33:19 <jcraig> ack r
10:33:22 <dcooney> so there needs to be a way to express the new context and new states
10:33:33 <chaals-ordhord> ack r
10:33:36 <dcooney> rich: aria is one way, saying something is a video tag is not enough
10:33:41 <dcooney> for a list box you can do best practices
10:33:53 <dcooney> but aria ran out of gas asking how do you do this in a device independent way
10:34:01 <dcooney> for example controlling where you are in a listbox or a gesture
10:34:02 <lilin> lilin has joined #webapps
10:34:15 <jcraig> ack me
10:34:15 <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
10:34:18 <dcooney> so rather than having device-specific handlers, if you could do this in a device independent way
10:34:22 <rniwa> +q
10:34:22 <dcooney> that's the whole picture
10:34:40 <dcooney> jcraig: slider and video are hard to make accessible today so I keep brining them up
10:34:51 <dcooney> the slider may have platfor mevents like increment and decrement and a value
10:35:04 <dcooney> but the platform should be able to set the value, query for the value, min, max and step
10:35:12 <dcooney> we had all of those in aria, not sure about step
10:35:28 <dcooney> but look at video, it has available tracks, media properties like tracks, are they audio descriptions,
10:35:33 <dcooney> the native properties have that
10:35:39 <dcooney> but the complexity skyrockets
10:35:39 <LJWatson> LJWatson has joined #webapps
10:35:48 <dcooney> I like the idea of a general interface for properties and actions
10:36:05 <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
10:36:14 <dcooney> over a custom video for example
10:36:41 <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.
10:36:54 <dcooney> jcraig: but maybe the button knows aircraft and you can extend it
10:37:01 <dcooney> travis: I use pokemon as an ekample
10:37:14 <jcraig> s/button knows/browser knows/
10:37:28 <dcooney> chaals: say I make aircraft, can ryosuke take that and extend it to make starship control, or is it a bag of buttons
10:37:33 <dcooney> how do you do that discoverability
10:37:34 <jcraig> s/ekample/example/
10:37:34 <richardschwerdtfeger> q+
10:37:37 <dcooney> and do you need toL
10:37:38 <dcooney> ?
10:37:45 <dcooney> maybe the individual controls are enough
10:37:54 <richardschwerdtfeger> s/toL/to/
10:38:08 <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
10:38:13 <dcooney> unsighted users don't have that
10:38:14 <xiaoqian> q?
10:38:24 <dcooney> jcraig: aria-role description does that to some extent
10:38:32 <dcooney> it's in 1.1 but not supported on every platform
10:38:37 <LJWatson> +1 Travis
10:38:42 <Todd> Todd has joined #webapps
10:38:43 <dcooney> any events or queryable properties should be associated with an explicit role
10:38:44 <chaals-ordhord> ack ch
10:39:02 <dcooney> eg container for a slide in slideshare is a generic group but you can describe it as a slide
10:39:11 <chaals-ordhord> ack rn
10:39:18 <dcooney> rniwa: travis' point that custom elements poses a new challegnge is a good point
10:39:22 <MichaelC> q+ jason
10:39:34 <dcooney> but that was always the case, web authors always come up with ways to express their content
10:39:43 <jcraig> s/describe it as a slide/describe it as a slide for assistive tech users/
10:39:44 <dcooney> we added media, article in the past 5 years
10:40:06 <dcooney> the platform should provide the building blocks, people build random things, and then the platform should consolidate the common patterns
10:40:15 <dcooney> so media controls, sliders, calendars we should support
10:40:28 <dcooney> but we also should provide a way for authors to describe actions users can take
10:40:31 <chaals-ordhord> q+ janina
10:40:44 <dcooney> accessibility API is a good API for that latter part--describing what a user can do with a control
10:40:55 <dcooney> we need to bridge the gap with a mid tier API
10:41:04 <dcooney> jcraig: by accessibility API do you mean AOM?
10:41:11 <dcooney> rniwa: yes Accessibility object model
10:41:27 <dcooney> rich: THe most expensive thing a developer has to do to add accessibility is adding keyboard support
10:41:37 <dcooney> removing that cost would make it much easier to add
10:41:43 <jcraig> q?
10:41:43 <dcooney> so what are the next steps?
10:41:54 <rniwa> +q
10:41:56 <dcooney> jason white (IRC?)
10:42:01 <jcraig> ack rich
10:42:04 <jcraig> ack jason
10:42:14 <dcooney> jason: i am involved in IAC global (missed)
10:42:26 <dcooney> makes accessibility/interactions for education
10:42:35 <jcraig> s/jason:/jasonjgw:/
10:42:41 <dcooney> have to reoder elements or create ordered pairs of elements from two sets
10:42:47 <dcooney> these are not common actions on the web
10:42:54 <dcooney> they would be well suited as web components
10:43:03 <dcooney> you can make accessible implementations of them with ARIA
10:43:18 <dcooney> but they don't fit into the predefined widget categories
10:43:23 <dcooney> if we add IMS' use cases
10:43:28 <chaals-ordhord> ack ri
10:43:35 <dcooney> then web application authors in domains like education
10:43:41 <dcooney> will continue bespoke interaction types
10:43:47 <dcooney> can we devise robust specifications
10:44:01 <dcooney> so the interactions are accessible without going through the standardization process
10:44:01 <jcraig> q+ to mention interaction pattern mix-ins
10:44:16 <dcooney> so this is a voice in favor of thinking carefully how extensibility is provided
10:44:20 <jcraig> q+ to say (from IndieUI)
10:44:28 <dcooney> and there are domain-specific interactions outside
10:44:42 <chaals-ordhord> q+
10:44:43 <richardschwerdtfeger> q?
10:44:51 <chaals-ordhord> q+ lisa
10:44:54 <chaals-ordhord> q-
10:44:56 <dcooney> jenina: plug for 1pm session on the need to identify the contextual information
10:44:57 <jcraig> ack janin
10:45:02 <chaals-ordhord> ack ja
10:45:07 <dcooney> eg this is starship controller, this part is the warp drive, this is the viewscreens
10:45:12 <dcooney> that turns out to be a wide use case
10:45:15 <jcraig> s/jenina/janina/
10:45:22 <dcooney> digital publishing needs ... something
10:45:26 <dcooney> longdesc
10:45:36 <dcooney> we're trying to move beyond it and have it apply to more than just images
10:45:47 <dcooney> we can associate a description with something
10:45:53 <dcooney> harvard admission test
10:45:56 <dcooney> here's a butterfly
10:46:05 <dcooney> print out a braille diagram of it, what can you say about it?
10:46:14 <dcooney> we need a way to make these containers and we need annotations,
10:46:21 <dcooney> we have it covered with aria-details
10:46:36 <dcooney> there are a lot of disability use cases where people don't use accessibility tech
10:46:41 <jcraig> q?
10:46:42 <dcooney> I want to point out it is a wide queue
10:46:50 <jcraig> ack rn
10:47:02 <dcooney> rniwa: going back to brand new components, the comment we need an extensible API
10:47:14 <chaals-ordhord> ack rn
10:47:18 <dcooney> despite what I said earlier there are some things that's hard to support without standardization
10:47:25 <dcooney> say someone wants to make a math equation editor
10:47:35 <dcooney> on some platforms there may be a native one the browser can hook up
10:47:49 <dcooney> how do you describe that in absence of an aria role for math eqn editor
10:47:54 <chaals-ordhord> q+
10:47:56 <dcooney> I don't know how you describe that without the role
10:48:09 <dcooney> on some obscure platofrm there may be an ancient egyptian text editor
10:48:15 <dcooney> but how do you convey that without a role?
10:48:26 <dcooney> the AOM API must let you build and customize the accessibility tree
10:48:34 <richardschwerdtfeger> q+
10:48:47 <dcooney> but I don't think we can support any concieveable widget, human imagination can come up with a lot of crazy stuff
10:49:03 <dcooney> one path forward is adding more aria roles, there are many that could be easily added like article
10:49:15 <dcooney> questions about frameset, canvas which don't have semantic meaning
10:49:18 <chaals-ordhord> q+ annevk
10:49:23 <dcooney> we should judge them case by case
10:49:29 <jcraig> ack me
10:49:30 <Zakim> jcraig, you wanted to mention interaction pattern mix-ins and to say (from IndieUI)
10:49:35 <dcooney> but elements with roles, we should describe the roles
10:49:53 <Travis> q+ matthew
10:49:56 <dcooney> jcraig: jason white jgw mentioned there are lots of controls like math editor, infinite expanding treees
10:50:07 <dcooney> it would be challenging to make these types of things
10:50:20 <dcooney> maybe they just expose latex and as long as you can edit that you can do whatever you want
10:50:31 <annevk> q-
10:50:42 <dcooney> for those cases we come up with new APIs, we'll look at things that exist and then talk about standardizing
10:50:54 <dcooney> We may not know what someone will create but a lot extend metaphors
10:51:03 <dcooney> this was part of indieui or (missing)
10:51:18 <jessebeach> jessebeach has joined #webapps
10:51:18 <dcooney> eg we don't know this map but it has scale and zoom; this one has pan or move
10:51:29 <chaals-ordhord> s/(missing)/intentional events
10:51:33 <dcooney> so the idea of behavioural mixins like activate (effectively click) or value change
10:51:42 <mck> mck has joined #webapps
10:51:47 <dcooney> then we can infer the context in the same way as a sighted user infers the visual presentation
10:51:56 <chaals-ordhord> ack li
10:51:58 <SteveF> q+
10:52:04 <dcooney> lisa: facilitator of accessibily TF
10:52:08 <mck> q?
10:52:17 <dcooney> when we made the first version of ARIA in 2006 we made a high level abstraction
10:52:21 <dcooney> to get the model of interativitiy
10:52:29 <dcooney> this is just going to specification now (1.1)
10:52:42 <dcooney> even though the presentation changed, we have a high level representation
10:52:54 <dcooney> you can often reduce very different things to these core concepts like selected option
10:53:09 <richardschwerdtfeger> q?
10:53:13 <dcooney> I think aria addresses a lot of these core concepts well if you look at what you can model instead of worked examples
10:53:27 <jcraig> lisa: Lisa Seeman, facilitator of Cognitive TF for Accessibily
10:53:43 <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
10:53:53 <dcooney> we just want to be able to do that stuff and tell people what that is.
10:53:58 <dcooney> Who agrees?
10:54:04 <richardschwerdtfeger> +1
10:54:14 <dcooney> seems to be general agreement, sense of where we are
10:54:20 <rniwa> +q
10:54:48 <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
10:54:53 <dcooney> then we can standardize those
10:55:09 <dcooney> we have a way of "just give me a straight out text description" and that's horrid but in theory it works
10:55:32 <dcooney> you get descirption, instructions, the instructions don't quite work and they are in a foreign language
10:55:37 <dcooney> like a flying car controller
10:55:47 <dcooney> so you start there with the description which is better than nothing
10:55:52 <jcraig> q?
10:55:56 <jcraig> ack cha
10:56:04 <dcooney> but is there anything more useful we can do until there are millions of these?
10:56:07 <jcraig> ack ri
10:56:29 <dcooney> rich: when you have one of these objects you want to know how to interact with it
10:56:44 <dcooney> so we need to define these as a starting point showing people how to interact with these
10:56:53 <jcraig> q+ to discuss action items: role parity (i think we're in agreement).
10:57:00 <dcooney> this will save developers a ton of money and time if they don't have to deal with device specific issues
10:57:07 <dcooney> how do our working groups interact?
10:57:27 <dcooney> can we tie AOM and this new API for describing the interaction pattern together
10:57:42 <dcooney> We need to tie together the semantic description and the bundle of interfaces
10:57:49 <jcraig> q+ to say action/events/query custom props within web components (general agreement but no clear path forward)
10:57:50 <chaals-ordhord> ack ch
10:57:50 <dcooney> I think this is a  Web Platform thing we should be working on together
10:57:57 <dcooney> It was going to be done in an incubator group
10:58:04 <jcraig> ack matt
10:58:08 <dcooney> the accessibility object model seeds the effort; what do we do today?
10:58:16 <chaals-ordhord> zakim, close the queue
10:58:16 <Zakim> ok, chaals-ordhord, the speaker queue is closed
10:58:16 <dcooney> matt keen facebook, aria WG member
10:58:27 <MichaelC> s/keen/king/
10:58:33 <dcooney> matt: there are certain aspects we're discussing that are bing massively overcomplicated
10:58:35 <dcooney> think of the user
10:58:45 <dcooney> you talk about starship, video, slider
10:59:08 <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.
10:59:37 <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
10:59:43 <aboxhall> q+
10:59:47 <dcooney> there should be no distinction between the general and specific cases
11:00:11 <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
11:00:17 <dcooney> we should be thinking about that generic problem
11:00:29 <dcooney> there may be a default action or gesture, there's something that gets done by that
11:00:33 <jcraig> q?
11:00:36 <SteveF> q-
11:00:39 <dcooney> what is it that gets done? how do they discover that?
11:00:51 <dcooney> increment/decrement to set upper/lower limits on an integral
11:01:02 <dcooney> a particular component has a particular vocabulary
11:01:18 <dcooney> authors should be able to develop applications that communicate in the context of the application
11:01:34 <jcraig> ack rn
11:01:39 <dcooney> the general (starship) and specific (slider) problems are the same and should have uniform solution
11:01:47 <dcooney> rniwa: suggestion, I don't want to start a long discussion
11:01:57 <dcooney> perhaps we should add a default aria role to custom elements
11:01:58 <jcraig> +1 to default aria role
11:02:20 <dcooney> to define a default aria role , people need to add a tag and a role attirbute which seems redundant
11:02:51 <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%
11:03:06 <dcooney> rniwa: it doessn't solev everything but would work for article
11:03:15 <jcraig> ack me
11:03:15 <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
11:03:18 <Zakim> ... clear path forward)
11:03:19 <dcooney> domenic: support but does not want to preempt AOM
11:03:25 <dcooney> q+ dominicc
11:03:45 <dcooney> jcraig: it seems everyone is on board with role parity and changed role for a web component
11:04:19 <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
11:04:28 <dcooney> AOM may be the vehicle but it is limited in scope
11:04:38 <dcooney> we have a proposed session on wednesday for that
11:05:04 <dcooney> aboxhall: noone said affordances yet but that is really what we are talking about with roles
11:05:13 <dcooney> travis was talking about the same thing without using that word
11:05:27 <dcooney> a (missed) is not an affordance, it is built out of affordances
11:05:31 <dcooney> these evolve over time
11:05:38 <dcooney> typically the visual affordance came first
11:05:52 <dcooney> it would be good as we are building visual affordances it would be great to have a way to build that
11:06:13 <Travis> dcooney: got feedback from polymer that they were interested in the default role.
11:06:15 <chaals-ordhord> s/(missed)/starship controller
11:06:26 <Travis> .. also that components would like a tabindex
11:06:54 <dcooney> dominicc: polymer wants role and tabindex
11:06:56 <dcooney> domenic, etc.
11:07:05 <dcooney> domenic: noted, it is complicated later
11:07:13 <dcooney> jcraig: it's complicated, scoping, etc.
11:07:35 <xiaoqian> RRSAgent, make minutes
11:07:35 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html xiaoqian
11:07:44 <slightlyoff> excited to see role parity
11:12:00 <wilsonpage> wilsonpage has joined #webapps
11:35:45 <smaug> smaug has joined #webapps
11:41:09 <Geunhyung_Kim_> Geunhyung_Kim_ has joined #webapps
11:57:12 <chaals> chaals has joined #webapps
12:01:35 <rniwa> rniwa has joined #webapps
12:02:50 <SteveF> SteveF has joined #webapps
12:05:47 <MichaelC> MichaelC has joined #webapps
12:07:46 <jungbin> jungbin has joined #webapps
12:09:19 <Florian> Florian has joined #webapps
12:09:19 <IanPouncey> IanPouncey has joined #webapps
12:09:50 <LJWatson> LJWatson has joined #webapps
12:10:26 <sangchul> sangchul has joined #webapps
12:11:15 <Florian> Florian has joined #webapps
12:12:56 <AlexD> AlexD has joined #webapps
12:13:18 <jnurthen> jnurthen has joined #webapps
12:17:31 <jamesn> jamesn has joined #webapps
12:24:32 <bz> bz has joined #webapps
12:32:46 <Travis> scribe: Travis
12:33:22 <Travis> Topic: custom elements--what to do when constructor throws during upgrade, cloning, etc.
12:33:24 <chaals-ordhord> chaals-ordhord has joined #webapps
12:33:42 <Travis> rniwa: report error, or propagate an exception.
12:33:54 <Travis> .. prefer throwing, but maybe we should discuss this.
12:34:03 <Travis> dcooney: I think the spec (today) makes sense (in this area)
12:34:28 <Domenic> https://github.com/w3c/webcomponents/issues/525
12:34:31 <Travis> .. in cases where there is script on the stack, it says to report an exception, which I think is the right thing to do.
12:34:50 <Travis> .. I think reporting exception is more helpful to authors.
12:34:57 <Travis> .. Spec is doing the best it can...
12:35:10 <Travis> .. Currently reports exceptions synchronously as much as possible.
12:36:08 <Travis> .. cloneNode: can clone lots of custom elements.
12:37:21 <Travis> .. exception throws, what happens to the next [queued] constructions/callbacks
12:38:07 <MichaelC_> MichaelC_ has joined #webapps
12:38:08 <Travis> bz: event dispatch depends (who/how this was started)
12:38:21 <Travis> .. to the web author this is not very predictable.
12:38:46 <Travis> dcooney: cloneNode has no early exists.
12:38:50 <Travis> .. [today]
12:39:04 <tomalec> tomalec has joined #webapps
12:39:08 <AlexD> AlexD has joined #webapps
12:39:19 <Travis> Domenic: it's not an early exit, its an interruption of the custom element queue.
12:40:03 <Travis> .. [thinking out loud] you have to do some kind of clearing of the queue...
12:40:20 <Domenic> https://github.com/w3c/webcomponents/issues/525
12:41:01 <Travis> rniwa: I agreed for innerHTML (makes sense for parser).
12:41:14 <Travis> .. for DOM API, I don't think that matches author expectation.
12:41:43 <chongz> chongz has joined #webapps
12:43:55 <Travis> dcooney: Are we talking about the constructor running specifically, or an issue with all callbacks?
12:44:18 <Travis> Domenic: I think we're talking about splitting into two things parser vs. DOM API.
12:44:29 <Travis> rniwa: Parseerror vs other.
12:44:40 <Travis> .. propagating an exception is more inline with authors.
12:45:05 <LJWatson> LJWatson has joined #webapps
12:45:12 <mck> mck has joined #webapps
12:45:27 <Travis> bz: seems easier to avoid inconsistent state in the cloneNode case than innerHTML case.
12:45:36 <Travis> annevk: should we re-throw in the adoptNode case?
12:45:49 <Travis> .. appendChild would throw?
12:46:11 <Travis> rniwa: Still think propagate the exception.
12:46:27 <Travis> Domenic: Don't like that one failure stops everyone else from running.
12:47:40 <bkardell_> bkardell_ has joined #webapps
12:47:51 <Travis> tomek: +1
12:48:10 <Travis> dcooney: I think createElement already threw--and you're only creating one object.
12:48:27 <Travis> .. for appendChild that's not the case--there are multiple ones.
12:49:58 <Travis> rniwa: I think it's weird to have constructor not throw, but everywhere else throw
12:50:36 <Travis> dcooney: there are options for "aborting".
12:50:50 <Travis> .. I don't think we need to do that.
12:51:12 <Geunhyung> Geunhyung has joined #webapps
12:51:13 <Travis> .. operations that didn't throw exceptions still won't.
12:51:31 <Travis> annevk: parser/createElement--we invoke the constructor as part of the call--it's sync.
12:51:42 <Travis> .. other things are deferred actions.
12:52:49 <wy-dong> wy-dong has joined #webapps
12:53:02 <Travis> chaals: consistency is a hard argument.
12:53:28 <Travis> rniwa: just report exception breaks down...
12:54:02 <taekyu> taekyu has joined #webapps
12:54:09 <Hyunjin> Hyunjin has joined #webapps
12:54:28 <Travis> .. it's hard for author to anticipate what will happen when the constructor has an issue -- there is different behavior depending on scenario.
12:54:33 <Todd> Todd has joined #webapps
12:54:42 <Byungjin> Byungjin has joined #webapps
12:54:59 <Travis> bz: you might want consistent behavior depending on how a library was implemented...
12:55:08 <Travis> .. but that's probably not feasible.
12:55:54 <jcraig> jcraig has joined #webapps
12:56:10 <Travis> rniwa: it's about what the author can expect.
12:56:18 <Travis> .. how about createElement should not throw?
12:56:32 <Travis> Domenic: Here's my model.
12:56:41 <Travis> .. parser/createElement sync create elements.
12:56:51 <Travis> .. parser has nowhere to throw to.
12:57:06 <Travis> .. createElement does, just sugar for the constructor, so it throws.
12:57:22 <Travis> .. is it too confusing to have the sugar?
12:58:14 <Travis> dcooney: createElement is a special case?
12:58:47 <oh9405> oh9405 has joined #webapps
12:58:51 <Travis> rniwa: I think it would be preferable for createElement to use CEReactions
12:59:18 <Travis> Domenic: We wanted to have as many scenarios as possible for authors to have a consistent world view wrt attributes/children
12:59:23 <weinig> weinig has joined #webapps
13:00:08 <Travis> annevk: My be different if we change createElement to take attr params...
13:00:30 <ericc> ericc has joined #webapps
13:01:30 <chaals-ordhord> dcooney - new has to throw, because ECMAscript
13:01:44 <chaals-ordhord> BZ: we could change that, but yeah.
13:01:50 <Travis> dcooney: new has to always throw...
13:02:30 <Travis> Domenic: anyone NOT want createElement to use CEReactions
13:02:37 <Travis> dcooney: I think what the spec says is fine.
13:04:44 <Travis> Domenic: like a try/catch around the createElement and report the exception (or return an HTMLUnknownElement)
13:04:52 <sangchul> sangchul has joined #webapps
13:05:03 <Travis> rniwa: parser does create an unknown element.
13:05:26 <Travis> annevk: suggest we record an issue.
13:05:42 <Travis> Domenic: I think CEReations is the right plan.
13:06:05 <tantek> tantek has joined #webapps
13:06:37 <Travis> dcooney: They'll call createElement, it'll "work" but not return a custom element as expected (delaying the error case)
13:07:14 <Travis> annevk: cloneNode/adopt cannot be made sync
13:07:25 <Travis> createElement is a better experience if we make it sync.
13:07:47 <jcraig> jcraig has joined #webapps
13:07:49 <yosin> yosin has joined #webapps
13:08:09 <Travis> annevk: we can embrace the inconsistency
13:09:06 <Travis> Travis: can we come up with something that notifies the author of the bad construction (async)?
13:09:45 <Travis> rniwa: the exception in sync case isn't going to help the application be more robust.
13:10:24 <Travis> Travis: what did we do for promises?
13:10:40 <rniwa> s/help the application/help the component/
13:10:41 <jcraig> jcraig has joined #webapps
13:10:51 <Travis> Domenic: That was the unhandledPromise thing. Not really useful here.
13:12:01 <Travis> Domenic: we can solve this in developer tools?
13:12:14 <Travis> .. vs. add some new blame property?
13:13:20 <Travis> Domenic: recap: let's swap createElement for CEReactions
13:14:33 <Travis> rniwa: We could keep sync flag set during createElement, so not propagate the exception (just like the parser)
13:14:48 <Travis> annevk: still needs CEReactions for 'is'.
13:15:44 <AlexD> AlexD has joined #webapps
13:15:47 <Travis> .. if it can be the same code-path as the parser, that would be nice.
13:16:10 <Travis> [Chaals calls for a break]
13:17:50 <Todd_> Todd_ has joined #webapps
13:19:29 <IanPouncey> IanPouncey has joined #webapps
13:19:36 <hjlee> hjlee has joined #webapps
13:22:24 <jcraig> jcraig has joined #webapps
13:25:00 <AlexD> AlexD has joined #webapps
13:25:18 <AlexD> ScribeNick: AlexD
13:25:19 <kochi> https://github.com/w3c/webcomponents/issues/468
13:26:08 <tomalec> tomalec has joined #webapps
13:26:14 <Todd> Todd has joined #webapps
13:26:30 <AlexD> 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
13:26:35 <rniwa> +q
13:26:58 <AlexD> The point against this is you could always add a Shadow DOM style sheet, but the cascade is different
13:27:03 <yosin> yosin has joined #webapps
13:27:10 <AlexD> This gives us lightweight syntax
13:27:21 <chaals-ordhord> zakim, open the queue
13:27:21 <Zakim> ok, chaals-ordhord, the speaker queue is open
13:27:50 <AlexD> rniwa: we discussed this, it adds yet another way to add styles. Makes it harder to find out where style has come from.
13:28:29 <AlexD> Cost of adding this feature seems disproprtionately high compared to the benefit
13:28:31 <taekyu> taekyu has joined #webapps
13:28:40 <AlexD> Elliot: Perhaps we don't change the cascading order
13:28:52 <AlexD> s/Elliot/esprehn/
13:29:49 <AlexD> 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
13:30:22 <AlexD> Domenic: It's treated as a UA style sheet, same order in the cascade as if you appended it at the bottom
13:31:00 <AlexD> 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
13:31:14 <AlexD> Domenic: No, you can only style the custom element itself
13:31:20 <AlexD> bz: May or may not be good enoug
13:31:25 <AlexD> s/enoug/enough/
13:31:40 <jcraig> jcraig has joined #webapps
13:31:50 <jungbin> jungbin has joined #webapps
13:32:01 <AlexD> esprehn: 2 things there - 1 is I want to style stuff in the shadow root, 2nd is I want to style things globally (?)
13:32:23 <AlexD> If your custom element has no shadow root, there's no way to add styles
13:32:45 <AlexD> rniwa: I suggest we leave for V2
13:33:18 <AlexD> esprehn: We already see lots of people using custom-elements and adding style inside shadow root
13:33:47 <AlexD> Once you're several levels down in shadow roots, there's no way to get styles to apply to your component
13:34:26 <sangchul> sangchul has joined #webapps
13:34:30 <AlexD> You can't do it with a global style sheet, cause there's no way to drill down to your shadow root (button example)
13:35:04 <AlexD> rniwa: In order to judge the cost benefit of this feature, how many components have a shadow root just to ad style
13:35:23 <jcraig> jcraig has joined #webapps
13:36:13 <AlexD> annevk: It's a little silly there's no API to add a style sheet
13:36:23 <AlexD> esprehn: We should pull things apart a bit
13:36:36 <AlexD> It's not that bad you have to add a shadow root to add a slot
13:37:22 <AlexD> rniwa: In that API, how you going to get the style sheet?
13:37:49 <AlexD> bz: There's been talk is CSSWG about interface to get style sheet. It's reasonable for the platform anyway
13:38:09 <AlexD> esprehn: Tab is already speccing a constructable style sheet thing anyway
13:38:28 <SteveF> SteveF has joined #webapps
13:38:31 <AlexD> esprehn: having to get an element to get a CSS OM seems silly
13:39:58 <AlexD> style is special, it's dynamic - you act immediately if you add/remove it
13:40:13 <AlexD> rniwa: why don't we then wait for that API to be specced?
13:40:40 <jungbin> jungbin has joined #webapps
13:41:58 <AlexD> we need something like this, but the cost to bring to the platform is high
13:42:08 <AlexD> weinig: it's not that high
13:42:38 <AlexD> annevk: what's the observable difference between this and adding stylesheet to the shadow root?
13:43:12 <AlexD> 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
13:43:31 <AlexD> rmiwa: It's a different cascading order
13:43:42 <AlexD> esprehn: we need Tab to answer this question
13:44:14 <AlexD> annevk: if the cascading order was a problem, we could add more rules later
13:44:53 <AlexD> Domenic: If the cascading order is still good with host, then that's OK, should we punt until later?
13:45:22 <AlexD> annevk: The user agent could create an optimization path for this
13:46:19 <AlexD> dominicc: As a strawman, we need constructable style sheets no matter what
13:46:34 <AlexD> Once we have implementor experience, we can look at syntactic sugar, etc.
13:46:43 <AlexD> These style sheets won't touch the ODM tree
13:46:47 <AlexD> s/ODM/DOM/
13:47:11 <AlexD> Subject: FORMS
13:48:08 <AlexD> 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
13:48:38 <AlexD> You shouldn't have to keep track of some inputs changing state in the light DOM that ride along with your form submission
13:48:49 <AlexD> annevk: why do you need to keep track?
13:49:02 <AlexD> dcooney: they need to reflect the state
13:49:21 <AlexD> domenic: for validation? No one likes validation:-)
13:49:34 <AlexD> dcooney: a lot of browsers auto-fill forms.
13:49:42 <MichaelC> MichaelC has joined #webapps
13:49:43 <AlexD> esprehn: you can also do auto-restore
13:50:05 <AlexD> annevk: you want to expose type, e.g. ccard
13:50:33 <AlexD> esprehn: right now you have to put a bunch of attributes on your element to get the behjaviour you want
13:50:38 <AlexD> s/hj/h/
13:51:15 <AlexD> if you hit the back button, then forward, we'll restore the input content
13:51:24 <AlexD> s/input/form/
13:51:50 <rniwa> https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html
13:51:58 <AlexD> rniwa: we did make a proposal in Feb 2014 covering this
13:52:31 <AlexD> we're happy to support this, and adding more behaviours
13:53:20 <AlexD> dcooney: Looking at your proposal, looks like it's a bit different to how form association works today
13:53:26 <AlexD> It's just a detail
13:53:43 <AlexD> rniwa: this is a very preliminary proposal
13:53:59 <AlexD> you could do something like form data callback, so you can serialize it
13:54:54 <AlexD> bz: submission vs. state restoration. submission needs some key value/pair thing, so it's more complex
13:55:21 <AlexD> Domenic: my initial thought is use the form object to do this, append to it, merge, etc.
13:55:53 <AlexD> annaevk: form data only supports blobs/strings
13:56:14 <AlexD> [Travis asked about form structure]
13:57:11 <AlexD> rniwa: There are cases where the element could produce more data than entered, e.g cloning, dirty flags
13:57:32 <AlexD> maybe submission data is a subset of what you need to clone
13:58:19 <AlexD> annevk: we just need whatever API to return the name/value object or similar. Maybe we use form data and merge them
13:58:50 <AlexD> rniwa: using the form data makes sense, maybe the function should support either string or form data
13:59:21 <AlexD> Domenic: I'm worried about the ergonomics of authors getting the name correct
14:00:01 <AlexD> rniwa: that's why we say why not serialize everything as JSON
14:00:15 <dom> dom has joined #webapps
14:00:23 <AlexD> Domenic: I feel we're all excited about this and should take it to github and work on it
14:00:44 <AlexD> annevk: someone should do some refactoring in the HTML spec
14:01:01 <AlexD> We could have form data steps.
14:01:08 <AlexD> Domenic: I'll do it
14:01:29 <AlexD> ACTION: Domenic: create form steps for the HTML spec
14:02:16 <iank_> iank_ has joined #webapps
14:02:23 <AlexD> rniwa: It'd be good to have a callback to serialize a custom element
14:02:35 <AlexD> annevk: focus is the other one
14:02:49 <AlexD> CSS psuedo-classes for your form elements, stuff like that
14:02:56 <plh> plh has joined #webapps
14:03:16 <AlexD> weinig: capture behavior when you go into suspended state (non active browsing state0
14:03:21 <AlexD> s/0/)/
14:04:31 <AlexD> weining: you could get away with multiple onshow/onhide handlers. [Travis asked about suspended state]
14:04:40 <AlexD> s/weining/weinig/
14:06:56 <kochi> https://github.com/w3c/webcomponents/issues/187 is the bug for form submission
14:09:34 <sangchul> sangchul has joined #webapps
14:13:02 <AlexD> AlexD has joined #webapps
14:15:17 <AlexD> AlexD has joined #webapps
14:15:46 <LJWatson> LJWatson has joined #webapps
14:17:51 <LJWatson> rrsagent, make minutes
14:17:51 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html LJWatson
14:18:29 <jamesn> jamesn has joined #webapps
14:19:33 <AlexD> AlexD has joined #webapps
14:20:41 <esprehn> scribe:
14:20:48 <esprehn> scribe: esprehn
14:21:36 <esprehn> dcooney: In the old ancient times you wrote markup, and then later you wrote markup and script and style, and now...
14:21:40 <chaals-ordhord> chaals-ordhord has joined #webapps
14:21:45 <jcraig> jcraig has joined #webapps
14:21:47 <esprehn> dcooney: with shadow dom... webcomponents...
14:21:49 <esprehn> annevk: /trolls
14:22:13 <taekyu> taekyu has joined #webapps
14:22:18 <esprehn> 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
14:22:42 <Domenic> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/HTML-Imports-and-ES-Modules.md
14:22:45 <esprehn> 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
14:22:57 <esprehn> bz: how does this work? what do you mean?
14:23:22 <esprehn> dcooney: page wants to say "hey I want this component" or component wants to say "hey I want this other one"
14:23:42 <esprehn> dcooney: seems like a good time to discuss integration with es modules, we didn't have them before
14:23:53 <esprehn> bz: are we talking about a declarative api for components?
14:24:21 <esprehn> 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
14:24:34 <esprehn> dcooney: just define a custom element or attachShadow is not enough, you want the whole component
14:24:52 <esprehn> dcooney: there's a define call in there somewhere, but a component is a unit with a script, style markup together
14:25:17 <esprehn> Domenic: component declarative vs imperative: we want to integrate with es modules and those support both
14:25:39 <esprehn> Domenic: definitely should integrate with es modules
14:25:52 <esprehn> rniwa: I think the use case makes sense, been saying like forever dawg
14:26:28 <esprehn> rniwa: 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
14:26:43 <esprehn> rniwa: want to evaluate the ecosystem
14:27:01 <esprehn> annevk: is this just that we want to enable folks to use more markup? or also want to support renaming things while importing?
14:27:23 <esprehn> dcooney: that does sound appealing
14:27:28 <sangchul> sangchul has joined #webapps
14:27:33 <esprehn> dcooney: polymer uses all this stuff, including html imports
14:27:39 <esprehn> dcooney: they wish it was in other browsers
14:27:55 <esprehn> dcooney: we want something interoperable
14:28:02 <esprehn> ojan: *talks loudly*
14:28:15 <esprehn> ojan: is there something specific you want to see out of frameworks rniwa ?
14:28:20 <Todd> Todd has joined #webapps
14:28:32 <esprehn> rniwa: es modules defines specific module graph, we're not sure how authors will use that
14:28:49 <esprehn> rniwa: cascading load events slows down page load, maybe combining scripts to mitigate that
14:29:03 <esprehn> rniwa: people are experimenting with how to use them and we don't have enough to judge
14:29:17 <esprehn> ojan: as an example your fear is that people are finding ways to concat scripts together?
14:29:59 <esprehn> 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
14:30:29 <esprehn> dcooney: we have good experience at google doing this in various frameowrks (polymer and others) that want this, but yes theres some new terriroty
14:30:41 <esprehn> dcooney: is this the same use case to packaging
14:30:43 <esprehn> ?
14:30:51 <esprehn> dcooney: or is this something else? seems like maybe separate
14:31:52 <yosin> yosin has joined #webapps
14:32:06 <esprehn> 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
14:32:30 <esprehn> rniwa: sure, if you're going for familiarity, but we're discussing what should be the best api, talking about the next 50 years
14:32:44 <esprehn> rniwa: will everyone use es modules? we don't know, maybe people will hate them
14:32:49 <esprehn> Domenic: /is sad
14:33:32 <esprehn> ojan: my experience with html imports is that it completely changed my way of writing web apps
14:33:41 <esprehn> ojan: felt like a huge change
14:33:50 <esprehn> ojan: I'd like to see something, not comfortable just waiting
14:33:51 <MichaelC> MichaelC has joined #webapps
14:34:14 <esprehn> ojan: 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
14:34:38 <esprehn> 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
14:34:45 <esprehn> annevk: I think it's reasonable to start working
14:34:52 <esprehn> annevk: want to avoid shipping too soon before we agree
14:35:24 <esprehn> smaug: what's the status of es modules implementations?
14:35:43 <esprehn> smaug: do we have real feedback? firefox hasn't implemented them yet we're not sure about it
14:36:00 <esprehn> annevk: some disagreement about how they should be implemented, folks that disagree haven't created an issue yet
14:36:06 <esprehn> Domenic: this is just mozilla
14:36:20 <esprehn> rniwa: we are implementing them right now
14:36:24 <esprehn> smaug: not shipping though?
14:36:26 <esprehn> rniwa: right
14:36:32 <esprehn> rniwa: but all major browsers will support soon
14:37:17 <esprehn> 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
14:37:24 <esprehn> dcooney: I think this might be a good time to look at this
14:37:48 <esprehn> dcooney: given the feedback that we should integrate with modules, if we do that how do we know? maybe mime type?
14:37:57 <esprehn> bz: what does it mean to integrate with loading?
14:38:06 <esprehn> dcooney: we're not sure yet
14:38:18 <esprehn> dcooney: maybe if you have a component that depends on a module, maybe it can wait on the load first
14:38:30 <esprehn> dcooney: if you have a script lib that depends on a component, it can include the html modules and block on them
14:38:43 <esprehn> annevk: if loader happens, how does this integrate?
14:38:54 <esprehn> dcooney: yeah lets talk about this sooner rather than later
14:39:10 <esprehn> rniwa: also big difference runs the script as if it's in the main document
14:39:16 <esprehn> rniwa: in html imports today
14:39:29 <esprehn> Domenic: modules also use the same global
14:39:48 <esprehn> rniwa: right, but less chance of leaking by mistake to global
14:39:56 <esprehn> rniwa: also scripts are forced into strict mode
14:40:04 <esprehn> dcooney: +1
14:40:31 <esprehn> dcooney: maybe html modules only allow more html modules
14:41:36 <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.
14:41:48 <annevk> (We added a closing tag to <canvas>)
14:42:48 <esprehn> rniwa: concerns also about polyfill churn in the api, polyfill does one thing, but spec changes
14:43:17 <esprehn> rniwa: we have concerns because modules haven't shipped, we appreciate feedback from google and experience
14:43:22 <esprehn> rniwa: but we also want feedback from others too
14:44:14 <Florian> Florian has joined #webapps
14:44:23 <esprehn> dcooney: I agree more feedback is better, but I also agree with esprehn that we want to deprecate html imports and remove them
14:44:36 <esprehn> annevk: could republish that spec as a deprecated thing
14:45:06 <esprehn> dcooney: not sure where the future spec should be, we could just reuse the html imports spec to be the new html modules thing
14:45:25 <esprehn> challs: By reusing the spec we can inject uncertainty
14:45:37 <rniwa> Here is an old proposal by Dimitri: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/HTML-Imports-and-ES-Modules.md
14:45:40 <esprehn> annevk: in terms of messaging I think it's clearer to just mark the imports one as dead
14:45:54 <esprehn> annevk: new one can have "html modules" as the name
14:46:13 <esprehn> annevk: we ended up with v0, v1 naming in shadow dom, but more clear if we just use a new name
14:46:28 <esprehn> Travis: did we already enumerate specifically the things we don't like about imports?
14:47:14 <esprehn> dcooney: not sure there's a published list, ex. stylesheets apply to main document, not sure how it integrates with es modules
14:47:24 <esprehn> Domenic: my issue is that it has this weird document with a half way browsing context
14:47:31 <esprehn> dcooney: yeah there's this strange document thing that runs script
14:47:47 <tomalec> +q
14:48:29 <esprehn> rniwa: can people at google, ex. polymer come up with issues they had with imports?
14:48:47 <esprehn> Domenic: does magic things with custom elements
14:48:54 <esprehn> dcooney: that's well spec'ed but doesn't work well with new sync v1 elements
14:49:05 <esprehn> dcooney: I had a set of requirements on the web components proposals
14:49:47 <xiaoqian> ack tomalec
14:49:56 <esprehn> 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
14:50:14 <esprehn> tomalec: found that importing a document is very useful
14:50:32 <esprehn> 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
14:50:47 <esprehn> chaals: okay break
14:54:31 <AlexD> AlexD has joined #webapps
14:57:14 <AlexD> AlexD has joined #webapps
14:58:26 <AlexD> AlexD has joined #webapps
15:00:01 <AlexD> AlexD has joined #webapps
15:02:51 <JFSIII> JFSIII has joined #webapps
15:03:55 <AlexD> AlexD has joined #webapps
15:04:59 <AlexD> AlexD has joined #webapps
15:06:10 <chaals> chaals has joined #webapps
15:08:39 <bz> bz has joined #webapps
15:10:10 <ericc> ericc has joined #webapps
15:10:30 <chaals-ordhord> chaals-ordhord has joined #webapps
15:10:35 <Florian_> Florian_ has joined #webapps
15:12:42 <rniwa> scribe: rniwa
15:12:55 <LJWatson> LJWatson has joined #webapps
15:13:22 <rniwa> hayato: I hope this will be the year of shadow DOM.
15:13:56 <annevk> Shadow DOM, <iframe>, and history: https://github.com/w3c/webcomponents/issues/184
15:14:06 <rniwa> kochi: There is an issue with shadow DOM and navigation histroy
15:14:23 <rniwa> kochi: right now, the navigation history is merged across all shadow trees with the main document.
15:14:53 <rniwa> kochi: perhaps we can discuss it tomorrow in a breakup session.
15:15:04 <rniwa> Travis: can we discuss it now?
15:15:14 <rniwa> Travis: what is the summary of the iframe & navigation histroy?
15:15:36 <rniwa> kochi: the navigation that happens inside an iframe creates a joint session history with the rest of the page
15:15:54 <rniwa> kochi: it affects back and forward buttons as well as some APIs such as history.go(-1)
15:16:06 <rniwa> kochi: which is accessible outside the shadow tree
15:16:44 <rniwa> kochi: the question is whether we want to exclude page navigations in a shadow tree from the rest of the session history
15:17:01 <rniwa> chaals-ordhord: presumably, there are some cases in which you want to combine the session history
15:17:14 <rniwa> annevk: The basic principle of shadow DOM is that it doesn't leak but this leaks.
15:18:29 <rniwa> smaug: We could add properties to an iframe to create its own session history
15:18:55 <rniwa> smaug: so that we can avoid merging the session history with that of the rest of the page whenever needed
15:19:06 <rniwa> kochi: can we discuss that after this session with a small group of people instead?
15:19:14 <rniwa> chaals: what's the question?
15:19:23 <rniwa> chaals: is this hard to do?
15:19:31 <rniwa> smaug: the question is what is the right thing to do
15:19:58 <rniwa> smaug: the important question is how we can still make the browser UI functional in the case of a separate session history
15:20:35 <rniwa> annevk: In some cases, you want to isolate session history as well as browser UI; e.g. ads
15:20:57 <rniwa> annevk: maybe for v1, we can tackle shadow tree case where you want to have a separate session history for a shadow tree
15:21:13 <rniwa> annevk: without integrating with the session history of the rest of the page
15:21:56 <rniwa> annevk: 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
15:22:07 <Jun> Jun has joined #webapps
15:22:31 <rniwa> chaals-ordhord: the question is whether browser should let user go back using back & forward button.
15:22:56 <rniwa> chaals-ordhord: once browsers ship, developers may start depending on whatever behavior browsers have shipped
15:24:07 <rniwa> chaals-ordhord: 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?
15:24:23 <rniwa> annevk: yeah, that's the thing we need a recommendation for.
15:24:53 <rniwa> annevk: it's probably good to discuss it separately. we don't need the whole group for this.
15:25:22 <rniwa> chaals-ordhord: what are other topics?
15:25:28 <rniwa> hayato: one issue is adding back /deep/ combinator to static profile
15:25:41 <rniwa> hayato: last year, we had a consensus to remove the combinator from dynamic profile for styling purposes
15:25:57 <rniwa> hayato: However, /deep/ is not just for styling. It's also used for querySelector
15:26:27 <rniwa> hayato: A few websites raised a concern about the lack of /deep/ combinator for when adopting shadow DOM v1 API.
15:26:54 <rniwa> hayato: This is an issue because we'd like for developers to migrate to v1 API.
15:27:49 <rniwa> annevk: On github, hayato said we need to wait to get data as to whether we need this feature or not.
15:27:58 <rniwa> esprehn: we have authors telling us they can't switch to v1 because they don't have this feature
15:28:25 <pauljeong> pauljeong has joined #webapps
15:28:38 <rniwa> esprehn: there is a long list of features that can be implemented using /deep/
15:28:55 <rniwa> weinig: is this the encapsulation breaking feature? didn't we say we don't want this?
15:29:08 <rniwa> hayato: we only want this in open shadow tree
15:29:22 <rniwa> weinig: a person could implement a polyfil that does this
15:29:49 <rniwa> esprehn: this doesn't expose new capability because developers can use shadowRoot property but for the same reason querySelector exists, this will be useful
15:30:03 <rniwa> weinig: we removed from styling, but we want this?
15:30:24 <rniwa> esprehn: because we saw that some abuses of styles reaching into shadow tree to style things
15:30:34 <rniwa> weinig: but we don't expect people to do the same?
15:31:41 <rniwa> esprehn: we've seen that people use /deep/ very infrequently
15:32:04 <bkardell_> this is me
15:32:14 <esprehn> ^ in the querySelector sense, it's for particular global libraries, but not really inside per components
15:33:01 <rniwa> 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
15:33:30 <rniwa> hayato: the reason we wanted to remove /deep/ from dynamic profile was that it was causing a lot of performance issues
15:33:43 <rniwa> hayato: we don't expect the same issue to happen in static profile
15:33:51 <rniwa> weinig: could you clarify what the difference is?
15:34:01 <rniwa> esprehn: there are two types of selector matching
15:34:31 <rniwa> esprehn: there are two distinct ways of applying a single rule to multiple elements versus multiple rules to multiple elements
15:34:43 <rniwa> weinig: I guess you're saying that certain implementations have trade offs
15:35:08 <rniwa> weinig: I still don't get why if there was an issue with styles, there won't be an issue with scripts
15:35:27 <rniwa> esprehn: It's because /deep/ can reach into a shadow tree and modify style inside a shadow tree
15:35:50 <rniwa> weinig: our experience doesn't match with that.
15:36:16 <dcooney> scribe: dominicc
15:36:52 <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?
15:36:59 <dcooney> esprehn: performance
15:37:05 <dcooney> annevk: so they must have used it a lot
15:37:19 <dcooney> rniwa: If it is 5x slower that shouldn't matter because you're not using it much
15:37:47 <dcooney> esprehn: Inside a click handler if you're taking 1/2s versus some msec then that' an appreciable difference
15:37:54 <dcooney> weinig: so don't do that
15:38:18 <dcooney> esprehn: also translation framework these authors are using needs to query the whole document
15:38:30 <dcooney> weinig: maybe we need a selector for thing swith shadow roots
15:38:53 <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
15:39:13 <dcooney> rniwa: I'm not convinced we need this feature if we can write polyfills for it; it's only for perforamnce
15:39:27 <Jun___> Jun___ has joined #webapps
15:39:33 <dcooney> bkardell_: I think the concern is performance, the polyfill is really slow
15:39:56 <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.
15:40:10 <dcooney> supporting this feature natively improves the performance
15:40:34 <dcooney> weinig: does anyone have a succinct answer to annevk's question--do we have enough implementation experience or is this premature?
15:40:44 <dcooney> esprehn: We have it implemented; what more do we need?
15:41:04 <dcooney> hayato: We have v0 implementation experience but we didn't do it in v1 because it was controversial.
15:41:21 <dcooney> rniwa: there's one author commenting in the issue who is doing top-down query to send a message to components
15:41:28 <dcooney> this is the use case we don't want to support
15:41:57 <dcooney> hence we should not do this; this is what you find in the dynamic profile. There's nothing preventing people use this.
15:42:22 <dcooney> esprehn: That's an argument againts lots of things, css custom properties can cause large invalidations; you can write a slow for loop
15:42:35 <dcooney> you have to querySelector(*) and walk, it's slow
15:42:45 <dcooney> rniwa: that assumes deep is your first selector
15:43:06 <dcooney> Travis: if there was a selector to identify elements with open shadow roots attached; you could just recurse on those n=5 elements
15:43:22 <dcooney> did you change the behavior of the API so it's the same name, it now just goes through shadow roots?
15:43:46 <dcooney> esprehn: there were two versions, :shadow and :deep, one was one level down, one was N levels down
15:44:07 <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
15:44:37 <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
15:44:56 <dcooney> annevk: the other thing rniwa brought up, there's some disagreement about how often ShadowRoot will be used
15:45:16 <dcooney> it's a bit different to descendant selector; we don't know how often people will go across the boundary
15:45:49 <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
15:46:11 <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.
15:46:20 <ericc> ericc has joined #webapps
15:46:20 <dcooney> rniwa: I've never seen it, provide those to us
15:46:47 <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.
15:47:05 <dcooney> esprehn: deep was removed from the dynamic profile, but still in static
15:47:17 <dcooney> weinig: now, we have an issue in shadow DOM to reinstate deep fully
15:47:27 <dcooney> but there's some concerns in implementer feedback which we don't understand
15:47:31 <dcooney> in parallel the Chrome team
15:47:40 <dcooney> is getting feedback from adopters that they need this feature to upgrade
15:47:44 <dcooney> is that the timeline?
15:48:01 <dcooney> esprehn: Yes, sort of, in the meantime there was communcation to authors that deep would still be in the static profile.
15:48:12 <dcooney> annevk: there's no question about bringingi it back fully?
15:48:22 <dcooney> esprehn: (missing)
15:48:45 <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.
15:48:56 <dcooney> If we're going to add/not remove/etc.
15:48:59 <dcooney> ... we need that.
15:49:24 <dcooney> chaals: that's the story esprehn told us--people using translation attributes and wanting to find them without dom walks
15:49:32 <dcooney> annevk: that doesn't work for closed shadow roots
15:49:37 <dcooney> weinig: that's a broken use case
15:49:46 <dcooney> esprehn: they don't use closed shadow roots
15:49:51 <dcooney> annevk: but they may not control that
15:49:59 <dcooney> esprehn: the framework is part of chrome UI
15:50:17 <dcooney> they want to upgrade to implement this translation system but it's too much of a perf hit
15:50:39 <dcooney> Travis: Is the provider the same as the conusmer? So there's a lot of flexibility.
15:51:05 <dcooney> esprehn: yes; there's lots of people using this for the same purpose who want to upgrade to v1 but they're stuck.
15:51:17 <dcooney> rniwa: Why do they need deep? They could just do translation some other way.
15:51:25 <dcooney> esprehn: It's a separation of concerns. I don't understand.
15:52:03 <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.
15:52:36 <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.
15:52:57 <dcooney> rniwa: But the argument I heard in the past is open shadom DOM is closed for people working on Polymer
15:53:07 <dcooney> but walking shadow roots seems to break encapsulation completely
15:53:46 <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.
15:54:10 <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.
15:54:29 <dcooney> Separate to that, everyone in devtools wants to find elements in the page.
15:54:35 <dcooney> Travis: write it in devtools
15:54:39 <dcooney> weinig: devtools aren't the web
15:54:43 <dcooney> annevk: (missing)
15:54:51 <dcooney> esprehn: We're going to end up with some way to do this anyway
15:54:57 <annevk> I said that if devtools needs it, they need it for closed shadow trees too
15:54:59 <dcooney> chaals: I'm hearing Google say we really really need this
15:55:04 <dcooney> everyone else, not a good idea
15:55:11 <dcooney> are there any non-Google advocates?
15:55:17 <dcooney> how serious is the opposition?
15:55:28 <dcooney> bkardell_: the worry is it's a footgun
15:55:40 <dcooney> Travis: Where do you stop? Do you need getElementById?
15:55:54 <dcooney> chaals: You stop at some arbitrary point of concensus until that changes.
15:56:04 <dcooney> I'm not seeing any consensus outside google.
15:56:26 <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
15:56:42 <dcooney> with iframe history, the argument was we should just allow it because we already leak a bit anyway
15:56:49 <dcooney> bkardell_: so why not leak everything...
15:57:00 <dcooney> annevk: so the non-google parties are a bit more conservative
15:57:24 <dcooney> chaals: there's no consensus to do this, you need to add this to devtools and beat consensus out of people
15:57:31 <dcooney> esprehn: We got feedback and we're reporting it
15:57:38 <dcooney> chaals: That wasn't convincing
15:57:55 <dcooney> rniwa: It's hard to judge without specifics, reach out to those people and ask them to share feedback
15:58:24 <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
15:59:36 <dcooney> hayato: the second item is supporting ::part, custom pseudo elements
15:59:44 <dcooney> esprehn: I thought I changed the text of this, but...
15:59:54 <dcooney> we have from authors that they want the ability to style custom elements
15:59:59 <dcooney> annevk: this is issue 300?
16:00:01 <esprehn> https://docs.google.com/presentation/d/1ZE73bQ0VVRcMNwPmqAJ3V4t7brg3a2PsUOmxuqOOFxE/edit#slide=id.g16b44b8be8_0_58
16:00:01 <annevk> https://github.com/w3c/webcomponents/issues/300
16:00:13 <dcooney> https://github.com/w3c/webcomponents/issues/300
16:00:33 <dcooney> (people look for adapters for vga, etc.)
16:00:48 <dcooney> rniwa: Are we talking about issue 300?
16:00:51 <dcooney> (all): yes
16:01:07 <dcooney> esprehn: https://docs.google.com/presentation/d/1ZE73bQ0VVRcMNwPmqAJ3V4t7brg3a2PsUOmxuqOOFxE/edit#slide=id.g16b44b8be8_0_58
16:01:12 <dcooney> rniwa: is anyone against this?
16:01:16 <dcooney> we're very interested in this
16:01:24 <dcooney> esprehn: we wanted to discuss the problem space a bit
16:01:31 <dcooney> Domenic: I want to learn how it overlaps with apply
16:01:54 <dcooney> esprehn: (referring to slides) there are use cases
16:02:20 <dcooney> theme my page, theme a complex subwidget, theme a region of a page
16:02:36 <dcooney> library authors want to expose sub component styling points
16:02:55 <dcooney> big libraries want hooks, which is well supported by custom properties eg light theme, dark theme
16:03:15 <dcooney> widgets want to expose subwidget parts, custom properties have spooky global effects
16:03:23 <dcooney> part is better for the subwidget use case
16:03:49 <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
16:03:54 <dcooney> annevk: makes sense
16:04:12 <dcooney> esprehn: (example of selector which drills through component parts)
16:04:22 <dcooney> theming works well with custom properties
16:04:32 <dcooney> authors seemed happy with this
16:04:42 <dcooney> so we probably need both parts, custom properties and ::part
16:04:55 <dcooney> we should work together for syntax for republishing parts
16:05:06 <dcooney> Travis: custom properties don't do that?
16:05:14 <dcooney> esprehn: they're globally inherited
16:05:19 <dcooney> parts expose an entire thing
16:05:39 <dcooney> annevk: expose an element in a shadow tree; custom properties style everything including in shadow trees
16:05:54 <dcooney> esprehn: (describes how to do part with custom proprties but it is bad)
16:06:04 <dcooney> part lets you explicitly publish
16:06:13 <dcooney> Travis: custom properties are part of your API
16:06:17 <dcooney> styling API
16:06:35 <dcooney> rniwa: custom properties work in one direction outside in; part is exposing something from the inside out
16:06:46 <dcooney> esprehn: We need both of these, for the two different kinds of use cases
16:07:00 <dcooney> separately we looked at a mixin feature called @apply, see slides
16:07:03 <dcooney> it is hard to optimize
16:07:15 <dcooney> the use case is limited it helps you avoid typing a set of variable declarations at the site
16:07:29 <dcooney> but we should do part first because the use cases are different and we may not need it
16:07:31 <dcooney> Domenic: Why not?
16:07:42 <dcooney> esprehn: Because there's no way to target the right thing.
16:07:49 <dcooney> Say you have up steppers and down steppers.
16:08:03 <dcooney> Domenic: You do @apply up-stepper and down-stepper
16:08:15 <dcooney> esprehn: But if you use properties to theme them, then they apply to broadly
16:08:29 <dcooney> Domenic: You do the variables in the upstepper block.
16:08:36 <dcooney> esprehn: And redeclare them everywhereL
16:09:00 <dcooney> esprehn: ... example coming to IRC ...
16:09:20 <dcooney> esprehn: that does work, but it's a different API contract; as you compose deeper and deeper components the variable still apply
16:09:34 <dcooney> part lets you expose upstepper and downstepper but not other things
16:09:39 <dcooney> Domenic: (missing)
16:09:46 <dcooney> esprehn: But people end up using variables...
16:09:50 <wilsonpage> wilsonpage has joined #webapps
16:10:03 <dcooney> Domenic: Custom pseudoelements might look better but I want to understand if they're different
16:10:11 <dcooney> esprehn: I think it breaks down if you're nesting
16:10:32 <dcooney> Travis: rosyn was nervous about implementing this because it requires a bottom-up percolation in CSS cascade
16:10:54 <dcooney> I talked to him about part (in CSS WG) not @apply; did not talk to him about @apply. @apply is still top down.
16:11:05 <jcraig> s/rosyn/Rossen/
16:11:12 <dcooney> esprehn: We thought part seemed good, variables seemed good, authors seemed happy about that
16:11:14 <tantek> tantek has joined #webapps
16:11:17 <dcooney> s/rosyn/Rossen/
16:11:19 <mck> mck has joined #webapps
16:11:30 <Domenic> https://gist.github.com/domenic/fa84dddf918014b2fd9c853ba9b4aa86
16:11:52 <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.
16:12:07 <dcooney> weinig: our experience is that's useful, all of our controls--builtins--require that.
16:12:10 <dcooney> Travis: builtins
16:12:30 <dcooney> weinig: Yes, what does it mean to make the text placeholder element position: fixed ; it's not reasonable
16:12:38 <dcooney> Travis: (missing), weinig: missing
16:12:55 <LJWatson> rrsagent, make minutes
16:12:55 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html LJWatson
16:13:12 <Domenic> updated https://gist.github.com/domenic/fa84dddf918014b2fd9c853ba9b4aa86 to show how they seem equivalent to me
16:13:18 <shane> shane has joined #webapps
16:13:19 <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 *
16:13:29 <dcooney> weinig: and potentially it can go deeper, is it just properties or specific values?
16:13:58 <dcooney> Domenic: I wrote some sample code,
16:14:13 <dcooney> to show why they seem equivalent to me
16:14:34 <dcooney> you have up-stepper inside a shadow root and you'd apply it from the outside.
16:14:54 <Yos> Yos has joined #webapps
16:14:56 <dcooney> then you'd alternatively expose the part from script and write ::part
16:15:28 <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.
16:15:36 <dcooney> Domenic: isn't that like *::part?
16:15:47 <dcooney> esprehn: Encapsulation is different.
16:16:02 <rniwa> scribe: rniwa
16:16:12 <jamesn> jamesn has joined #webapps
16:16:22 <rniwa> hayato: the shadow DOM specification in the past had this feature
16:16:32 <rniwa> hayato: We removed this feature because we invented /deep/ combinator
16:16:39 <rniwa> hayato: but then we removed the /deep/ combinator
16:16:52 <rniwa> chaals-ordhord: Are there other issues?
16:17:06 <rniwa> chaals-ordhord: are people have a thought on whether we want @apply?
16:17:25 <rniwa> Domenic: I think the conclusion was to do it at least later
16:17:36 <rniwa> weinig: is the spec far enough?
16:17:52 <wilsonpage> wilsonpage has joined #webapps
16:18:05 <rniwa> esprehn: the CSS WG wrote a spec and we implemented @apply but we'd like to pull back and instead discuss :part.
16:18:40 <rniwa> rniwa: rniwa: Approaching :part makes sense to me.
16:19:12 <rniwa> Domenic: Let's talk about global custom attributes
16:19:29 <rniwa> Domenic: people had interests in Github, and this may avoid some of the concerns people had with is=
16:19:49 <rniwa> Domenic: you can apply multiple lifecycle callbacks on a single element per attribute
16:20:00 <rniwa> Domenic: so each attribute can get callback for connected, disconnected, and attributeChanged
16:20:09 <rniwa> annevk: would callbacks be per custom attribute?
16:20:22 <rniwa> weinig: is the idea that document.registerCustomAttributeObserver
16:20:35 <rniwa> weinig: and any time an attribute of that name is added to an element, the callback is called?
16:20:58 <rniwa> Domenic: People want to use this feature to listen to lifecycle callbacks on an arbitrary element
16:21:08 <rniwa> Domenic: people who use is= attribute can describe this use case better
16:21:49 <rniwa> annevk: Some kind of i18n attributes can be implemented across shadow boundary for example
16:21:55 <rniwa> annevk: This may take way reasons having to use open shadow trees
16:22:22 <rniwa> bkardell_: can mutation observers across shadow boundaries?
16:22:22 <rniwa> annevk: no, they're scoped to each tree
16:22:43 <rniwa> dcooney: This is a pretty light weight feature that benefit use cases
16:23:07 <rniwa> dcooney: If an element want to refer to another element via an attribute, they'd like to track all these attributes globally
16:23:22 <rniwa> dcooney: and having this attribute would help implementing such a feature
16:23:49 <rniwa> annevk: that's like how id attribute works
16:23:56 <rniwa> annevk: they need to update mapping whenever id attribute changes
16:24:08 <rniwa> dcooney: id might be a special case in blink because we do work laizly
16:24:23 <rniwa> annevk: we can do a similar dash (-) syntax and expose it
16:24:55 <rniwa> dcooney: if you're paranoid custom element author, then restricting attribute name to dashed names, they can avoid leaking internals
16:25:12 <rniwa> annevk: well but if you override the prototype of objects, they can still leak property
16:25:49 <rniwa> dcooney: custom elements would operate in closed shadow trees so it makes this global custom element to work across shadow boundaries
16:26:02 <rniwa> dcooney: It would be shame if people started adding callbacks to all the elments
16:26:22 <rniwa> dcooney: in the early days of web components, there was a proposal for decorators
16:26:37 <rniwa> dcooney: to be able to add and remove callbacks on elements and some vendors thought this was a bad idea
16:26:53 <rniwa> dcooney: is this a deal breaker? do we not want people to give this anti-pattern?
16:27:43 <rniwa> chaals: we can continue discussing this with four people who are interested in this idea
16:27:52 <rniwa> chaals: we can take a break now and talk about it later
16:28:10 <rniwa> annevk: I'd like to hear Apple's opinion on this
16:28:20 <JF> JF has joined #webapps
16:28:23 <dcooney> scribe: dominicc
16:28:38 <dcooney> rniwa: when we heard about use cases of is attribute we talked about htem a lot
16:28:45 <dcooney> all the use cases are mixin use cases
16:29:01 <dcooney> it was obvious to us in those cases you have to be able to add multiple mixins
16:29:10 <dcooney> like localization, or form submission participation
16:29:17 <dcooney> you have to be able to apply multiple
16:29:24 <dcooney> so we felt is was not good for that
16:29:29 <dcooney> so we prefer this approach
16:29:32 <JF> JF has left #webapps
16:29:44 <dcooney> however we haven't reviewed a detailed proposal so we're not sure
16:29:56 <dcooney> the use case sounds OK but there's only one vague proposal
16:30:08 <dcooney> this area sounds interesting and preferable to the is attribute
16:30:13 <rniwa> scribe: rniwa
16:30:25 <rniwa> Domenic: I'd like to hear from Microsoft
16:30:37 <rniwa> Travis: I think we're generally okay with is= proposal
16:30:52 <rniwa> Travis: I'd like to understand more about this new proposal.
16:31:22 <rniwa> Domenic: This would be a top-level custom element thing. You probably pass in a set of callbacks instead of a class
16:31:40 <rniwa> Domenic: and they get callbacks only when a given attribute is present on an element
16:31:49 <rniwa> esprehn: why not a class?
16:32:00 <rniwa> Domenic: because there will be no construction of the class.
16:32:22 <rniwa> bkardell_: Could you write some pseudo code to show us the idea?
16:32:28 <rniwa> Domenic: Okay, let me try to describe the processing model.
16:32:35 <rniwa> Domenic: It certainly has connected and disconnected callbacks
16:32:39 <annevk> s/bkardell_/smaug/
16:33:12 <rniwa> Travis: is connected callback for element or attribute
16:33:22 <rniwa> Domenic: for element
16:33:49 <rniwa> dcooney: this may end up storing data on maps element
16:34:01 <rniwa> dcooney: so using a closure function might be fine
16:34:53 <rniwa> Domenic: if we can figure out when & where to run constructor, then maybe class is okay
16:35:05 <rniwa> Domenic: however, this has an issue because "this" no longer refers to element
16:35:55 <wilsonpage> wilsonpage has joined #webapps
16:36:00 <rniwa> esprehn: Storing states on element would avoid leaks
16:37:03 <rniwa> annevk: if we use composition for state but for styles we have to manipulate, we're only solving half the problem
16:37:26 <rniwa> annevk: if we're going to composition route, you have to own the problem space.
16:37:52 <rniwa> annevk: If composition is the pattern we adopt here, then we should be using composition everywhere
16:38:51 <rniwa> annevk: composition means keeping all the states and styles related to a custom attribute in one object
16:39:02 <rniwa> annevk: and removing all of them altogether when the attribute is removed
16:39:41 <rniwa> Travis: Matching lifecycle of an attribute per element might be important
16:39:55 <rniwa> Travis: Unlike custom element, here, you get constructor when an attribute is added to an element
16:40:22 <rniwa> Domenic: when I said mixin earlier, I meant ES6 mixins
16:40:49 <rniwa> annevk: Once you register a new attribute, should we also automatically add an IDL attribute?
16:41:05 <rniwa> dcooney: in some use cases, it does require modifying prototype e.g. adding property
16:41:11 <rniwa> Domenic: we could let authors do it themselves
16:41:23 <rniwa> Domenic: we don't want to spec reflection in browser
16:41:54 <rniwa> Domenic: another problem people are asking is namespacing for attributes
16:42:06 <rniwa> Domenic: we may not need it but we need to pay attention to it
16:42:22 <rniwa> esprehn: it's unclear what authors need since we haven't implemented such a feature
16:42:43 <rniwa> annevk: data- is the only example here and it's a very special attribute
16:43:05 <rniwa> dcooney: It seems like there is a consensus that this isn't really an awful idea
16:43:22 <rniwa> dcooney: so we should go ahead and try to prototype it
16:43:30 <rniwa> esprehn: This also removes the use case for /deep/ and global mutation observer
16:43:56 <rniwa> esprehn: In some pages, it's important to wait for some special element to appear in the page for telemetry
16:44:31 <rniwa> esprehn: using a custom attribute would avoid having to pierce through shadow trees to find all special elements
16:44:54 <rniwa> annevk: this would probably help solve the previously stated chrome UI use case for /deep/ which needed i18n attribute
16:45:13 <rniwa> chaals: thanks everyone
16:46:22 <rniwa> RRSAgent, draft minute
16:46:22 <RRSAgent> I'm logging. I don't understand 'draft minute', rniwa.  Try /msg RRSAgent help
16:46:25 <rniwa> RRSAgent, draft minutes
16:46:25 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/19-webapps-minutes.html rniwa
16:53:22 <Zakim> Zakim has left #webapps
17:02:58 <MichaelC> MichaelC has joined #webapps
17:03:09 <ericc> ericc has joined #webapps
17:07:27 <jcraig> jcraig has joined #webapps
17:18:58 <Florian> Florian has joined #webapps
17:19:20 <wilsonpage> wilsonpage has joined #webapps
17:24:13 <wilsonpage> wilsonpage has joined #webapps
17:30:04 <wilsonpage> wilsonpage has joined #webapps
17:34:25 <jcraig> jcraig has joined #webapps
18:15:24 <jcraig> jcraig has joined #webapps
20:08:34 <Florian> Florian has joined #webapps
20:13:52 <wilsonpage> wilsonpage has joined #webapps
20:20:31 <MichaelC> MichaelC has joined #webapps
20:25:56 <cabanier> cabanier has joined #webapps
21:37:41 <Florian> Florian has joined #webapps
22:18:21 <tantek> tantek has joined #webapps
22:26:25 <IanPouncey> IanPouncey has joined #webapps
22:36:02 <smaug> smaug has joined #webapps
22:48:55 <rniwa> rniwa has joined #webapps
22:56:34 <IanPouncey1> IanPouncey1 has joined #webapps
23:24:55 <bz> bz has joined #webapps