04:43
<aresuii>
@sideshowbarker who was that guy
04:44
<sideshowbarker>
no idea
04:57
<aresuii>
ok but what is "Guest Standard"
09:44
<smaug>
We can do something like that yes, and have consistent behavior for all Promise APIs. It does change the meaning of microtasks though, a bit, if JS doesn't really run. But anyhow, that would be better than having the current ad-hoc "let's run microtasks here".
10:56
<Noam Rosenthal>
Does something like "Perform a promise entry point with the following step: activate view transition" sound right?
11:02
<Noam Rosenthal>
There are a few promise entry points which don't work like this, e.g. ones that fire multiple promises and events as part of one stack and rely on the behavior of the microtask queue firing at the end of the stack. but I think probably that should be the exception
11:05
<annevk>
zcorpan: rs? https://github.com/whatwg/html/pull/12060
11:07
<Noam Rosenthal>
Approved, but I now see you asked specifically from zcorpan
11:12
<zcorpan>
annevk: reviewed and merged
12:00
<Noam Rosenthal>

I've added a comment to out-of-order streaming with the thinking around markers after the last WHATNOT. https://github.com/whatwg/html/issues/11542#issuecomment-3743936051

zcorpan keithamus Jake Archibald it attempts to answer some of your questions about processing instructions, polyfills, and developer ergonomics.

12:10
<Noam Rosenthal>
https://github.com/whatwg/html/issues/12080
12:16
<zcorpan>
Noam Rosenthal: Can marker-start and marker-end be anywhere (in normal elements), or do they need to be siblings?
12:17
<Noam Rosenthal>
If they're not siblings they don't match each other because you'd hit the end of the marker's parent before hitting the matching marker-end
12:18
<Noam Rosenthal>
IOW only sibling marker-start/marker-end pairs create an automatic range for <template contentfor>
12:19
<zcorpan>
What if you have <div><?marker-start name=x ?><span><?marker-end name=x ?></span></div>
12:21
<Noam Rosenthal>
it's a good case, but it would resolve to siblings in some way or another. probably the ancestor of the span that's a sibling of marker-start
12:22
<Noam Rosenthal>
though by how I put it in the comment it only iterates on the siblings, so it would simply ignore marker-end and reach the end of the DIV. Perhaps that's better
12:22
<Noam Rosenthal>
(less recursive iteration)
12:23
<zcorpan>
I was thinking it might be better to require an attribute on the element, and allow marker-start and marker-end PIs (without name pseudo attribute) as direct children
12:23
<zcorpan>
But doesn't support multiple marker-starts with different names in one element
12:23
<Noam Rosenthal>
yea but that would make it so that you can only have one marker-pair per element
12:23
<Noam Rosenthal>
exactly
12:26
<zcorpan>
Or we can have markers="results more-results"
12:27
<Noam Rosenthal>
instead of attributes on the markers? seems a bit less ergonomic though no? What's the rationale?
12:29
<zcorpan>
Yes. Seems more ergonomic if you have one marker and both start and end, but can be less for other cases. Or hard to follow which marker is which if the names depend on ordering. Rationale is attributes on elements are better understood and supported in various tooling
12:30
<zcorpan>
Easy to query for an element with an attribute, then iterate children to find markers
12:31
<Noam Rosenthal>
Gotcha. It also works nicely when you want the simple case of replacing everything (just don't have marker PIs), and works nicer for polyfills. I can see the appeal given that multiple marker-pairs inside the same element is probably more rare to beginwith
12:32
<zcorpan>
Yeah. Also makes for one way to do things
12:32
<Noam Rosenthal>
I'd use marker rather than markers though (I don't think we tend to use plural in attribute names?)
12:37
<zcorpan>
We have headers but also class
12:56
<Noam Rosenthal>
And srcset :)
12:58
<Noam Rosenthal>
what this doesn't allow doing is complex overlaps, but perhaps it's OK. e.g.: <?marker-start name=a?> Content <?marker-start name=b?> Content <?marker-end name=a?> Content <?marker-end name=b?>
12:59
<zcorpan>
Yeah, though we can allow name pseudoatt to override implicit name assignment
13:00
<Noam Rosenthal>
yea sure. so use the DOMTokenList thingy as a default index, and then those PI attributes for complex things
13:01
<zcorpan>
Yep
13:02
<zcorpan>
I want to find out if it's compatible to change from comment to ProcessingInstruction generally for <?foo > in HTML, and also whether we want the trailing "?"
13:07
<Noam Rosenthal>
It's probably safer to start with just <?marker-start and <?marker-end... We can run an HA query with a RegExp for the general case but I'm sure we'll find stuff. the only way to really test for web-compat is to run a trial and see if people scream I think
13:08
<Noam Rosenthal>
I think we don't need the ending ?, <?marker-start> is perhaps OK?
13:11
<zcorpan>
Yep. I suppose we can support (trim) a trailing ? in the same way we ignore trailing slash on start tags
13:29
<zcorpan>
https://docs.google.com/spreadsheets/d/1o04eP_BwH1u7X8CyyLUvxOsntZNmfrDalfhU7ldVqlU/edit?usp=sharing is for 1% of HA. Mostly <?xml and PHP
13:48
<Noam Rosenthal>
I think I'm cautiously optimistic about it being safe web-compat wise. the only use case for this is PHP/HTML editors that use the DOM to update these comments and check for node type explicitly
13:50
<annevk>
Consider shortening things to <?start ...?> and <?end ...?>
13:51
<annevk>
Or <?marker ...?> and <?/marker ...?>?
13:53
<zcorpan>
<?/marker ?> is not well-formed XML
13:54
<Noam Rosenthal>
Note that <?marker-end> can live without <?marker-start> (replace everything from the start of the element until that marker), Perhaps <?mark> and <?mark-end>
13:55
<annevk>
Just have to be mindful that there might be a lot of these so you want them to be easy to scan and ignore and not add a lot of noise.
13:55
<Noam Rosenthal>
Though I'm also OK with <?start> and <?end>
13:56
<Noam Rosenthal>
Sure, though I think <?mark{something}> connects it back to the marker attribute
13:56
<annevk>
To be clear <?mark[-end]> seems like an improvement to me. I wonder how much we care about XML since I like the slash even better, but maybe that's just me.
14:01
<Luke Warlow>
I like the / too fwiw. Would these be aimed at working in an XHTML document? If not I think XML well formedness is meh. Then again I think XML and XHTML are pretty meh anyway.
14:02
<Noam Rosenthal>
it would feel surprising that you have a <?/mark> without a <?mark> and it would somehow work. though we can also disable that concept and force having a start marker
14:02
<zcorpan>
DOM createProcessingInstruction will also throw
14:02
<annevk>
That seems okay to me actually, if a bit novel. But then all of this is novel so we get to decide.
14:04
<annevk>
We should figure out if we want correspondence with PIs, and if so, what kind. Would be nice if these didn't have all the mutability of CharacterData for instance.
14:05
<Noam Rosenthal>
I think it's nice that document.evaluate("/processing-instruction('marker')") works. XPath is a bit niche at this point but having some way to select these is nice given that querySelector wouldn't
14:12
<Noam Rosenthal>
That mutability is not very useful here, but since it's also there for comments perhaps it's harmless?
14:33
<zcorpan>
If names are implied by order they need to be recomputed on mutations (not just to target, data but also node insertion, removal, move)
14:41
<Noam Rosenthal>
yes sure but supposedly since targeting is done using the parent element when the template is parsed, we don't need to keep this information cahced/alive/up-to-date anywhere
15:06
<Noam Rosenthal>
btw I think it might be easy to get confused if it's <?/mark> or </?mark>. I'm tending to like <?mark> and <?mark-end> better
18:20
<Noam Rosenthal>
I guess that DocumentType is a precedence where the node type is an immutable special-case of bogus comments. Maybe it's a good precedence for having a Marker as a narrowly defined immutable node type that is a direct subclass of Node