<JakeA> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md
RN: We posted a proposal for this a week ago.
<Domenic> https://github.com/w3c/webcomponents/issues?q=is%3Aissue+is%3Aopen+label%3Atemplates also interesting
RN: when you call method you pass a template and for each syntax we create a template part - either attribute or where textnode appears.
... for each we assign values, for text node one we can insert elements and text nodes.
... these parts are not designed to get updated on DOM mutation. They hold on to the parent and siblings, and tries to collect itself when values are pushed.
... There was a concern this may be expensive, but do not think so.
... Have raised some questions already, are there questions people have not yet raised.
<Justin> lit-html contains an internal polyfill of these ideas in many ways: https://github.com/PolymerLabs/lit-html
OP: It is hard to think hard about this in just a week. It would be good to try a polyfill to play before we decide on a syntax - this might be good byut not yet ready to decide.
JF: Polymer like the proposal.
... We looked at this to replace some other library stuff. Since the proposal is new, should we look at why we think we need this?
... a critical problem is to create large DOM trees fast, and remember the interesting bits in it.
... so you can update them. This is pretty hard at the moment, and not very efficient
... There is a syntax level to think about, but also about underlying capability of cloning large trees and remembering nodes which is important to us.
... Laziness *might* be interesting to explore. We have reification of instance - no DOM created, just a holding point. You can make a tree of them.
... Wondering what the performance implications are in the proposal.
JA: Excited too. It is hard for developers to read the document as is, but we would like to make something more developer-facing to get feedback.
... comparting to other proposals, if you iterate and create 100 items, and then update to add one, does it go back and do the whole thing or just add the new one?
RN: There are 2 concerns. Create template parts and instantiate.
<Justin> handling lists and higher-level things can be done by processors, especially if they can directly manage the DOM controlled by a Part
RN: for now we make an object. That is well defined. Didn't define looping and conditional behaviour because we were not sure what other developers want it.
... Think it is good to support them by default, but tricky thing is how smart we want to make it, and what should we define about its smarts.
... Not sure about interest
... If you want a loop in the template we recommend using nested template.
... e.g. list item template. inside ul or li, you would have a template element and specify the for loop, the behaviour you use, and for each element you create a new template instance within the template.
... reason for that apporach is that when looping you want to form a template part for each instance.
... We can let authors create parts and attach them anywhere - what happens when you clone the node?
... we can probably define that, but seemed messy so we went with the approach of always create template instance.
... avoids the problem of multiple template part in the same spot. But if there is a use case for revisiting, we can.
<Justin> advanced repeat() directive in lit-html that manually creates Parts: https://github.com/PolymerLabs/lit-html/blob/master/src/lib/repeat.ts
DD: Discussed internally how high/low level this should be. We are excited about the low-level ability to track locations and stamp out templates.
... looking towards not having something for loops, authors do their own in v1
... I would like something that has the extra smarts out of the box eventually, but think we could agree and ship on a version with few features and reserving syntax we think we will want.
JF: re looping. Wanted to implement something that did smart looping, and this was an exercise.
<smaug> [smaug agrees with Domenic. Start with something simpler.]
<bkardell_> [agrees also start with the simple low level bits]
JF: Hear that it gets messy - if you clone a node with a part does that get cloned too? But making a solid minimal and extensible foundation, we can think about the mess later.
... and for some messy stuff, the answer might be "if you do weird stuff, things break" and that's OK.
... For extension points you need to get holod of a part then manually control it yourself
... Once there is a directive, the range of DOM you have is controlled by the directive. Used by repeat() to manually determine what happens when you do that, and to do efficient updates, you do the same
RN: Like the template processor
JF: Right but directive works out single expression.
RN: Can single directive drive multiple parts?
JF: No, it is a value for a single expression.
RN: OK
JF: Like a ref in React.
Surma: People want to start with a simple thing. Currently process callback for parts is synchronous. Do we want to make it support promises from the start? Think it might be a big use case, resolve a promise and replace the default value with the promise's result.
... So make email value a promise. So there is something there ("promising") that would be updated when the promise is resolved.
<Justin> lit-html supports Promises, by default: https://github.com/PolymerLabs/lit-html#promises A template processor (or directive) could support Promises on top of the minimal API
Surma: Realise this goes against start simple, but think it is a really major use case.
<JakeA> I think enabling this usecase is interesting, but I don't think we should bake it in yet
RN: That seems plausible... but...
<Justin> making sure that template processors can do all the things they need is the primary concern, io
<Justin> making sure that template processors can do all the things they need is the primary concern, imo
RN: We wanted to make this indifferent to how things should work - needs to work with ember, angular, polymer, etc etc.
<Domenic> Yes, this ask seems similar to asking JS's default template string processor to support promises
RN: Think libraries mandate evberything is available, so not sure that making it wait for promises by default is a good idea.
Surma: Is it easy enough to build that behaviour on top of the current proposal?
<Justin> agreed w/ Ryosuke, very easy
RN: Yes, very easy. All you need to do is looping over the template process, if the property value a promise? If so, wait ...
SUrma: Sounds good.
DD: Next steps for this discussion? Should we go through issues?
TW: are we going to consider inert content vs wanting scripts to run?
... there will be frameworks who don't want scripts to run and others that do. Any opinions?
RN: There is an issue about not allowing it, think the problem will go away.
JA: Letting devs change properties not attributes, and how to deal with event handlers, can be tricky. Do you enable that?
RN: We would like to solve it with ability to overwrite the attribute name. e.g. onclick content attribute, or yank out the template and addEventListerner. You can also add attribute and mutation observer.
... think this *should* work. We don't have a polyfill which makes it hard for developers to evaluate - so I have the action item to make it.
DD: Think template processors is the hardest issue, can we start with that
<yoav> https://github.com/w3c/webcomponents/issues
RN: In current proposal we had a strawman. We think it is a good idea to add it in shadow root. Don't want to just allow it anywhere because that gets leaky. If you have a registry that can be reference by multiple realm that is possible but looks tricky.
... Allowing at document and shadow root level is probably enough.
JF: What if createinstance only allows an imperative way to add it?
RN: Good enough for v1
TO'C: As long as you can specify a default processor, seems fine.
JF: In markup?
TO'C: You might want to call a different one each time, buit if specifying it once in markup helps, let people do that.
JF: So that starts to imply a kind of global registry
RN: The implication might just be that tehre is *one* default processor for everybody.
... this might be nice, but do not think it would be required.
JF: Would be nice to tackle custom element name scope so they have something similar
RN: Yep: Would need to figure whether we allow a single function, or permit options. Think the latter, you might want to get stuff when you see a callbackl not just when you instantiate it...
DD: Seems reasonable...
JF: If this is a performance primitive, what is the potential win?
... rather than experimenting with the spec, can we do some experimenting on how fast we can make this things happen?
... Where are implementors seeing the wins, what experiments will show us about them?
RN: We don't see it as a performance feature, but there could be some features that improve perf.
... in first implementation I doubt we will implement the first version with super perf. Updating DOM without doing traversal would be nice because that is a known drag...
DG: Agree with Ryosuke. Main win is that you do not have to load the code.
RN: SO for v1 we do not have a registry?
DD: Yep
... we can prototype global registries on top pretty easily. Think it is nice to declare your processor, but we should be careful given the experience with global custom element registry
RN: Can we remove the replacehtml?
DD: yes
RN: OK, remove it.
... Should each instance inside a text node have its own syntax? We think we should not normalise, because otherwise it gets confusing for developers when you are inserting stuff... so prefer to keep each template piece apart.
BK, DD: agree.
... there is a step I am not getting yet, but we should talk about that offline. Everyone likes separattion.
DD: Tables (not noted in list).
JF: Foster child algo and expressions - we have not filed the issue yet.
<JakeA> can someone describe the issue?
RN: Syntax might become controversial. We want to use expression inside CSS, and {} does not make life fun there, we want to fit into template literals, ...
... any suggestions about which syntax we should use?
<dfreedm> `<table>{{part}}</table>` becomes `{{part}}<table></table>` due to the foster parenting parsing for table elements
DD: tyhe argument for double brackets seems compelling. The other candidate is the XML processing instruction that doesn't work inside attributes.
<JakeA> I see
RN: We could go with [ ] so people do not have to type 2 characters.
<JakeA> thanks dfreedm!
DD: How do we figure out how to paint the bikeshed. The people here will say "yeah sure"
TO'C: Don't think we really care, so long as we don't get it broken.
RN: Next, how powerful default processor should be.
... should we support dot syntax, ...
... seems like Google are saying let's not support that for now.
JF: Instinct is to keep it really simple for now. (But see the value here)
... wnder if declarative custom elements could define its own default processor and if that would help
RN: We see the instantiation thing can be useful outside custom elements, so you can use it for doing nice things.
... No problem not to have them so long as we reserve the space so we can add them in the dfuture
JF: Was worried about JS gropwing features to make things safer. If we invent one in default processor and another in JS that would be sad.
DD: Instinct is keep it minimal, then allow all JS. Think XSS concern means people do not want to do that, and then look at handlebars / mustache, ....
... seems like they allow dots maybe, so maybe it is what we want. They don't have or, fallback, arrayindex...
... this needs research but my first instinct is keep it simple.
RN: Why not limit to JS identifiers.
DD: Throw seems safer than just not working. You won't ship code that throws, but might ship if there is an empty field in the DOM
RN: OK, makes sense. notSupported error?
BK: Would make sense to look at what is common in other template processors.
... None of them I know of throw unless you do something really bad.
<Justin> filed an issue for tables: https://github.com/w3c/webcomponents/issues/703
<smaug> rniwa: FWIW, I'm having hard to even comment since this is after all just an initial proposal.
TW: Lot of simple ways is to dump if there is a syntax error. Has the effect of a throw that people try not to ship because it looks bad.
DD: Agree on identifier name, error-handling needs to be researched.
<smaug> rniwa: I think so. And need to think of other possibilities too
DD: Do we do whitespace stripping? Think Ryosuke is in favour, I don't care.
<smaug> rniwa: I mean some different kinds of approaches which might help with performance more
RN: space stripping is behaviour of template parts, We could keep them but as far as I know nobody ever did that.
JF: Whitespace inside the expression is what we mean, not textnode space.
... and no problem stripping it.
Tomek: You can have space in property name. It's esoteric...
RN: true...
JF: We are only stripping trailing and leading.
... it is not a valid JS identifier, so you quote and then no stripping happens.
... On error handling, what happens?
RN: Depends. when we throw an exception we currently parse first, so we throw then and do nothing. Probably sensible...
[nodding]
<smaug> yoichio: how does the selection proposal work if one serializes the selection range which includes some shadow DOM too (especially closed shadow dom)?
<smaug> yoichio: remember that Range interface has stringifier
<yoichio> Is it about crossing selection?
<smaug> yoichio: right
<yoichio> As I write in the appendix section, Chrome exposes each Range of document and shadowRoot and user copy concat string.
<smaug> yoichio: so the Range object rooted in light DOM wouldn't stringify the selection?
<smaug> only the light DOM part of it?
<smaug> just trying to understand the proposal
<yoichio> I'm also boiling detail, but first of all, I want to get resolution that making selection adapting shadow keeping light side compatibility.
<JanMiksovsky> Scribe: JanMiksovsky
[now joined by ARIA group]
Joanie: ARIA working group met yesterday to discuss AOM (Accessible Object Model)
... conclusion is starting with role and attribute parity
... AOM should support the needs of web components, and more cleanly than can be done with ARIA
... AOM has the advantage of better handling object/ID references
Marcos: Mozilla quite supportive of AOM
Ryosuke: where is proposal to have AOM work with shadow root?
<yoav> https://github.com/WICG/aom
<surma> https://github.com/wicg/aom
Alice Boxhall: are there specific issues not addressed by explainer?
Ryosuke: you would have the component own the accessible node? We have problem with that approach.
... Current AOM spec says ARIA role would be overridden by AOM, we think that's good
... But we think accessible node should be exposed on shadow root
Domenic: Don't focus on specific API
... Sounds like you want three levels of precedence.
... Only see need for 2 levels of precedence.
Ryosuke: 1) default value for each element, 2) ARIA then overrides those, and then 3) AOM would provide additional override
... We don't want web components to be different from built-in elements
Alice: Not quite following. You're saying we should be able to set the default values for ARIA, and that is different from setting default semantics?
Domenic: My thinking is we don't need accessible nodes in AOM
Ryosuke: If you're saying we're not going to have accessible node override ARIA values, we'll have significant problems with that
... If you look a <button>, and if you want to override role, you do that with ARIA attribute
... And AOM allows dev to override that imperatively
... Then web components need to be able to define something equivalent to default role
Alice: Sounds like we differ in need for a mechanism to override ARIA at all.
Chaals: Can you (Ryosuke) elaborate on use cases?
Ryosuke: Need James for that discussion
<Travis> Scribe: chaals
janM: We have some components that want to set aria on themselves and their light dom children...
... a list, that turns its children into options or says which is selected...
... found that need was common
... we do that on slot change
... how does AOM address that?
alice: In that scenarion you would use a custom option element for the list options, which would set its own role
... for selected state, there is no barrier to setting things on the accessibleNode for another element.
... you can access from outside the shadow root.
JanM: We are making a carousel. The devs want to put an img element inside, and have them be ooptions in there.
... does the component need to be forced to use a custom component inside?
DD: In the native latform today elements do not change role when you put them in a container.
... each one needs specific children - a tr or li, in order to behave right.
... so we do not have this pattern currently
robdodson: You have slotchange. If you need to change something you can listen for the change there and use that as the trigger to update.
JanM: OK, that was my question
... is AOM meant to replace that - set AOM properties instead of attribute values?
AB: Cannot se why you want to change something's behaviour.
... so better to have a proper child (like tr in native html) that does the right thing
... then you can tell it to set itself right
CMN: Agree that it is odd to put things in and tell them to be different, but people do it :(
JanM: Think we will have challenges if we have to have a corresponding child component that behaves right.
... this is juist what we saw. But that constrains how people are going to understand things
Tomek: Think what you can do is create li in your shadowfor each child and distribute it, and have a slot.
JM: If elements are assigned to the slot, they will be picked up, but if they are img elements, that isn't going to be nice
AB: You *can* use AOM to do that...
<rniwa> +q
CMN: We should expain better the HTML pattern and point out you need children that are the right thing
JanM: That makes the developer ergonomics a lot more cumbersome
DomM: Don't see why the component isn't defined to allow users to put anythings in and use AOM to set roles and props.
... advantage of AOM as we see it is that you set a default role for your children when added, and allow embedder to override that.
... people can use ARIA and add it. There is value to set defaults, and can be overridden
JanM: I am exited about this, not opposed. But have not seen enough example of "here is how to take advantage"
<tink> rsagent, make minutes
DD: Do not understand the ask...
RN: Think the idea we don't want to have two different things is #88
<JanMiksovsky> Ryosuke: Issue #88 is the one we're trying to merge ARIA and AOM?
<JanMiksovsky> Alice: I'll look it up
Alice: There are benefits to AOM we could achieve in a slightly different API. We have relationships across shadow boundaries that are critical but cannot be done in ARIA.
... there are ergonomics around setting ARIA without needing get/set attribute
... we can get those two by making ARIA reflect something you can set in DOM
... having another node might help, issues with shadow. To set nonreflected semantics anywhere
RN: OK. THat solves all the world's problems
... We really need to be able to define a role without modifying the host element.
... users of the custom elements should be able to define the defaults. Think we are converging and can take it offline.
<JanMiksovsky> scribe: JanMiksovsky
Ryosuke: Apple is very supportive of this AOM proposal
Tomek: if we're going to use AOM to solve the reference problem
Dominic M: where would that spec live?
Domenic: Happy to talk more about this offline, I think this would be a new, more complex form of reflection. We'd define that in HTML, and then ARIA would just say: use that mechanism
<tomalec> above was about same reflection for `<label>` element
Chaals: sounds like we're done (with AOM discussion)
<tantek> s/Chas/Chaals
<rniwa> +q
Domenic: Before we move, just want to emphasize that we'd really like to see parity (with ARIA)
<scribe> Scribe: JanMiksovsky
Justin: We're interested in shadow parts.
Chaals: That's on the agenda (item 7)
Ryosuke: Can we talk about two more issues with template before we move on?
... Let's talk about tables
<Justin> issue #703 https://github.com/w3c/webcomponents/issues/703
Ryosuke: If you have mustache syntax inside of the table, do you do the foster parent algorithm?
... This is one of the biggest pain points that framework authors have to face
... There are a few options here we discussed prior to this meeting.
... Option 1: Change the parser. Potentially backwards-incompatible.
... Option 2: During parsing phase, remember that foster parenting did happen. Inside of createInstance, we would just move it back to where it belonged.
... That's weird. Template content would continue to follow parsing order.
... Yet another option 3: Use a Processing Instruction.
Justin_Google: I like the parser changes. Brings templates closer to what devs expect.
... Concerned about polyfill on older browsers. Would need something backward-compatible for those browsers.
Domenic: We should design for the future. Polyfill can define their own syntax.
Alex_Russell: The <template> was the last larger parser change. I don't believe that it's feasible to do that again.
Domenic: But this is so much smaller.
Alex: The size of the change doesn't change the speed of the roll-out.
Ryosuke: This parser change is a lot smaller.
<tantek> nor does the size of change affect the probability of compat impact.
Ryosuke: XHTML parser supports this. So you can use that parser.
... Only applies to text nodes inside of tables inside of templates. Change is lot smaller.
... Hopefully no one's relying on how that (specific case) works today.
Thomas: I can see there being small changes.
Domenic: Most people won't have to worry about having polyfills differ in syntax.
Ryosuke: This is really about how templates are parsed
... We can try to make this parser change separately.
... If no browser vendor strongly objects, we'd like to make this parser change.
... If this change doesn't stick, we can come back and revisit one of the other options.
Domenic: We'd need to talk to our parser implementaors
Dimitri: Actually, I think we can do it.
Ryosuke: Great.
<smaug> aha, nm
Ryosuke: Can we also talk about boolean attributes (in template proposal)
... If it'd be really nice if you could loop over everything, without worrying about whether it's a node or attribute.
<smaug> (the whole proposal is so new it is really hard to say much about it.)
Ryosuke: With boolean attributes, our setAttribute/removeAttribute behavior was magic.
... In our current proposal, people are asking why this isn't a method.
... There are lots of boolean attributes. We would like the default template processor to handle this.
... Without this, devs would be very unhappy. Do people have opinions about how boolean attributes should work?
Rob_Dodson: Are you factoring in ARIA attributes that take an actual "true" or "false" string?
Ryosuke: I meant the JavaString value of true or false.
Domenic: The ARIA attributes aren't really booleans. You should just think about them as strings.
... To me, the exact API shape for controlling boolean attributes in custom processors, we can continue to work on.
... Controversial thing is how to have the default processor solve this.
... Best option I've heard is (what Ryosuke said).
Ryosuke: We considered having special syntax for boolean attributes.
... but then we're inventing an opinionated framework in the browser.
... This seems less desirable.
Domenic: We could have a new type of template part that is the attribute name.
Justin: One place where default processor could put opinion is expression syntax.
... So you could have something like "boolean:" and the processor could handle that.
Ryosuke: Let's file a new issue to track this.
Justin: We rely heavily on CSS custom variables and @apply, so we're excited about shadow parts spec.
... We wanted to clarify the importance of this (as a CSS spec) for web components.
Dimitri: As the inventor of parts, I certainly support it.
Ryosuke: I think the only major feedback we have about parts, we'd like mechanism to define part and theme to be separate.
... We like part.
<JakeA> Can we get a link to the proposal being discussed?
Ryosuke: We understand the use case for theme, but we would prefer for these two things to not be conflated.
Justin: We brought that up with Tab the other day.
<tomalec> https://tabatkins.github.io/specs/css-shadow-parts/
Justin: We considered ideas for what theme could target, both at the part declaration site, or at the theme selector site.
... There are a couple options here to satisfy that.
... Would that satisfy (Apple's concerns)?
Ryosuke: We want components to be define which are the parts that they want to expose, and which are themes.
... The thing we're not okay with is someone defining a part, and not want it be themed.
Justin: Why shouldn't my host be able to control that?
... Ryosuke: That's fine. What we don't want
... Suppose component A includes component B and exposes B as a part.
... Our users want to be able to style all paper-button instances in the entire tree.
Ryosuke: Component B exposes a part. If it's okay if B exposes that as part of a theme.
Chaals: You want to encapsulate.
Justin: One idea was namespacing on the part name.
... A slider might expose it thumb as a thumb part.
... They could have a namespace like slide:thumb.
... Then it becomes themeable.
Ryosuke: I don't think we want to do that.
... It's not bad if every theme is a part. We just don't want to part to be themed.
Takeyoshi: There is an issue in WC issue tracker ... Apple is concerned about exposing a part to the outside world.
<JakeA> tomalec: thanks
Ryosuke: We don't think querySelector should every return a node inside a shadow tree
... If we add ::part or ::theme, we still shouldn't return a node inside a shadow tree.
... If you already have access to the shadowRoot, that's fine.
Takeyoshi: As implementors, having querySelector not return nodes is fine. Helps performance.
Justin: In testing with WebDriver, people want to cause events or do other things to parts inside of shadow roots.
Ryosuke: We could expose a WebDriver-only API.
Justin: Not all test frameworks operate over WebDriver.
... They could patch shadow. The tricky part is exposing a reasonable API to the test author (to find parts).
... Would like static profile for querySelector to support this.
Ryosuke: We have lots of test APIs in WebKit.
... Turns out a lot of apps end up using those test APIs.
... That's not good, not thread safe.
... If we expose it in static profile, someone's going to use it in production somewhere.
... Maybe we should standardize polyfill or something (for test frameworks).
Chaals: Let's talk about forms.
Domenic: At last TPAC, I picked up an action item to tackle forms. Haven't done it yet.
... We need a new champion for this.
Ryosuke: There's a 4 year-old proposal.
... Biggest problem is that no one's actively working on it.
<Domenic> https://github.com/w3c/webcomponents/issues/187
marcosc: I could be interested, maybe.
... Could potentially fit nicely with Payments API.
... I would need some mentoring.
Domenic: I would be happy to mentor.
Chaals: Lunch, back at 2:00
<chaals> our meme...
<bkardell_> scribenick: bkardell_
<scribe> scribe: bkardell_
<kochi> FYI: http://tabatkins.github.io/specs/construct-stylesheets/
<kochi> is the spec draft
kevin: the given gist is the ability to marshall and share styles amongst custom elements
<Yam_ACCESS> +present Toshihiko_Yamakami
one use case for being able to imperatively create a stylesheet out of text
rather than have the style element and the template be parsed every time, you could do it imperatively and allow them to share the same instance
there are probably a lot of options on API
Domenic: from what I understand of the problem
... constructing stylesheet objets from text is not that controversial, the q is how to use them
tabatkins made a proposal that allows you to ...?... without having to create a shadow root
another is that you create a new property, at a special level in the cascade that allows you to reuse them
theres been a question in the past about whether this is worth solving since you can already put a style element in the shadow root
I think it is, it's more obvious to developers that they can optimize it
ryosyke: we think the general concept is great, I have specific naming complaints
... I dont understand why 'treescope', it should be shadow root or something, and I dont think 'moreStylesheets' is good
... I had one more suggestion, it probably makes sense to add a option for stylsheets in shadow root creation
Domenic: There are multiple ways to solve the use cases here... you could do it when creaing a shadowroot, you could use it in the custom elements api
... normal css files wont penetrate the shadow root, howeer if you have the option of constructing effectively 'user agent level' stylesheets, that's pretty good
Kevin_Schaaf: one of the reasons adding it to custom element definition is attractive is that there are a lot of leaf element cases where the entire reason to create a shadow root is to add a style element
this winds up adding 3 extra nodes just to make a style for your definition
ryosuke: last time this came up, we had one issue with this: the cascading order was strange
... instead, make this new thing that ...?....
Domenic: the problem I am concerned this doesn't solve is creating elements that are the same as ....?...
... the issue is that it affects specificity (sorry, cascading level)
the worry is that something like a * element shouldn't .... [some discussion]... maybe I don't have an issue after all
Kevin_Schaaf: to the implementers in the room: is it weird or possible that custom elements apply this stylesheet having the same semantics?
ryosuke: what happens if someone tries to attach a shadowroot if you already have a custom style?
one option is it throws
another is to create a new one /redefine - but that is very weird
Domenic: I'm much interested in this proposal if it is just another way to do this
?: As a creator of components, I'm interested in things that offer a new degree of expressiveness. my own reaction is rather tepid
<dfreedm> Jan is Jan
I'm not saying we should or shouldn't, just as a consumer it isn't very exciting
ryosuke: There's a third option: [...?]
justin: I like that... to speak to Jan's point: there are a host of things about things like SSR, if you want to take advantage of upgrade, for example, pre-upgrade you want to offer some styles and then it upgrades to more
at least this gives you a lightweight way to give basic styles and then upgrade and load more
Jan: it has a feeling of something that might end up happening without a lot of passion for it, I'm not feeling it yet
I hate to see something get added to the platform unless we're really excited for it... this, just not that exciting
tomalec: As kevin mentioned a lot of work needs to be done to make just something like UA styles
so I really like this third proposal so I can think of it like a way to create UA-like styles and not be limited
ryosuke: as an implementer this will dramatically increase the memory footprint and the optimizations we can do later.
Jan: What makes it hard?
Kevin: This is a classic ergonomics vs perf
the leaves tend to be simplest, stuff like buttons, they might just not require a shadow root
it you just hand it a ref it's pretty cheap... esp if we are trying to make the case to use the features of the platform this is hard.
<chaals> BK: When yu make a shadow root you get accessibility stuff...
<chaals> AB: You mean relationships?
<chaals> BK: Yes. If I just wanted a basic thing, without a shadow root, when I create a shadow root things have to get redone. So is this more usefu?
Jan: that would be interesting, this group has a long history of how to specialize the native elements... it would be interesting to see if we could use this to work on how to create 'native' elements that are just styled.
<rniwa> +q
tess: this seems like an empiracle question - lots of leaf nodes, makes sense
worst case scenario is that we're wrong and we don't get the 4x optimizations
dglazkov: a synthetic shadow root?
justin: I just wanted to drive home the perf aspect. we are a go between to a lot of things (youtube, etc) - 'there's just too many elements'
getting a lot of extra nodes out of the way/reduces node count really helps us
Jan: So is it just a native element that just wants to have styling?
Justin: it's a little different than just subclassing... container elements that can do special styling
robdodson: to this point - I think the issue is that the native elments internals are just not exposed... like, a select, you just cant get at the internals and restyle them - there are just limitations that you can't style
ryosuke: yes, that is true..
I think there's not a performance problem with the extra nodes as much as being able to share the same stylesheet instances
you dont want a new list of stylesheets for each of 400 instances
if we had explicit ability to reuse, we could optimize that a lot more
this provides two things: as an author you could use something much simpler
the other is that there is a clear path for browsers to apply optimization
chaals: do you see a risk or just unexcited
Jan: Just if everyone has limited dollars to spend on features, I was just wondering if we are adding load that spends those dollars and just no one seemed that excited
<dfreedm> scribenick: dfreedm
<kochi> yoichio: proposing https://github.com/yoichio/public-documents/blob/master/selectionapiforshadow.md
yoichio: I proposed the selection api for Shadow DOM
... in this document I briefly described the API for the web author to modify the selection API in the document
... in the case of creating an editor with shadowdom and custom element
... in this case, we might also want to modify selection in shadow root
... but currently in the spec, this is prohibited
... in case 2, user selection selection crossing shadow dom
... my proposal would permit user selection to cross shadow boundary
... there is complex and difficult reasons to explain why selection apis depend on one node tree
... but shadowdom creates a separate node tree, which makes selection API not work with Shadow DOM
<Zakim> chaals, you wanted to say yes, as a user I would be grateful if I can select stuff that appeared via a shadow DOM
<rniwa> +q
yoichio: I propose upgrading selection API with Shadow DOM. This might create a bunch of discussion for relevant spec work
chaals: as a user, I would really like this to work, but implementors might have scream
rniwa: We agree with the goal to allow selection to cross Shadow DOM, but oppose this change for a few reasons
<rniwa> https://w3c.github.io/selection-api/
rniwa: There's an ability to add, remove, and modify ranges
... The problem is most of these methods make no sense to change just because the user selection crosses shadow root
... It might make more sense to figure out which parts of these APIs are changed by ShadowRoot and expose just those specific APIS
... Frameworks may not be able to keep representations of elements with Shadowroots stable
... The most natural way to expose this is to expose the selection API that is on Text nodes and allow framework authors to rebuild selections
yoichio: Your opposition is specifically about ShadowRoot?
rniwa: No, there are many other use cases, like svg, that could use this too
... Specifically svg <use> element, which pulls an svg element into itself and displays that element in the space of the <use> element
... Also have similar situation with psuedo elements. you should be able to select partially inside of a psuedo element
... We should have a consistent API that handles all of these cases
... Not saying we have a specific polish proposal, but we should extend the selection interface to handle these cases
... Specifcally Selection API has an anchor node, and a focus node
... we could also have another anchoring and offset pair to select the offset to specify the selection location inside
... Authors could be provided a selection API that has no access to the underlying shadow tree or svg use element, but could provide access via an identifier to keep position and restore it back
... to save and restore states
yoichio: The story with selection is the reponsibility of web hosts.
chaals: This should maybe be a conversation between yoichio and ryosuke, and maybe we can move on
yoichio: I want to listen to the opinions of Microsoft and Mozilla if you can
Travis: Microsoft is thinking about the various use cases for selection across shadow boundary
... You have something looking like a native control, which you can't select through, and you have this case like the example which is just text
... As that develops further, which is worth persuing, perhaps you want to prevent the selection end according to your scenario
rniwa: There is a need to control selection. In the case of an editor, there is a need to scope the selection.
... There are two use cases: text input and text area, and another of plain text which wants to share with the rest of the document
kevin: We already have a similar situation with events where in ShadowRoot the event path is scoped and exposed in the deep case with a new API
... Do you see a need for a similar split in selection?
rniwa: Not sure what you are proposing
kevin: The difference between event.target and event.composedPath()
rniwa: The composed path doesn't contain nodes from closed ShadowRoots
kevin: Not sure what the use case is for closed shadow roots is, but
rniwa: Our position is to use closed shadowroots for everything. We may disagree on that
chaals: This is not the path to nirvana between closed and open shadow roots
rniwa: One thing I would say is that we would like to solve the selection problem
... We have a specific problem with what is proposed, we don't think this is a good interface
... Because there are other cases than ShadowRoot, where author can't access nodes, it would be very useful for them to address the offsets of the selection and have one solution that address all of these cases
... Web developers want to just handle the one or two values for this and not the specific way for each different use case to support undo-redo and other editor operations
yoichio: So you propose another Selection API.
rniwa: Yes it is a bug that the selection apis between text and specific elements are different
... there should be only one APi for these cases
yoichio: That makes sense
chaals: We should park this topic for now
... Is there anything else to discuss today?
yoichio: Yes we can close
chaals: Any particular preference for the next topic?
... Or we can take a break
[break called]
<chaals> we are back...
<scribe> scribenick: dfreedm
justin: Polymer supports this because our current offering uses HTML Imports
<kochi> Polymer's strawman: https://github.com/w3c/webcomponents/issues/645#issuecomment-343601237
justin: Now that ES6 Modules are here, I think everybody agrees we should all use the same loader, module registry
... We have a rough set of dependencies
... You have to be able to load them, be able to get things out of an HTML module
... From there, we would like to be able to specify exports in the HTML markup, maybe an attribute
Domenic: Why?
Justin: You may want to have multiple templates chosen dynamically
... People really like to write "single file components". Vue, Polymer, "unity" components from Webpack seem to provide this
... In some sense how we get those features matters less than getting them at all
... github issue 645 has Polymer's strawman
<Justin> link: https://github.com/w3c/webcomponents/issues/645#issuecomment-343601237
tomalec: I like what Justin proposed, as a developer who needs those features
... I used to use HTML Imports for client side includes. Having a template from there and executing javascript is really important
justin: has any body seen Travis. Maybe using HTML Modules as a mechanism for includes
Travis: I need more context
Justin: < provides tomalec's use cases >
Travis: we have a though about imports where we tossed around the idea of abandoning the concept of importing a selection and stamping instances
... Currently HTML Imports can load and run script, and make custom elements to be used later in the main scope
... What if instead you could use this as a contained element and use the URL as the identity.
... But we don't like our idea anymore after some hallway discussions
... One of the use cases we have is that if you want to load components from the same domain and you have a lot of components that you can somewhat trust, then it is reasonable to import a bunch of defintions and instance them where they are used
... The other scenario is the Facebook like button where you don't trust it and it doesn't trust you, you may not want to use very many of them, and maybe you don't want to smoosh all of those together
<rniwa> +q
Travis: I want to look at a proposal, perhaps rniwa's proposal about declarative custom elements, and Justin you had another proposal? We should look at those two.
robdodson: Raising a small point, in the strawman you propose, template needs an "export" attribute, script can use "export" or "id", that seems confusing
Justin: yeah, I tried to say that wasn't fully formed
... The strawman is just meant to outline the use cases for exporting, and how you would import elements from the HTML Module
... Using URL fragments was just a possible way to show how a module could import elements from inside the same module
... apologies, I just posted that an hour ago
dglazkov: Let's agree on what we think the important properties are, and then break to a smaller group to discuss how to accomplish those goals
... Can you list the priorites
<JanMiksovsky> From the doc: P0: Some way of importing HTML, possibly inert P0: Some way of when you import, getting access to <template>s, including re-exported <template>s from other HTML modules. P1: Some was of exporting/importing arbitrary DOM. P1: Execute <script>s in some reasonable way. P1: Allow a <script> to control the HTML module's exports.
Justin: The 5 high level priorities: some way to import HTML, some way to get elements out of that HTML, some way to export certain DOM nodes.
Travis: Just can you clarify what you mean by export
Justin: if we think about a JS module, you can specify a symbol to export so others can import it
... You should be able to make a HTML module that can be expressed as a JS module with exports
Travis: would those be references like in JS Modules?
Justin: Yes
rniwa: Now that ES modules are ready, we think this is a great time to address this concern
... In general we agree on this proposal, but I have mixed feelings about the syntax in your example
... Its a bit unclear, maybe we need a high level discussion, about maybe two use cases
... Security model for a bunch of elements I wrote and untrusted modules is very different
... Ideally these should have the same authoring
<Justin> Travis referred to an example I wrote for untrusted components: https://gist.github.com/justinfagnani/fea819776d77eee5a108a3bcf873e7f4
rniwa: Particulary in the facebook like button, it is a non starter for that javascript to be exposed in the same Realm as your code
... There needs to be a wrapper, like a WindowProxy, to wrap around this untrusted component
... There is one approach: export or import the custom element definiition or template itself
... Or export the declaration of a custom element in an abstract way
... Say, instead of exporting my custom element which defines the element, import the "idea" of that element
... If you think of a x-origin case, importing the element is not adequate
domenic: I haven't considered the cross origin case before. I propose protecting them with CORS, and execute the code as if it is in your origin
... Just like in JS modules, cross origin modules still execute in your realm. I don't think we want to make something different here
rniwa: this is slightly different. the use case we are talking about is isolation level 4
... You have a widget you want to include like iframe, like a social button
... but you have a high standard of security so you don't want to execute this code on your site, and the button might also have a strict policy
... The only way to do that now is cross origin iframe
... but in this case, it is really slow because each instance needs its own Realm
... but you really want to have only two realms: your page and the button's
chaals: Should we keep this discussion to the high level goals, or start talking specifics
Justin: If we get the base layers of our goals correct, we could solve the untrusted component case with the HTML modules
<Justin> https://gist.github.com/justinfagnani/fea819776d77eee5a108a3bcf873e7f4
Justin: dan and I made a gist last night of how you could combine these use cases
... using declarative custom elements
... We could step back to high level goals and then talk about declarative custom elements?
kevin: justin has sketched out a way to handle trusted html modules and we perhaps could defer the untrusted use case if that's ok?
Travis: I like that from the standpoint of making progress, but I'm concerned that not keeping the untrusted case in mind would lead to not being able to use the same methods
dglazkov: The way I think of this is just modules with HTML sugaring
... If want to come up with an untrusted way to load modules, we could do that in parallel
... The high level goal is to use ES module plumbing, and the untrusted use case is just figuring out how to load untrusted modules
Travis: second that, another high level goal is to have something declarative so the parser can locate these resources ahead of time
domenic: ES modules are already declarative and you could locate them at parse time in theory
Travis: I thought dglazkov said something about leveraging es modules but with a different syntax?
Domenic: I think we should redo the syntax, and if you serve with an HTML mimetype you get an HTML modujle. JS mimetype? Js Module. Etc
justin: Another high level goal is about if scripts are inert or not. Some way of executing script is on our high prority list because our users really want to write script inside of an HTML module and have that define custom elements
Domenic: That's huge, we can't say yes or no
rniwa: I reiterate the statement we made: its fine to focus on same origin, but we're cautious that not keeping the cross origin case in mind would make it hard to solve cross origin in the future
justin: even before we get to the last point, this the first time I've heard about tying the untrusted module case
Domenic: Seconding dimitri loudly, we should solve the untrusted es module case in general, not just in this HTML module proposal
rniwa: Sure yeah. This would involve running scripts in an untrusted fashion with ES module semantics, but we can't delay discussing the untrusted case
... For us, it is a very very important use case
Travis: Domenic can you recap where we are?
Justin: This seems worthy of talking about more, but I'd like to finish the list
... If you accept that you should be able to write equivalent HTML and JS modules in each other, you should have a way to import and export from an inline JS module
... An inline module should be able to export a symbol out of the HTML module
Domenic: I think what I'd like to get a sense of from the room is if we think single file components is worth it. It is very complex
Travis: what do you mean about single file component
Domenic: You have a file with a template, script, and styling all in one
... As opposed to a sipmle file where the HTML module would only have teplate
Travis: Single file html modules sound like the right approach to me
rniwa: Yeah, I think we are all in agreement that we should be able to use HTML to define components
... I agree with you
Domenic: then I would love to dig into that issue as I find it uncomfortable
... HTML IMports did weird things and that's where I'm coming from
... There's no other instance in the platform with a separate document that allows scripts to run, and I'm sure the spec missed places that could allow this
... It feels weird to allow this thing to have a doctype and title tag
... There's a lot of issues like script execution and creation of separate documents
... Having document fragments seems nicer so we can keep synthetic documennts as weird case
... But I like that there is enthusiasm to solve these issues
rniwa: With original HTML Imports, we had issues with the specific proposal but not the idea that it should exist
... There was a lot of weirdness like stylesheets applying to the main document
... We should see what everyone sees as issues and work through that
Domenic: one more issue, custom element lifecycle in these documents
rniwa: All this weirdness comes from it being a seprate document. We should remake the semantics to make that work
Travis: Design considerations: one thing we would like is that when you import an HTML module, maybe you don't need to have script execution for it to work
... Maybe you could have a use case where it displays as a component without needing script
... Maybe not a compelling use case?
<Domenic> Document vs. DocumentFragment from 2013: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22305
Justin: I agree because you could have a use case where you have different authoring opinions. You should be able to import that module without needing script in it
Dglazkov: which items have we added to your needs list?
... single file component, same mechanisms as ES modules
... what else?
Domenic: we haven't talked about exports yet
dglazkov: I love exports
kevin: I guess that the answer to domenic's question is that we see HTML Modules as a high level solution for declaring custom elements, or a low level primitive for importing HTML. WE've seen it as a low level primitive that could achieve the high level one
... If the only thing an unstrusted component could do is export some dom maybe that shapes the discussion
rniwa: It would be really useful to have a list of concrete use cases from the people already using HTML Imports. We need a list of very complete specific scenarios to evaluate if a proposal can meet those needs
<Justin> Added additional goals from discussion to https://github.com/w3c/webcomponents/issues/645#issuecomment-343601237
kochi: What I'm interested in is if you have an HTML module, is it only a leaf node of the module tree, or it can be a node between root and leaf
... If we allow executing script from HTML Module, can it import something else from dependant modules, which could also be HTML Modules? Or only export?
Travis: That's a good question. If we limit that to leaf nodes, there will be use cases that won't be possible. I feel like that is not correct
... There should be nothing stopping you from loading your dependencies and so on
Domenic: I agree we need to handle it and it is too restrictive to disallow importing. I want implementers to be aware of the pain they are signing up for by allowing html parsing inside of module parsing
tomalec: I've expressed my opinion on github. I'm using HTML Imports for client side includes, and it needs script execution
rniwa: So for HTML Modules importing other scripts, I don't think we need to parse HTML inside of the module parsing, as we can set the semantics to do what we want
Domenic: why not?
... ES modules assemble graph statically so you need to get dependencies before running code
rniwa: those are the es module semantics, but we don't _have_ to do that for HTML modules
Domenic: I welcome your alternate semantic proposal
Travis: I'd like to propose a breakout session for this
Domenic: you mean like yesterda?
Travis: no, like now
s/yeserda/Wednesdayy/
dglazkov: I propose a WG-like meeting to discuss this off-season of TPAC with whiteboards and donuts
chaals: You don't think a 15 minute breakout would solve it?
rniwa: Chaals, what are the topics left?
Domenic: I think we should talk about declarative syntax in light of these proposals
tomalec: I wonder if declarative syntax is for custom elements, shadowdom, or both?
rniwa: break first before that? it is a long topic
chaals: we can talk about this after a break. Do you want a long break, or a shorter one?
[break for 15 minutes]
<fantasai> ScribeNick: fantasai
<rniwa> present+
rniwa: Just posted link to the proposal in IRC
<rniwa> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md
rniwa: Basic proposal is very similar to proposal in 2011/2012
... You have an element, I'm calling definition element, which defines an element and specifies a constructor
... inside definition element you have a template for the shadow root
... and script element which defines the class for the custom element
... If we wanted to, we can ge trid of req that you have to specify constructor name by looking at the evaluation result of each script element within the definition element
... and use the result
... this is a bit weird
... because ifyou have a comma at the end, result is undef
... that turns into new expression, so won't work
... in current ecmascript spec, class declaraiton doesn't result in ?
... even though safari and chrome don't ...
... safari still ships with class evaluating to a value
Justin: to get a value out of a script, we have a mechanism foor that in modules, so can we use that, and sya export defautl or epor the name and you can get from outside
... ties into feature we'd like for script tags, to have promis that hagngs off it
... This would tie in, from a script tag can get to the module object it defines
rniwa: wouldn't preclude req that you specify which one is a constructor
Domenic: you can do the default export, that's what it's there for
... Don't need to say "what distinguished name to use", we already have one
rniwa: sounds reasonable to me
RESOLUTION: use default export to identify the class that will be the constructor for the custom element
rniwa: once we have that approach, this coudl associate the template and constructor
... in case where author didn't specify write any script
... there is some value in supporting in supporting very simple custom element that doesn't invoke any script
... in those cases would like to automaticlaly create the shadow element with the template beings specifie
... update value whenever value attribute changed
... with original template proposal we had, there was a wa to get, we supported a property getAccess
... In our template proposal we had function called createInstance and update function, take state object
... state object let's you look up values
... if we did pass the shadow root of the custom element as the state object to update and create instance, we wouldn't be able to get the attribute value by doing the looking of the host and then lookup of attributes on the element
... and then becaue it has name getters, wuld be able to look up the foo content attiute
... could do host.attriute.foo and get attribute value
... get value attribute without writing any script
... if we did do this work where we automatically invoke update when attr changes, and call on template instance
... upate attriute value to the template instance
Justin: sounds reasonable to me, I think most component authors will think of their context as the custom element instance not the shadow root
... so maybe the data passed to createInstance is the instance itself
... so you elide the host part from thee expression
rniwa: .. want to access things inside the shadow root if you pass in the host.. but maybe that's not useful anyway
... so maybe that's okay
Domenic: THat inspired me, if you make the value passed in the element itself and you do attribute property reflction as you should be doing, then you don't need that syntax
... your example could be rewrittento be percentage value
... oh, doesn't work beacause can't do attr prop reflection in you completey declarative non-JS thing
Justin: why can't define reflection?
Domenic: No declarative way to set up reflected attributes.
... could add that, would be ambitious
hober: I think you're both trying to solve prolem that host.attribute.foo.value is verbose, and maybe just make that shorter
... nice to get it for free, just add some sugar
Justin: I think the length of the expression is separablae from the .. of attributes
... good practice to reflect attributes
Justin: good for non-scripted elements to have that behvior, maybe make it default
rniwa: myabe define list of attriutes that the element has
... reflect IDL attiute not content attr
Domenic: property you mean, not IDL attribute
... After JS decorators make their way through TC39, there are some nice decorators you can use to do auto reflection
... Say that because in that proposal I define what I thought would be a useful subset of HTML's reflection rules to expose to authors
... isntead of JS decorators, could maybe do as custom declarative thingies
rniwa: Reason I didn't go that route was because decorator isn't quite wel defined late
<Domenic> https://gist.github.com/domenic/e3e1e034e119826f394480cd9f15e211 especially https://gist.github.com/domenic/e3e1e034e119826f394480cd9f15e211#with-decorators
rniwa: Didn't want to conflate undef bhavior with rest of proposal, but maybe not an issue
... Add decorator, that works, that'd be great
JanMiksovsky: So in general I'm nervous about thinkgs where we bake in things that feel like a frmaework, was wondering if in rniwa's earlier proposal for templates, you defined idea of template type that maps to a processor
... wanted multiple framework using the same shared syntax
... use template in different way or different processing
... maybe apply same kind of flexibility to custom elements
... opt into declartive attribute creation, here's the specific processor I'm using that understands this
... Avoid default processor being too opinionated
Domenic: I like that line of thinking , but also think that attr property reflection is very basic part of HTML and it's super complicated right now
<chaals> [+1 make reflection easier]
Domenic: Haven't heard anything to make it simpler, aside from this and the tc39 decorator propsoal
... I like idea of customizable processors, but we should make attr reflection easier and not say that's wrong
Justin: Seems very natural for a declarative custom elements proposal to include declarative attributes,
rniwa: In template instantiation api was to make possible for libraries and frameworks to build on top of it
... in this case, tho, start providing usgar over ... define custom elements without writing scripts
... if you have library and want own custom library and want to ... then probably better foryou to have your own elmeent
... Do'nt see much value in having definition element that then has a diferent semantics model
slightlyoff: Wanted to echo Domenic's coment about making attr property reflection easier to be more unified
... dont' what to have something magical for specific case of decl custom elements easier
... I think dom has done a bad job to make this esay
...
... There already is a defined if magical lifecycle that built-in elements used, should extract and reuse that ifecycle
... as a mixin or other behavior that devs could reuse
rniwa: What we want to do is to define decorator or something eles that lets you define custom attrs
... this definition is jsut syntax sugar to trigger htose behaviors automatically
... .. veriso nof impertiave semantics
... so don't need ot have specific behavior
hober: was talking earlier about leaf case where mostly custom style, this gets you there without bunch of repeated boilerplate
rniwa: if no furhter comments, then third seciton of propsoal...
... if you have class defining custom element,s in today's world you have to attach shadow root and then find template associated with custom elements and hte create that instance
... we think there's vaue in sort of adding helper function to do that stuff
... that's like 3 lines of JS
... so if using framework or library not really an issue
... but since entrie entire exercise of declarative sntax is improving dev ergonaomics
... then this helps
JanMiksovsky: I noticed there's no mode param
Justin: there is, shadowMode on the template
rniwa: Sorry, that is missing shadowMode attire on template element
JanMiksovsky: It's provided as attr on the template?
discussion of open vs closed
Domenic: There has to be a defualt for every HTML attribute, and this group cannot decide on one for this
... What if I put mode=asdf?
... what if I don't attach template as shadow, but use declarative custom element
rniwa: It will throw
Domenic: How will it throw during initial HTML parsing?
rniwa: Ah, so no script.
... It would fail to register.
bkardell_: That'sunfortunate
Domenic: I'm not convinced we should add 3-lien helpers to window.customElements without seeing in frameworks first
... This one that searches for nearby ? elements and attaches them to the script tags...
... Do we really need a top-level name for this?
Justin: Whehter polymer has a 3line function that gets this is separatble, it might even
... we currently use ... effectively
... conceptutally we do have this
Domenic: but you build it as part of a larger framework
Justin: It's also a pack of useful tools
Domenic: I'm not concerned about frameworks having as users using it
Justin: also have import.meta.scriptTag issue
Domenic: we should have that
rniwa: Fundamentally though we see value in associateing a template element to custom element def that uses it
... The idea that oh, look at import meta script element, find tempalte around it, it's a very clumsy way to find a tmeplate elmeent
... Itw ould be nice if ? had semantics to find the element during custom definition call
Justin: API question that Ihave
... say you have purely declartive custom element. Does that induce a new custom constructor for every tag?
rniwa: Yes
Justin: Can they have a common base class that has an API on it, instead of having this.getTemplate?
rniwa: Could do that?
<Domenic> Perhaps instead of `export default class X extends HTMLElement { ... }` you do `export default function (template, ...otherStuff) { return class X extends HTMLElement { ... } }`
Justin: There might bhe other API you might want to hang off this class
rniwa: didn't consider that
<Domenic> Or `import.meta.templateElement`
rniwa: maybe want to expose other helper functions
... but right now no way to have protected function, so didn't see much value in superclass, but maybe
Domenic: dropped some proposals into IRC
... My concern is you're taking this associate which is somewhat specific to the decl custom element syntax, and you're creating a method on our generic custo elements namespace to manipulate that
... I would prefer something more specific to this environment
... import.meta is for metadata for this module, could put it htere
... or say shape of module processes templates, so expoert...
... I have surface concerns, not functionality concerns
rniwa: I think we could explore those options, sounds reasonable
kschaaf: I wnt to point out that decl syntax there looks very similar in spirit to polymer
... part of reason polymer is a 10k library not 1k is getting perf just right
... so concern about e.g. attributeChangedCallback
... run ? 10x will have bad startup perf
... if run once at start, and then get net level call again,
... lots of perf to consider
rniwa: We have not really looked into that, right, this is a straw man proposal
... def open to making changes to make more performant
... wanted to create simple
... We didn't do perf optiomizations, or the example would be 10 times as long code
... Frameworks tend to do dom update differently
... there's react model, top down render function call after all updates are done
... angular style update dom, after observing changes model
... Building elements closer to latter model
... It makes sense that attr change should be reflected
... maybe it's opt-in behavior
... or if we did definereflect semantics for attribute, then maybe we take...
... In those cases, even for building them, e.g. input value attriute, it's only for instantiation
... so there are many considerations we cna make here
Justin: one thing a lot of frameowrks do for batching chanes for asyn crendering
... whole host of things that make that difficult in platform-friendly way
... because can't coordinate work across DOM tree very well
... async updating of elements, how do elements know when other elements are done?
... ton of future work
... Try to make that more interoperable
JanMiksovsky: Curious whether consider staging this wrk
... e.g. some aspects of proposalthis morening including looping and other stuff, core features
... Might be a lot of compexity in deifnign elements without scripts, and might be quicker to come to agree on elements that hvae scripts
... nd get syntax of that nailed down first, then address more interesting feature script
later
rniwa: as long as we define a way that works late
rniwa: anyone opposed to the proposal? object to proposal?
<Domenic> I want to write everything in JavaScript, but I don't want to object to this proposal...
kschaaf: Don't want to take away from, don't want to be negative on propsoal, but I'm wondering how many of the custom elements that you can write today, without needing an event listener thing
... the more use cases you solve without, think about what you need in script
... you can do most of a slider in script, but translate change in % to firing a change event, need a script
hober: lots of leaf elements needed for styling, and there's tons of them
chaals: a large class of trivial problems
... I think this is something you should keep doing, and see if it actually comes out
<leaverou> and even if you need script, reducing the amount of boilerplate script you have to write is always good
dfreedm: From example of just having how many element syou can make on the script, style xample. How does it tie to constructible style sheet idea that Dmitri proposed earlier?
... ties into decl custom elements?
<robdodson> is it possible to add some time to the agenda to discuss the global custom element namespace?
chaals: Would like to put this topic down now, y'all are baked.
Justin: So whenlooking at top user requests, cross-scope styling HTML modules, doing something about global custom name registry is high up on there
... at least one of the large criticisms of web components on the twitter lists
... request to use shadowroot as name scope
... beign able to associate a rgistry iwth a shadow root
... have some ideas for solving this problem that seems to be important to some people, can we ask if ppl want to help?
chaals says something sarcastic
s/sarcastic about chairing about chairing/
chaals: OK, will put up suggestion of actual meeting for some time early next year and we'll sort that out offline