- From: Douglas Parker via GitHub <sysbot+gh@w3.org>
- Date: Fri, 14 Feb 2025 04:48:52 +0000
- To: public-css-archive@w3.org
Seems the blog post got shared around a bit and increased some of the traffic on this particular issue, I'll try to respond to as much as I can here:
> I wonder if an element would be a better way to convey these semantics than a character entity. We've got `<br>`, so it does seem like a `<sp>` void element with the semantics described here wouldn't be too radical a departure from existing conventions. Seems like that option would be squarely in the WHATWG's domain, which would avoid the need to get Unicode involved.
Personally I'd prefer having an actual space character, rather than a distinct element splitting up multiple text nodes. That feels more intuitive to me and also is more straightforward for tools like CMS which could do basic textual transforms without needing to `innerHTML` an `<sp>` tag and having to deal with the security implications of that. Of course if we need a distinct "non-collapsible space" character anyways, then maybe I should just accept that it won't be "just a space" at the end regardless and `<sp>` might not be all that much worse.
> you don't even need WHATWG involvement if you use a custom element:
>
> <style>nc-sp::before { content: " "; white-space: pre-wrap }</style>
> Hello,<nc-sp></nc-sp><nc-sp></nc-sp><nc-sp></nc-sp><nc-sp></nc-sp>World
I don't think `<nc-sp>` would work for SEO / `<noscript>`, since engines not processing that JS would not know spacing is inserted in that location.
> <style>pre-wrap { white-space: pre-wrap }</style>
> Hello,<pre-wrap> </pre-wrap>World
`<pre-wrap> </pre-wrap>` is probably more viable, since the spaces are at least present in the text. I suspect CMS' would not want to rely on a custom element for their outputs, though a slightly more standard version isn't that far off:
```html
Hello,<pre style="display: inline; white-space: pre-wrap;"> </pre>World
```
[Initial testing](https://jsfiddle.net/98ov2dx0/10/) does seem to line wrap as I would want. This also works for automated formatters and minifiers, both of which already need to preserve spacing inside `<pre>` tags and should know not to mess with it. CMS' are still a little weird per the `innerHTML` point above, I suspect an ideal solution would be plain text / escaped characters, not something which requires a different DOM structure.
However I don't hate this solution. It's awkward and verbose but does preserve the specific spacing required. I'm not sure if there's other behavior here which would be undesirable in this context.
> I have a better suggestion, one that better integrates with how it's actually done in practice: add CSS properties for significant whitespace control.
I don't think any CSS properties are a valid solution here. There is no straightforward way for a CSS property to select a specific space to retain and therefore you need to define broad categories of "all leading spacing" or "all internal spacing". Often the developer just wants one in particular to matter.
Also any automated tooling like HTML formatters or minifiers can't know the CSS which will be applied to a particular element and won't know to retain those significant spaces. The solution needs to be expressible directly in the HTML.
> but have we considered `‌`
I've never heard of this character, but it seems to be a [zero-width non-joiner](https://unicode-explorer.com/c/200C)? If I understand this correctly, the idea is that you would place a `‌` between two space characters to prevent them from being collapsed together?
[Testing this out quickly](https://jsfiddle.net/ba2j0em9/2/), it does seem to prevent collapsing behavior but it doesn't really line wrap correctly. Joined spaces can lead newlines, which isn't the intended wrapping behavior. It should line wrap like a standard space.
> I would go as far as to say that we would be better off going with the solution recommended in [this article](https://blog.dwac.dev/posts/html-whitespace/#how-could-we-fix-this)
Just to be clear, I'm personally very skeptical such a solution is feasible or would even be a net positive on the ecosystem. The point of that section was to describe a hypothetical alternative in order to highlight some of the shortcomings in the existing design such as the ambiguity around developer intent for whitespace (and even that solution doesn't solve all my complaints!). If we could go back in time and redesign HTML from scratch, I might push for something like that, but given where we are now, I don't think anything there is possible. Even if we declared a new `<!DOCTYPE qhtml>`, it would still cause an immense amount of churn in the ecosystem and would almost certainly be a cure worse than the disease.
(Also even if `qhtml` became a thing, there would probably still be value in shipping `&ncsp;` to existing HTML5 users, so this issue still applies.)
> I like that idea better, but I am confused as to why [Newlines [would be] banned by default [in this new html syntax and] a quoted newline [would be flagged as a] syntax error.](https://blog.dwac.dev/posts/html-whitespace/#how-could-we-fix-this:~:text=Newlines%20are%20banned%20by%20default%20as%20it%20would%20be%20way%20too%20easy%20to%20forget%20a%20closing%20quote%20and%20introduce%20unintended%20significant%20spacing.%20Therefore%2C%20a%20quoted%20newline%20is%20a%20syntax%20error.)
It's purely a subjective judgment call, there's plenty of different ways to bikeshed the proposed syntax and I'm sure there's alternatives which are just as good, if not, measurably better than my suggestion. It was just the most immediately obvious approach which was easy to explain in the context of that blog post.
I recommend keeping this issue focused on the `&ncsp;` idea. We can potentially discuss a more holistic improvement in separate issues or venues, though I didn't make any attempt to start such a conversation outside my blog post precisely because I'm not convinced the idea has any real merit.
--
GitHub Notification of comment by dgp1130
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10821#issuecomment-2658269538 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 February 2025 04:48:53 UTC