5 ms·

> Do you mean "any change to whitespace in HTML or XML results in a semantically inequivalent document"? In the strictest sense? Yes. Of course, we can build

> Do you mean "any change to whitespace in HTML or XML results in a semantically inequivalent document"? In the strictest sense? Yes. Of course, we can build tools that make... call it "unsound assumptions"... and I'll happily use them and encourage their use, because you can make the correct judgement call that those assumptions should hold in your context (and that the one causing the assumptions to be broken, if they ever are, is the one "at fault" rather than the tools.) On the other hand, if those same tools are then automatically applied beyond your control, there's a good chance those unsound assumptions will be broken, and become a source of pain and suffering for whatever strange - or not so strange - edge cases your own context comes with. Whitespace isn't the only source of this problem - and it's one of the problems I have with WYSIWYG editors in general. Often, they don't clean up after themselves and leave behind a bunch of editor shrapnel, in part because they can't remove stuff that might technically be semantically inequivalent. Those same editors might also remove stuff I wanted to keep!

lmm 2y ago
> Of course, we can build tools that make... call it "unsound assumptions"... and I'll happily use them and encourage their use, because you can make the correct judgement call that those assumptions should hold in your context (and that the one causing the assumptions to be broken, if they ever are, is the one "at fault" rather than the tools.) That's a pretty bad way to standardise a data format IMO. If readers, writers, and tools all want these representations to be equivalent, far better to make that equivalence part of the standard - the point of the standard is to support the use cases, and being able to sensibly reformat HTML is far more valuable than being able to preserve a distinction that doesn't show up in any browser and most writers would never intend anyway.
- austin-cheney 2y ago
  The need for equivalence, if any, is in the parsing and not the visual presentation. HTML does not consider itself, according to its maintainers, to be a presentation format.
  - lmm 2y ago
    Which makes it decidedly unfortunate that you cannot determine whether a sequence of spaces are collapsible or not without consulting the presentation layer, even though this should be a semantic/parsing question.
    - tsimionescu 2y ago
      The concept "collapsible spaces" is not a part of the HTML format, it is a decision that certain renderers apply, and others may not.
      - lmm 2y ago
        Are there actual renderers that don't, and are there real users who consider that reasonable behaviour? I mean maybe someone somewhere has a spacebar heating workflow that relies on it, but file formats and standards should not add ways to shoot yourself in the foot if they can help it.
        tsimionescu 2y ago
        As this article shows, browsers actually collapse spaces differently based on the specific CSS applied - and this is in fact intended behavior, not some corner case. Also, the output of HTML parsers is the HTML structure, and changing that to collapse spaces would break numerous tools. So while probably all HTML renderers do some kind of space collapsing, there are many other uses of HTML parsing that don't. Most likely the syntax highlighting in your HTML editor of choice in fact relies on a space-preserving HTML parser, just for one example.
        lmm 2y ago
        > browsers actually collapse spaces differently based on the specific CSS applied Sure. But they do all collapse spaces. I don't think anyone wants their browser to always preserve all the spaces that are in the source. > and this is in fact intended behavior, not some corner case. Eh maybe. They collapse the spaces of block elements like block elements and the spaces of inline elements like inline elements; that seems like the obvious thing that your renderer would do if you didn't make any deliberate design decision. > So while probably all HTML renderers do some kind of space collapsing, there are many other uses of HTML parsing that don't. Most likely the syntax highlighting in your HTML editor of choice in fact relies on a space-preserving HTML parser, just for one example. I very much doubt it. And even if it did, that would be an incredibly backwards reason to keep that behaviour - "we've spent all this effort working around our bad standard, that would be wasted if we fixed the standard".

lmm 2y ago

> Of course, we can build tools that make... call it "unsound assumptions"... and I'll happily use them and encourage their use, because you can make the correct judgement call that those assumptions should hold in your context (and that the one causing the assumptions to be broken, if they ever are, is the one "at fault" rather than the tools.) That's a pretty bad way to standardise a data format IMO. If readers, writers, and tools all want these representations to be equivalent, far better to make that equivalence part of the standard - the point of the standard is to support the use cases, and being able to sensibly reformat HTML is far more valuable than being able to preserve a distinction that doesn't show up in any browser and most writers would never intend anyway.

austin-cheney 2y ago
The need for equivalence, if any, is in the parsing and not the visual presentation. HTML does not consider itself, according to its maintainers, to be a presentation format.
- lmm 2y ago
  Which makes it decidedly unfortunate that you cannot determine whether a sequence of spaces are collapsible or not without consulting the presentation layer, even though this should be a semantic/parsing question.
  - tsimionescu 2y ago
    The concept "collapsible spaces" is not a part of the HTML format, it is a decision that certain renderers apply, and others may not.
    - lmm 2y ago
      Are there actual renderers that don't, and are there real users who consider that reasonable behaviour? I mean maybe someone somewhere has a spacebar heating workflow that relies on it, but file formats and standards should not add ways to shoot yourself in the foot if they can help it.
      - tsimionescu 2y ago
        As this article shows, browsers actually collapse spaces differently based on the specific CSS applied - and this is in fact intended behavior, not some corner case. Also, the output of HTML parsers is the HTML structure, and changing that to collapse spaces would break numerous tools. So while probably all HTML renderers do some kind of space collapsing, there are many other uses of HTML parsing that don't. Most likely the syntax highlighting in your HTML editor of choice in fact relies on a space-preserving HTML parser, just for one example.
        lmm 2y ago
        > browsers actually collapse spaces differently based on the specific CSS applied Sure. But they do all collapse spaces. I don't think anyone wants their browser to always preserve all the spaces that are in the source. > and this is in fact intended behavior, not some corner case. Eh maybe. They collapse the spaces of block elements like block elements and the spaces of inline elements like inline elements; that seems like the obvious thing that your renderer would do if you didn't make any deliberate design decision. > So while probably all HTML renderers do some kind of space collapsing, there are many other uses of HTML parsing that don't. Most likely the syntax highlighting in your HTML editor of choice in fact relies on a space-preserving HTML parser, just for one example. I very much doubt it. And even if it did, that would be an incredibly backwards reason to keep that behaviour - "we've spent all this effort working around our bad standard, that would be wasted if we fixed the standard".