> Would be writing something like "DOM in the modern browsers" more correct then?
No, I don't think so. I don't know why the GP comment is at the top beyond historical interest. If you continue with your plans mentioned elsewhere to cover things like layout, rendering, scripting, etc, under this standard almost everything will have to have the "in modern browsers" added to it.
Part of the problem is the term "DOM" is overloaded. Fundamentally it's an API, so in that sense it only has meaning for a browser to "have a DOM" if it supports scripting that can use that API. And, in fact, all browsers that ever shipped with scripting have had some form of a DOM API (going back to the retroactively named DOM Level 0). That makes sense, because what's the point of scripting if it can't interact with page contents in some way?
So, "Lynx remains a non-DOM browser by design" is true, but only in the sense that it's not scripted at all, so of course it doesn't have DOM APIs, the same way it remains a non-canvas browser and a non-webworker browser. There's no javascript to use those things (it's a non-cssanimation browser too).
There's a looser sense of the "DOM", though, that refers to how HTML parsers turn an HTML text document into the tree structure that will then be interpreted for layout, rendering, etc.
The HTML spec[1] uses this language ("User agents must use the parsing rules described in this section to generate the DOM trees from text/html resources"), but notes it's for parsing specification convenience to act as if you'll end up with a DOM tree at the end of parsing, even if you don't actually use it as a DOM tree ("Implementations that do not support scripting do not have to actually create a DOM Document object, but the DOM tree in such cases is still used as the model for the rest of the specification.")
In that broader sense, all browsers, even non-modern ones (and Lynx) "have a DOM", since they're all parsing a text resource and turning it into some data structure that will be used for layout and rendering, even if it's the very simple layouts of the first browsers, or the subset of layout that browsers like Lynx support.
I wouldn't do anything to "correct" your guide - I think it is "correct" as is. This comment is great for its informational content but I'd consider it an addendum, not an erratum.
If you like it might be nice to include a section on historical and/or niche browsers that lack some of the elements this guide describes - like e.g. Dillo which is a modern browser that supports HTML4 & doesn't support Javascript. But your guide should (imho) centrally focus on the common expectation of how popular browsers work.
> Would be writing something like "DOM in the modern browsers" more correct then?
No, I don't think so. I don't know why the GP comment is at the top beyond historical interest. If you continue with your plans mentioned elsewhere to cover things like layout, rendering, scripting, etc, under this standard almost everything will have to have the "in modern browsers" added to it.
Part of the problem is the term "DOM" is overloaded. Fundamentally it's an API, so in that sense it only has meaning for a browser to "have a DOM" if it supports scripting that can use that API. And, in fact, all browsers that ever shipped with scripting have had some form of a DOM API (going back to the retroactively named DOM Level 0). That makes sense, because what's the point of scripting if it can't interact with page contents in some way?
So, "Lynx remains a non-DOM browser by design" is true, but only in the sense that it's not scripted at all, so of course it doesn't have DOM APIs, the same way it remains a non-canvas browser and a non-webworker browser. There's no javascript to use those things (it's a non-cssanimation browser too).
There's a looser sense of the "DOM", though, that refers to how HTML parsers turn an HTML text document into the tree structure that will then be interpreted for layout, rendering, etc.
The HTML spec[1] uses this language ("User agents must use the parsing rules described in this section to generate the DOM trees from text/html resources"), but notes it's for parsing specification convenience to act as if you'll end up with a DOM tree at the end of parsing, even if you don't actually use it as a DOM tree ("Implementations that do not support scripting do not have to actually create a DOM Document object, but the DOM tree in such cases is still used as the model for the rest of the specification.")
In that broader sense, all browsers, even non-modern ones (and Lynx) "have a DOM", since they're all parsing a text resource and turning it into some data structure that will be used for layout and rendering, even if it's the very simple layouts of the first browsers, or the subset of layout that browsers like Lynx support.
[1] https://html.spec.whatwg.org/multipage/parsing.html
I wouldn't do anything to "correct" your guide - I think it is "correct" as is. This comment is great for its informational content but I'd consider it an addendum, not an erratum.
If you like it might be nice to include a section on historical and/or niche browsers that lack some of the elements this guide describes - like e.g. Dillo which is a modern browser that supports HTML4 & doesn't support Javascript. But your guide should (imho) centrally focus on the common expectation of how popular browsers work.