SV_MEETING_TITLE -- 06 Mar 2018

<rniwa> +present Ryosuke Niwa, Apple

<annevk> Agenda link again: https://public.etherpad-mozilla.org/p/web_components_agenda

template instantiation

<kochi> Remote join URL: https://hangouts.google.com/hangouts/_/google.com/google-com-vvaf

<kochi> (if it doesn't work, ping kochi@google.com)

<chaals> [presentation]

<kochi> community event after at 7pm: https://web-study.connpass.com/event/80198/

<chaals> CJ: we should file issues, but we were running late. So we will do it after the meeting.

<chaals> ... prepare was a very important stage.

<chaals> scribe: chaals

DD: You want template part for each element, rather than having to make everything at once.

CJ: Wanted to be able to remove bits before cloning, although I didn't have a concrete use case...

RN: The reason the directive is mandatory is so that if those things are there they won't be removed
... Would like to avid having another DOM type - new interface - for this.

DV: Is this to allow expressions at runtime?

CJ: This unlocks getting expressions when you create

RN: Don't want to make this easy...
... don't think we need a new API to help with it. Do your own housekeeping.

JF: Lit has to do 2 treewalks, one at prepare time, one to make the parts.

RN: You don't have to do that.

CJ: I hear "if the author cares about this, do their own bookkeeping"

JF: Given a template I can say what bits I care about, which is the new piece

RN: If you do your own parsing you already do that.
... you could just clone the tree.

JF: Lit does, and then has to find the nodes.
... to createPart you have to get to the right spot in the clone to createPart

RN: If you do prepare you have a list of parts.

DV: We have a declarative template engine. The root of all evil is allowing arbitrary expressions to be evaluated at runtime. That's a Yuge footgun.

JF: This is only allowing the template engine to look, not JS...

DD: as long as we allow JS to work, people have footguns...

RN/DD: if you do eval, you do eval. :S

DV: I know we cannot prevent it, but we should be clear that it is a bad idea...

JF: common to have JSex outside JSex ...

DD: Not sure ordering is the win, it is just creating everything at once without going back to JS

JF: deferring all te CE callbacks to the end of creation of the tree instead of as you go seems to be a win.

RN: Nested template needs to create its own instance...
... When you create a foreach it has to know to clone itself each time...

DD: [templateinstance slide] The win is there is only one createContent

JF: You have templateinstances as values, rather than making actual DOM

RN: This is not good for performance - you clone twice?

DD/JF: No, there is no DOM there until you create at the end.

RN: I dislike this approach. Don't like making a new stage between instance creation and DOM creation, and the benefit seems minimal.

JF: Compared various VDOMs. They can be faster than what I am doing...

RN: Don't like decoupling update and instance creation
... prefer createInstance to be the thing that creates content.

JF: You get multiple phases if you construct the DOM first.

RN: Agree we can have DOM creation at the end...

JF: What values represent nested templates?

RN: You create the subtree's DOM first. Bottom-up

JF: In lit it is slower

DV: You want to know which nodes to touch, before you start. That's why you want to go top-down.

RN: Behaviour is fine, don't want three different function calls. If you combine createContent into createInstance, that would be fine.

JF: Can we have a simple mode that does that, and a power mode that splits them?

RN: Why?

JF: So you can make creating the DOM a single step.

P-M: you expose the constructor in this model?

JF: Maybe we can agree on some goals for e.g. timing of creation

RN: Think we have agreement on that already, but yes.

JF: Having more steps, this is simpler, because I understand each step that happens.
... Think we agree on the "why Lazy" slide goals...

RN: If we can share the content between create and instantiate that would be good.

JF: We would say don't mess with stuff in the middle of those.
... considered making it a class

[TW nods]

JF: give it an evaluate expression, to help create a tree without making DOM.
... would be called in createInstance and in update

RN: How do you get rid of {{if..}}stuff{{endif}}?

JF: In the prepare step

DV: That's why you have the multistep process, to clean those things up easily.

RN: OK, that makes sense

CJ: We have a couple of API variants on the repo

OP: Do you have any performance measurements on this?

CJ: Haven't done the measurement, but ends up like litHTML

DV: Performance asside, the ergonomics is a huge benefit

TW: Yes...

OP: This is a thing to maintain for ever, so we need to be careful what we add.

<robwormald> avoding treewalks is the WHOLE REASON angular doesn't use <templates> :)

DD: Seems like we are decomposing into things that will be useful to a wide range of frameworks. *Seems* like it avoids a lot of treewalks, but not sure we can figure that out without testing it live. If there is no performane benefit, maybe we should find a way to step back.

JF: having a template that doesn't help make content is odd.
... Claim you can convert everything into tempate proposal, but need to prove it.

JM: The thing thhat owns a template doesn't always know about all the parts.

CJ: We want to be able to construct template parts in the process.

JM: How do the rules reflect the template part to be created?

CJ: Left that open... we may have had the same approach

RN: Seems there is a consensus that we need to make templatePart constructable, and we need a prepare step.

JF: There is often a prepare step, but the compiler goes over that and takes it out.

RN: We need to figure out the model

CJ: Seems we agree on a lot, agree the goals, so we can look at API shapes that match them

DD: Would like to have attributes too

OP: That part is unclear to me

RN: The key is you don't have to update dynamically when something is updated.

AvK: This is what Yehuda was looking for in the platform.

JF: people want to move bits of documentfragment around, seems template-like. Maybe we can fix range a bit.

DD: Problem with range (and doesn't do attributes): document has to track all the ranges you create.

RN: template doesn't need more than a pointer to where it is, and update itself when it needs to if it can.

DD: There is a staticRange too.

RN: This is a point, not a range

JF: Well, once it gets content it is like a range...

RN: Having the same parent is different

OP: Don't need to calculate start/end

RN: Problem with range is for any DOM change we have to check them all to see if they need to be updated.

TOC: What are we agreed on? TemplatePart...
... we will capture the goals and check agreement.

JM: Heard general interest in prepare step

TOC: Think we have more agreement than it seemed ...

:part and theme...

JF: Think there is a fair bit agreement on part

Fergal: Splittng naming and forwarding is a biggish change.
... part= and partmap=

<fergal1> https://github.com/w3ctag/design-reviews/issues/230

F1: forwarding is in the spec

RN: Don't think we should create a microsyntax to do it. You could have attributes

<tomalec_> https://github.com/w3ctag/design-reviews/issues/230#issuecomment-369848367

TW: That's what part map is for, no?

f1: You have to name the parts. Like adding classes to an element.

on host you want to forward parts higher up the tree. Suggesting separating those 2 ppieces.

RN: Yes, we should do that.

TW: what about starting with imperative API first?

JF: That will make polyfilling it way harder.

TW: You can create a shadowroot without a template.

JFL We assume you create stuff from a template. Ahead of time we will preprocess the styles.

<cdata> Link to Template Instantiation slides from earlier: https://docs.google.com/presentation/d/1f9lMbJA_TSUwXXWPvH7QcIEMy1yUVcSD_KNpGjHztyk/edit?usp=sharing

f1: you will have to cross that bridge at some point.

DD: What extra does imperative give?

f1: I just assume that at some point you will expose an API for the feature

DD: setAttribute...

F1: well yeah, but yuk.

TOC: It is a general problem for microsyntaces

DD: If we switched to an imperative API would it be as easy to implement?

F1: think so

TOC: We agree to separate part and partmap and want to go to Tab and get something nicer.

DD: Authors are waiting for this to happen...

RN: Do you need forwarding? Will part work OK alone?

JF: You need forwarding a lot
... If you had theme, would forwarding be less used?
... we think forwarding is the normal way forward
... theme is for stuff that goes across the entire tree.

f1: Seems theme is still unsettled, but are we the people we need to talk about it?

JF: Think we are not far away, just need to check if we agree. A part becomes available to theme selectors - if you want to be themable you should have to opt in for that. THink this was OK by Tab, as an attribute. And maybe that's agreement.

<rniwa> https://drafts.csswg.org/css-shadow-parts/

[tracking what CSS is doing can be hard...]

TOC: So file two issues. Part microsyntax is underspecified. Separate part and partmap.

RN: We want theme to apply in closed shadows too.

AvK: Yeah.

[general agreement]

DD: Define HTML attributes better...

AvK: HTML, or super-globals?

JF: Should be super-globals
... We were noodling about x-origin isolated components, iframes are kind of like that. Would be interesting to let iframes do part/theme

TOC: Interesting...

[...]

[lunch]

lunchtime whiteboard

RN: standalone template part seems very expensive...

AvK: Updater would have a pointer to an element start and end, for attributes would have a pointer. Have a new cloneWithUpdaters or something.
... returns cloned nodes and list of updaters.
... you can build template syntax on that in the future

RN: Thinking about it, I really don't want to do this.

JF: What about clone with parts?

RN: As long as you have a mappig from template to parts, it's bad.

TW: restrict cloneWithUpdates only for templates?

[nodding this is OK]

RN: Yeah, maybe

AvK: making it only for templates, or for docFrags

DD: You do one traversal to find the updater and another to update?

RN: We only want to allow cloneWithUpdater on a template.

DD: Why does it exist?

AvK: So if you clone the tree, the updaters for it get cloned too.
... we need to provide pointers to the new ones for the cWU API.
... clone doesn't copy updaters.

JM: Only interested in them during the preparation of the template. Once I have cloned I don't need to inspect, could just pass it an object.

JF: template engines will need to inspect. So make it your job to tell the template you made an updater?

DD: will look more carefully offline

RN: You want original template tree. To instantiate you clone tree, clone template parts, updater sets the values in there

DD: So you need a traversal to insert the updaters

RN: cloneWithUpdater is to remove the need for a traversal.

<scribe> scribe: Diego

<scribe> scribeNick: diervo

<chaals> https://github.com/webcomponents/issues/468

Providing a lightweight mechanism to add styles to a custom element]

RN: We dont want to add another cascading order

<chaals> DD: like having a phantom shadow root with phantom style sheet there, so that the cascade seems the same

<chaals> TW: As a developer, need this feature where there isn't a shadow root.

<chaals> AvK: Builtins do not lose their style when they have a shadow root...

<chaals> RN: Their styles are UA based and already in the cascade.

AvK: Does it behaves like UA or not for the shadow styles sheets?

<chaals> DD: We are interested in this

<chaals> AvK: If document says green, shadow says red, what do you get?

Avk: There are various proposal for the API of this proposla

<chaals> [red]

DD: If you contruct a styleshee how do you apply it to the document?

Avk: How ordering affects the stylesheet?

DD: There are always after DOM stylesheets

<chaals> ... document.moreStylesheets where the constructable ones live, but don't have a DOM representation.

DD: Is this tied to shadowRoot in an observable way by adding in to the shadow style sheets?

<chaals> DD: they were saying we should put it on shadow.moreStylesheets

<chaals> AvK: Should be link rel...

<chaals> JF: Is their proposal settled yet?

<chaals> DD: Don't think so.

<chaals> ...Tab hasn't got a lot of feedback.

DD: IMO This should not be exposed in the shadowRoot

<chaals> JF: Ordering should be the same between shadow roots and otherwise. So if they behave like being on shadows, but are for custom elements, they should seem like being on shadows.

<chaals> DD: We only talk about shadows as a way to implement, not to make shadow root actually the observable hook.

DD: The point of this feature is to create lightweight stylesheets, we can't compromise on that

<chaals> TW: Main point is to provide lifecycles.

<chaals> HI: using style in shadow tree, with lots of custom elements, you fire a lot of load elements...

<chaals> ... lightweight style sheets should not have to fire them.

<chaals> RN: What happens if you constructed a stylesheet that @imports or references images?

RN: What happens is the contructed stylesheet have @import or other resources?

DD: People don't normally use load events (data from telemetry)

RN: Well but in shadowroot probably people will care more

TW: People have issues with FOAC when loading styles

RN: Constructing stylesheets might work better than strings

<chaals> RN: having constructed style sheet you create it once, fire one load, everything is using that.

Avk: Do we expose this then in the shadowroot API? Seem a little weird to expose it elsewhere

<chaals> JM: can you get to it through the registry?

<chaals> AvK: If you attach a shadow to a div, we wouldn't expect to expose the UA stylesheet...

<chaals> DD: Registry - yes you could do that if people turn out to need it

DD: What selectors will work?
... This should behave as if it were on the shadow root

JM: If you didn't have a shadowroot and slot, would the styles would still work? Its seems that won't be the case

<chaals> [clarification: without making a slot, you don't match ::slotted]

<chaals> [RN updates issue 468 with a summary of consensus]

<chaals> [break 15 minutes]

<smaug> annevk: :host doesn't seem to match anything https://drafts.csswg.org/css-scoping/#selectordef-host

<smaug> without Shadow root

<chaals> Ryosuke's update to the issue.

<annevk> https://github.com/whatwg/dom/issues/510

<annevk> (declarative shadow DOM)

issue tracking

<chaals> AvK: put pointers to shadow issues in various repos.

<chaals> ... topic:shadow as a key across github is pretty uncommon

<tomalec_> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Declarative-Shadow-DOM.md

declarative shadow DOM

<chaals> AvK: Do we want to touch the parser? Probably not...

<chaals> TW: Tried to aggregate the features...

<kochi> https://hangouts.google.com/hangouts/_/google.com/google-com-vvaf

<chaals> TW: main use cases are using HTML without script, and scoping style.

<chaals> ... supporting non-script environments isn't polyfillable.

<chaals> AvK: How do you parse this?

RN: I really don't want to keep streaming on shadow root

<chaals> TW: When you reach start tag, you attach a shadow and start filling it.

<chaals> RN: As long as it is semantics of element, not parse rule, we are OK.

<chaals> ... element removing itself later is OK.

<chaals> AvK: no incremental rendering?

<chaals> RN: right. unless you pause in the middle of parsing it.

<chaals> AvK: So it won't be inert. Scripts won't see the shadow tree... problems there.

<chaals> RN: If you have a script inside a shadowroot element, they execute immediately, as if it were not inside a shadow root.

<chaals> JF: custom element in there will attach to the wrong place.

<chaals> RN: Adding template was unmaintainable. We don't want to repeat that.

Avk: We are going to have security problems if we change the parser
... The previous proposal for template will have a lot of issue with parsing and evaluation the tree

TW: Wouldn't you just clone instance once the template has been populated?

RN: I don't think there is a way about cloning

AvK: You can't do close shadow trees (specifically get references)

<chaals> TW; scriptless environment / Server-side rendering is important

<chaals> DV: Server-side rendering is huge for us.

<chaals> JF: Do you need no script, or just "not much"?

<chaals> DV: We want server-side render, little interactivity...

RN: Adding a new eleemtn that behaves like a shadow is a non-starter

<chaals> ... it does behave like a template.

<chaals> OP: Are there cases where you would take advantage of a template repeatedly adding the same shadow?

<chaals> RN: Feel like this is a different kind of template

<chaals> AvK: If libraries did this, then perhaps we should. Is there much of this in libraries?

DD: It will be interesting to have an END_TAG event, but will be very expensive

RN: We will need to stop parsing when starting evaluating scripts, which is expensive

<inserted> TS: what about search engines?

<chaals> TS: If I have tobuild with light DOM I lose encapsulation of my component.

RN: The mental model for frameworks that rely on components is to rely on the UI view (the component)

<chaals> TS: I don't think we should be disregarding server-side rendering

<chaals> RN: so have data in light DOM, web component upgrades...

<chaals> DV: But you only get the first bit of work done, and what we want is the rendering to happen having done all of that.

<chaals> RN: You want to send a DOM with elements and styles.

<chaals> JF: On documentContentLoaded, crawl the tree, take the templates and move their content into shadows

<chaals> TW: doing it myself gives a lot of flashes

<chaals> RN: you have templates, on DOMContentLoaded you can get the templates and instantiate them and if you want, remove them.

<chaals> TS: Streaming?

<chaals> RN: Nope.

<chaals> DD: You can make crawlers see the content by using a template element.

<chaals> DV: Both cases are solvable in userland. They take a lot of work - can we move some of that towards browsers? Seems like the answer is "not at the moment"

<chaals> TOC: it is an overconstrained problem with a null set solution space.

<chaals> HI: I think we should say clearly that we will not support shadow DOM in scriptless environments.

<chaals> AvK: It might be feasible one day to make parser changes. So I would not say forever, but maybe for a while...

<chaals> DD: Think we should be OK with requiring JS

<janmiksovsky> https://github.com/w3c/webcomponents/issues/645

RESOLUTION: lukewarm non-enthusiasm to put a note in a spec saying that JS is necessary for shadow doms

HTML Modules

<janmiksovsky> Google proposal: https://github.com/w3c/webcomponents/issues/645#issuecomment-343601237

<chaals> JF: This is what we did at TPAC really

<chaals> ... there is a real crowd who want HTML written in HTML. Not JS, CSS, ...

<chaals> [walks through proposal linked]

<chaals> RN: recrusive scruff is likely to be unpleasant.

<chaals> DD: or we bring in the content, without executing until you use it.

<chaals> AvK: Can we use the XHR parser?

<chaals> AvK: There is no browsing context, so script doesn't execute...

AvK: We will have to define some special mode and branch in - I'm inside a module

JF: Is this like super CSP mode?

AvK: We will have to do several checks

<chaals> ... this needs some special mode.

JF: Is this something that we want to pursue for single file components or "single file component"

RN: We need to guarantee that we can gather all dependencies
... We need probably a single XHR mode and then run the scripts once all dependencies are done

<chaals> OP: What do we want to load

<chaals> OP: stylesheets, images, ...or not...

<chaals> AvK: It is a lot of work, but doable...

RN: We need to figureout what is this module type mime/type

<chaals> RN: We need a way to know what is an HTML module compared to scripts

AvK: We should not expose XML if we don't like the parser

RN: We should restrict this proposal as much as possible
... We need to be careful which mode we are going to parse the document (reference to documentFragment )
... We do not upgrade on documentfragments

AvK: We will not get base URLs

JF: Technically we would love to see baseURL in shadowRoot

AvK: Its a lot of plumbing

RN: You will need baseURL that points to the final shadowDom component

DD: What happens for scripts?

AvK: We will have to postprocess to executed them anyway
... Regardless will be a URL problem

JF: Action items: We need to take the feedback from implementors. Figure out document vs documentFragment. Outline pros/cons of the dependency model. Figure out post processing would look like for scripts. Figure out which elements will need postprocessing for all elements (img, video, ...) What kind of APIs are available for this scripts.

AvK: Today document.write will throw at the top level on module scripts

RN: I really like to see use-cases

JF: The use cases I can think of is : HTML includes (import, attach), declarative HTML, single file components

<chaals> [break]

<ChaalsOut> ./whois kochi

Declarative Custom Elements

<chaals> scribe: chaals

<tomalec_> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md

RN: I made a proposal.
... nothing changed on our side.

JF: the big idea is it builds off template processor.

RN: That's pretty much it.
... would like to make it possible to pull values from an attribute and use them in a shadow tree
... so minimum viable thing allows that.

JF: Properties, too

RN: We want to get to declarative custom elements eventually, we see this as a stepping stone.
... previously we didn't have a template syntax, which stopped us. Now we have one...

AvK: These are same-doc, not entrusted?

<justin> untrusted elements via declarative elements: https://gist.github.com/justinfagnani/fea819776d77eee5a108a3bcf873e7f4

RN: Yes, but we considered using this mechanism for cross-origin...

AvK: Is the template instantiation a requirement?

RN: Yes.

AvK: So this is for the future.

TOC: But shows what we need from that.

DD: The problem of using .attributes.name is as TW said. You encourage people to use it and we don't want them to.

JF: Might want to pull out textContent. changing script tags, having a default export of the script...

TOC: That had a problem

RN: Spec says result of running module is undefined.

JF: Default export is OK, right?

RN: Yeah...

JF: People want to do progressive enhancement, think they mean make a stub of an element, and can you do that and later upgrade it bringing in more fun.

DD: Makes sense...

RN: You won't put the definitions in the main document, you wouldn't have them until you import them.
... so this doesn't buy anything.

<hfmanson> Avk: you tagged https://github.com/w3c/webcomponents/issues/634 as "needs implementer interest". Which browser vendors attend this conference? Yesterday I talked to your college Bobby Holley

TW: You use declarative to load a minimal custom element. Then you add something script to do something serious...

[some discussion]

JF: If we support attributes you declare observed attributes...

RN: Less sympathetic to declarative CE that others have to use JS for

JF: Frameworks batch calls to apply through the tree, rather than letting them just run freely... maybe browsers will go that way

RN: We should allow that, not sure we should build it into the browser.

JM: There may be different senses of how far you can get without script. It seems odd for the browser to become more frameworky

JF: Letting Wikipedia use custom elements would be great.

RN: A browser could optimise without a spec change for pushing data around.

JF: AMP is another case

CMN: And MIP - but they feel more like they need script to add behaviour in, much like Tomek's scenario of loading up an element declaratively, but then piling on with script.

JF: If you have declarative CE you will need some kind of linting...

RN: Or we can add a magical end tag...
... We need to sort out template before we can have a more useful discussion on this topic.
... so we need to design the default template processor with the use case in mind of supporting declarative custom elements.

OP: [nods]

The bright brave future.

JM: From outside the browser universe... participation in the platform in the future...
... Product teams seem to be driven by anecdotal experience or very quantitative. This group tends to be the former.
... There is an availability bias. The 2 loud developers in the meeting can misrepresent "what all developers in the world need immediately"
... so it would be good to feel the group is being more methodical about collecting data on what people want.
... Equally, it is hard to find a way to find the others who are looking for a particular feature - there isn't the "vote for a bug" approach that e.g. Edge has.

[/me is nodding as Jan says this.]

RN: We are getting more feedback on Github than we did before...

CMN: I think everyone agrees with you...

[everyone nods...]

JF: COmmunicating a vision that someone could look at and figure out where it is going would help people to understand and so provide useful feedback.

RN: Think we should do better at explaining why we made certain decisions.

JF: Would be good to start with an FAQ...

OP: We need something systematic - we don't have a "blame" for specs in the same way.

RN: Getting the information about what decisions affected a bit of a spec would be handy.

JM: Has the group ever asked people for "their vision of the distant future" as a way of getting some sense?

CMN: Not in the way you describe the exercise, as far as I recall

JF: Focus of frameworks has shifted. It was defining templating, a component model, and we are following that. The change has been noticing we have too much script
... focus now seems to be more doing asynch work and scheduling it. Some of these things are not highly compatible with web components.
... so how do web components fit into that sort of model, managing components without jank...

RN: People say "DOM is slow". It isn't, DOM is fast, but computed style and layout slow stuff down a litte...

[Discussion about how to speed up the Web, by batching read/write]

JF: Are there things we can think about doing that make components fast?

RN: Important to figure out how components communicate with each other. There are some very bad possible appproaches here...

- DRAFT -

SV_MEETING_TITLE

06 Mar 2018

Attendees

Contents