WHATWG
2026-01-19
plaintext logs
prev next
source on github
11:15
<zcorpan>
foolip: Noam Rosenthal : No wide usage of <!marker> in httparchive https://docs.google.com/spreadsheets/d/1JRDf0k6ZYNa_2UZH5QuQuuTs3tjzOVsmqfz53g1ssKU/edit?usp=sharing
11:16
<Noam Rosenthal>
zcorpan: also seems like most downstream parser can handle bogus comments
11:16
<Noam Rosenthal>
zcorpan: main webcompat issue might be with scripts not expecting a new node type after all these years
11:17
<zcorpan>
Yeah
11:18
<zcorpan>
From this search I noticed that some people use <!link ...> as a way to comment it out. SVG has a <marker> element. But I think it's not common enough to be an issue
11:21
<Noam Rosenthal>
zcorpan: I think the main open issue is how to deal with "end" markers. Are they allowed to be orphaned or does DOM deal with disposing them
11:21
<Noam Rosenthal>
(or something in between, where they are parsed as bogus comments when not in the right place, but DOM can move them)
11:22
<Noam Rosenthal>
keeping them atomic seems compelling for simplicity but perhaps moves some of the complexity to the author
11:24
<zcorpan>
I discussed with foolip an idea of yanking both the start and end markers and storing either offsets (like a range) or pointers to the node before start and after end on the container element
11:25
<Noam Rosenthal>
yea but then it can lose the state when serializing
11:25
<Noam Rosenthal>
or if you add elements in between
11:26
<zcorpan>
The serializer can write the markers again though?
11:29
<Noam Rosenthal>
It breaks the mapping... e.g. if you later prepend HTML to the element with markers you have to recompute what's going on and it's easy to lose track
11:31
<Noam Rosenthal>
(especially if you have more than one range)
11:31
<Luke Warlow>
Do these markers work when within embedded svg or MathML contexts? I'm guessing yes?
11:32
<Noam Rosenthal>
Probably yes. As long as it's a normal container element (not self-closing, not script/style/title/textarea / iframe etc)
11:40
<Noam Rosenthal>

zcorpan: e.g. problematic issue:

Before
<!start>
<div id=first></div>
<!end>

<script>
first.after("second")
</script>

If the range state is part of the element it would create an unexpected thing because the new contents would be outside the range

11:45
<zcorpan>
Noam Rosenthal: With the model of storing pointers, the node before start is "Before", the node after end is a whitespace text node. Inserting nodes between would be part of the range.
11:47
<Noam Rosenthal>
yea but then it gets weird if Before gets moved. maybe we can still parse these as bogus comments and the element keeps the range as a pair of pointers to these comments, serializing them with <! if they match the range
11:59
<zcorpan>
I guess that works, yeah
12:00
<zcorpan>
Should it be possible to set markers with DOM API?
12:11
<Noam Rosenthal>
Probably with an API on the element rather than manipulating them directly? Note that anyway you'd have to name those ranges in the sink attribute or whatnot
I wonder though if this adds much because you can still end up with junk bogus comments if you move them around yourself
13:18
<Noam Rosenthal>

... Perhaps this is getting too complicated, and we should keep markers atomic+generic and keep the relationship between markers and patching as an attribute-like thing

<div sink="title search-results">
   <!marker start=title>Current title<!marker end=title>
   <!marker name="search-results">
</div>

This way it's clear that markers are atomic things that DOM doesn't "manage" and error handling is done when patching

16:48
<Noam Rosenthal>

zcorpan, foolip I think this is a lot simpler, jotted it down on gist: https://gist.github.com/noamr/4c8b4972d717816f3e8a0dc4c3e3c907

Basically markers are atomic and unopinionated about patches/ranges. Instead, they provide metadata for patches/ranges as attributes. It allows us to extend markers to other uses in the future or to let frameworks be opinionated about them in other ways

23:44
<Fernando Fiori>

Why is entry global object use discouraged? cc annevk because you mentioned this in a comment (or anyone who could comment on this is also welcomed as the only info I found is this old issue but I didn't see the reasons https://github.com/whatwg/html/issues/1431)

For context, I'm working on this PR where I was using entry global object to reference the frame that initiated an action (calling focus) but using it is discouraged in general in new specs https://github.com/whatwg/html/pull/11519