Spring 2023 DOM Parts F2F #999
Comments
|
Should we throw some ideas around for an agenda? Question I would like to see answered:
|
|
One (perhaps the only?) viable alternative if we must support the table element as is, would be empty template elements, which was the direction I was going before I learned of the ability to query processing instructions with xpath. I was able to get nested loops working without bookending before and after, relying instead on the cnt attribute. But I only tested that two levels deep, and didn't yet convince myself it wouldn't run into trouble as the complexity of scenarios increased. So I would be hesitant to adopt that solution without far bigger implementations from high usage libraries trying it out. As my comments indicate, I would have preferred using the data element, as that seems to be its purpose, but as I recall, table elements spit them out as well. Has anyone done performance comparisons between the two? (empty template elements vs processing instructions). Yes, my intuition tells me processing instructions would win out, but you never know, I guess? |
|
Looks like Tuesday, May 2nd 10-11am is the only time slot in which everyone is available with Tuesday, May 2nd 9am-10am being the second slot with most availability (only smaug is unavailable). With that in mind, I tentatively propose we host this on Tuesday, May 2nd 9am through 11am PDT (UTC 4pm through 6pm) |
|
In case anyone's interested, I ran a simple test of creating thousands of empty template elements vs processing instructions. Performance was roughly equal. |
|
Are there any notes of what was discussed that led to doubts whether {{}} is a feasible authoring tool? If it isn't a feasible authoring tool, then there doesn't seem much point to supporting interpolation beyond what spans can provide. However, I think the output of what is rendered needs to provide enough information so we can reverse engineer everything. I earlier endorsed (to the wind, I'm sure) the comment idea, but if my quick analysis is correct that the cost of a processing instruction matches the cost of an empty template, templates would be much easier to apply an xslt transform to reverse engineer the server rendered content to extract the data and {{}} based template (which would keep the syntax the originating template needs to support simpler). A quick lookup indicates comments can be used for ranges, so not sure where that question came from either. Maybe there's some more subtle nuance I'm missing? I also did my usual second guessing about the possibility of using "flat" elements (no bookending) to model nested structures. I don't yet have 100% in my solution. But I remember now where I got the idea. There are actually plenty of robust grids (starting with slickgrid) that managed this quite well (using "levels" to keep track of the nested structure). This would reduce the number of (unnecessary) elements, I think, which could only help performance. At least something to consider? |
|
@bahrus I'm not sure how you would suggest that we replace processing instructions in the current proposal with The question is whether or not comments should mark the beginning and end of a child node range. Meaning, if you remove one of the comment nodes from the DOM, the range would be invalid, and whatever nodes are between the two comments be precisely what the range represents, rather than some abstract non-DOM based concept of a child node range where you would have to explicitly add or replace nodes in the range via a new API, and sibling additions would have no impact (which leads to unintuitive behavior like if a node gets added in between two nodes that are part of the range, should that node be part of the range too?). It's really a question of whether the placeholders representing ranges should be serialized to the DOM as nodes (in the declarative case, comment nodes, but in the imperative case whatever nodes the user provides) or not. Not sure I understand what a "flat" element possibility would be, perhaps you could explain. |
|
@tbondwilkinson , thanks for the clear explanation on the child node range issue. I'm sure I don't yet fully understand the processing instruction proposal, and that will quickly become apparent with my examples below, but the way I see our options is this: Suppose we do use {{}} as out authoring tool. And suppose our template looks like this: <template>Hello, {{name}}</template>And say the host object is: {"name": "Adam"}The server could generate: Hello, Adamwhich would leave us unable to reverse engineer the output and update the name property, nor infer what the original template looked like. Hence the need for some markers, which could include a "book-ended", "non-flat" child processing instruction: A: Hello, <?child-node prop="name"?>Adam</?child-node?>or a book-ended, non flat empty templates: B: Hello <template prop=name start/>Adam<template end/>or a "non-book-ended", "flat" representation with empty templates: C: Hello <template prop=name node-count=1 level=0/>Adamor a "non-book-ended", "flat" representation with processing instructions: D: Hello <?child-node prop=name node-count=1 level=0 ?>AdamI'm suggesting C and D might perform a little better, especially with many nodes, because it cuts the number of nodes in half (roughly). Although I agree with full access to JS and sufficient grunt work, it is possible to extract out the same information with all of these, I'm suggesting that I have more options to do it more simply when I compare B with A. With B I can query using CSS (in addition to XPath), and XSLT instructions might be simpler, because I'm not sure "attributes" inside the processing instruction come pre-parsed? Same goes with JS manipulation. If the performance is the same, doesn't that give empty templates the edge as far as what we should prefer? |
The main objection (attempting to summarise from the notes) is that |
|
Another potential benefit of using empty template elements: I could see the microdata initiative of itemprops attributes being extended to support empty template elements. Extending it to support processing instructions seems less likely to me. |
|
I don't think this is the issue to discuss these things. It would be much easier to track the syntax discussion in a syntax issue. This one should be about planning the meeting. |
|
Opened #1003 |
|
Are we meeting today, Tuesday, May 2nd 9am through 11am PDT (UTC 4pm through 6pm)??? I need to make some plans... |
|
I'm curious as well |
|
the meeting still not on WCCG calendar, could someone send an invite, please? |
|
I believe this is still happening, and some folks from Google are definitely planning to attend. I've created a calendar event for the meeting, since it looks like that hasn't happened yet. Details below.
|
|
In today's F2F DOM parts discussion, we agreed that we need another follow up meeting in a month or two.
|
|
My availability:
|
|
June 5-7 is Igalia's Web Engine Hack Fest https://webengineshackfest.org/2023/ So, we may want to avoid conflicting with that. Any of the other dates look like they will work for me. |
|
Here's a link to the use-case slides I showed today: https://docs.google.com/presentation/d/1nBxZI4X6hVFct5t4VFCJqc4_j92nZtAxWqXDCottUus/edit?usp=sharing |
|
My availability:
|
|
Mine:
|
|
Results so far:
|
|
Mine: |
|
Should we decide on a week? |
|
Looks like the week of July 17th and July 24th are only weeks in which everyone is available. |
|
Works for me! Can you put together a whenisgood for those two weeks? |
|
Looks like Tue, July 18th 10am to 12pm PDT (5pm to 7pm UTC) is the current winner so far. |
|
@tbondwilkinson I've started to write a template engine, and I decided to use this format:
<template>Hello, ${ name }</template>
$[ extends "base.html" ]
$[ header ]
$[ content ]
<template id="header">
<h1>${ title }</h1>
</template> |
|
Myself and a few other folks (Justin, Mason) are planning on attending the meeting tomorrow, if it still works for you Ryosuke and anyone else who was originally interested. |
|
I've got it on my calendar and am planning to attend. Just need the meeting invite when it's available. |
|
I'm not sure if I can come but can I get an invite in case I can? I'd like to. |
|
DOM Parts F2F |
|
I did some prototyping over the weekend with Chrome Canary's experimental implementation in rictic/web-template-workbench#1. I'll plan to attend and share feedback. |
|
Updated meeting link for today: DOM Parts F2F |
During today's web components F2F, we came to a conclusion that we need a longer separate meeting time to discuss DOM parts proposal.
Please indicate your availability in when2meet.
Update: Current proposal is to have this on Tuesday, May 2nd 9am through 11am PDT (Tuesday, May 2nd 4pm through 6pm UTC)
The text was updated successfully, but these errors were encountered: