[css-text] Non-Collapsible Space #10821
Comments
Rather than
Do you mean that you want some sequences of spaces to collapse, but not others? Why not just preserve all spaces and use a single one instead of multiple wherever you want to see a single one?
And you want to see both or one?
When I write
And I don't think they will find this much appealing... |
|
Yeah, see whatwg/html#5121 and whatwg/html#7071 for instance. |
Preserving all spaces in an element is a larger change than strictly necessary to preserve only a particular set of spaces within it and forces the developer to compromise other aspects of how they write their HTML, such as eliminating any indentation or newlines depending on the specific Also as mentioned, CMS tools generally can't rely on any specific styles being applied to an element, so any CSS requirement feels like a non-starter for that use case.
In this example, I would want to see both spaces. If the developer types
Thanks for pointing that out, I wasn't aware new HTML entities were so difficult to add. I agree this is unlikely to meet the impact needed to justify its addition. An unnamed entity could technically address the same purpose, though I imagine it would be significantly harder to convince the community to prefer an unnamed It seems I was at least correct that this would require a new Unicode character, but it sounds like it would make more sense to file this in https://github.com/whatwg/html? I imagine we'd need at least some amount of consensus there among HTML stakeholders that this is worth pursing before there would be any hope of getting Unicode on board. |
|
Not the ideal solution, but you can simulate it by interleaving no-break
spaces and zero-width spaces:
```
foo​ ​ ​bar
```
…On Sat, Sep 7, 2024 at 5:14 PM Douglas Parker ***@***.***> wrote:
Rather than pre, you probably want pre-wrap, and possibly combine it with
white-space-trim.
Do you mean that you want some sequences of spaces to collapse, but not
others? Why not just preserve all spaces and use a single one instead of
multiple wherever you want to see a single one?
Preserving all spaces in an element is a larger change than strictly
necessary to preserve only a particular set of spaces within it and forces
the developer to compromise other aspects of how they write their HTML,
such as eliminating any indentation or newlines depending on the specific
white-space value they are using and the trade offs that requires. &ncsp;
would not require developers to make that kind of compromise. They could
use any white-space value and just choose to keep any arbitrary space
within the element.
Also as mentioned, CMS tools generally can't rely on any specific styles
being applied to an element, so any CSS requirement feels like a
non-starter for that use case.
maybe I'm one of those people who insists on two spaces at the end of
every sentence
And you want to see both or one?
In this example, I would want to see both spaces. If the developer types Good
new everyone! HTML supports non-collapsible spaces now. (note two spaces)
they will naturally be collapsed into a single space when rendered in HTML.
&ncsp;&ncsp; would allow both spaces to be preserved, regardless of the
rest of the content or styling for that element.
Yeah, see whatwg/html#5121 <whatwg/html#5121>
and whatwg/html#7071 <whatwg/html#7071> for
instance.
Thanks for pointing that out, I wasn't aware new HTML entities were so
difficult to add
<https://github.com/whatwg/html/blob/main/FAQ.md#html-should-add-more-named-character-references>.
I agree this is unlikely to meet the impact needed to justify its addition.
An unnamed entity could technically address the same purpose, though I
imagine it would be significantly harder to convince the community to
prefer an unnamed &ncsp; character over for those mis-use cases.
It seems I was at least correct that this would require a new Unicode
character, but it sounds like it would make more sense to file this in
https://github.com/whatwg/html? I imagine we'd need at least some amount
of consensus there among HTML stakeholders that this is worth pursing
before there would be any hope of getting Unicode on board.
—
Reply to this email directly, view it on GitHub
<#10821 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AET4OW5KSZXXZ66F4J2RHT3ZVNUCRAVCNFSM6AAAAABNQ5OWXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWGQ2TIMBSHE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I don't think interleaving no-break and zero-width spaces quite works because no-break spaces have a forced width, meaning they always take up space even when line wrapping would not require it. See point 3 of the original comment, that issue still exists with an interleaving approach. |
|
Angular introduces it's own special white space entity for similar purposes: &ngsp; https://angular.dev/guide/templates/whitespace#preserving-whitespace |
|
I wonder if an element would be a better way to convey these semantics than a character entity. We've got |
|
It's still not much clear to me what exact behavior is wanted here, but 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>Worldor <style>pre-wrap { white-space: pre-wrap }</style>
Hello,<pre-wrap> </pre-wrap>World |
|
I have a better suggestion, one that better integrates with how it's actually done in practice: add CSS properties for significant whitespace control.
In each of these, And of course, three shorthand properties:
In all three, they can accept up to two, but if you only pass one, it intelligently applies to both. For an easier time with HTML, especially with minifiers and formatters, add [trim~=before-start i] {
white-space-before-start: collapse;
}
[trim~=after-start i] {
white-space-after-start: collapse;
}
[trim~=before-end i] {
white-space-before-end: collapse;
}
[trim~=after-end i] {
white-space-after-end: collapse;
}
[trim~=inside i] {
white-space-inside: collapse;
}
[trim~=outside i] {
white-space-outside: collapse;
}
[trim~=both i], [trim=""] {
white-space-control: collapse;
}
[notrim~=before-start i] {
white-space-before-start: retain;
}
[notrim~=after-start i] {
white-space-after-start: retain;
}
[notrim~=before-end i] {
white-space-before-end: retain;
}
[notrim~=after-end i] {
white-space-after-end: retain;
}
[notrim~=inside i] {
white-space-inside: retain;
}
[notrim~=outside i] {
white-space-outside: retain;
}
[notrim~=both i], [notrim=""] {
white-space-control: retain;
}Then, if you really wanted to, you could introduce something like a ncsp {
display: contents;
height: 0;
width: 0;
visibility: none;
white-space-outer: retain;
} |
|
@dead-claudia That's basically https://drafts.csswg.org/css-text-4/#white-space-trim |
Oh, then in that case, we should just add those global HTML attributes to match. [trim] {
white-space-trim: discard-before discard-after discard-inner;
}
[trim~=before i] {
white-space-trim: discard-before;
}
[trim~=after i] {
white-space-trim: discard-after;
}
[trim~=inner i] {
white-space-trim: discard-inner;
}
[trim~=before i][trim~=after i] {
white-space-trim: discard-before discard-inner;
}
[trim~=before i][trim~=inner i] {
white-space-trim: discard-before discard-inner;
}
[trim~=after i][trim~=inner i] {
white-space-trim: discard-after discard-inner;
}
[trim~=before i][trim~=after i][trim~=inner i] {
white-space-trim: discard-before discard-after discard-inner;
} |
|
but have we considered |
|
@VoxelPrismatic I could see that working as well:
Screen readers do seem to ignore them, so it shouldn't present an accessibility problem. |
|
I would say that there should be a shorter way to get non-collapsing spaces, perhaps <span>Hello,</span>&________;<span>World!</span>which would produce (each underscore is a space) |
|
The nerds are right, this is a CSS problem, fix it in CSS. |
|
I would go as far as to say that we would be better off going with the solution recommended in this article, but making it compatible with older HTML versions by simply having to go from Unfortunately, I doubt this solution would be implemented, even though it would make using and and debugging things which involve HTML and CSS, much easier. |
|
@dgp1130, some questions for you. Going off of @sapioit 's comment, 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. You say it is because it would be easier to forget closing quotes? and that using &lf; would be the replacement for /n in single quoted strings? (remember that some type of newline character is needed in single quoted strings, otherwise we would have to use a #define or something in cshtml to continually refer to a triple quoted newline string when creating strings programmatically) Is there some reason you chose &lf;? Does not quoting it produce errors more reliably than not quoting a /n? Is missing a closing quote that hard to debug? |
|
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:
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
I don't think
Hello,<pre style="display: inline; white-space: pre-wrap;"> </pre>WorldInitial testing 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 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 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.
I've never heard of this character, but it seems to be a zero-width non-joiner? If I understand this correctly, the idea is that you would place a Testing this out quickly, 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.
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 (Also even if
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 |
|
|
My intent behind this feature request is more about a non-collapsible space character, how one produces that character is effectively an implementation detail. I agree I'll update the title and initial comment to make that more clear. |
dgp1130
changed the title
&ncsp; - Non-Collapsible Space
|
@dgp1130 you can use be warned that all spaces will be visible, even after wrapping. |
|
@dgp1130 You'd have much better luck asking the Unicode Consortium for that. (And they'd likely reject it if the below works - they'd only approve it if there's no alternative. They're very, very picky with their approvals.) However, have you considered a zero-width space? The relevant CSS spec explicitly only counts ASCII whitespace (U+0009, U+000A, U+0020, and indirectly U+000D in HTML due to CRLF normalization) as whitespace it can collapse. It doesn't collapse any other code point in Unicode category Zs. So you may be able to get away with using |
I considered that in #10821 (comment), but like you mention, the line wrapping behavior isn't right.
My intent behind I tried interleaving with
If there's a character which can serve as a regular space but avoid this line wrapping behavior, then maybe we can apply "non-collapsible" behavior to it by interleaving |
|
@dgp1130 And to be clear, what is the difference between what you need and what For clarity, per spec:
Twitter uses this for their post display, since users like to use spaces for text layout in precisely the same way you talk about with CMS users. |
|
At the risk of repeating myself and being annoying, I have to say: this article explains why One of the reasons is the inconsistency, since your solution would likely need to be applied as That's why I think the |
|
Also, the linked article makes untrue statements like "all newlines at the start of a |
Adding zero-width spaces prevents this with no change to alignment. And zero width spaces should be treated as space by any functioning screen reader. This does still impact what text is copied to the clipboard, though. |
@sapioit you are insane if you believe this is reason enough to touch the most likely scenario in which i encourage the public paritcipation from common developers in spec authorship. but copy pasting opinions from entertainment-coding-youtube-channels, is not how you do it. this is the video in question and the reason why this issue is getting so much traction. |
|
That video might be why people are getting here, but that doesn't mean they don't have issues with the problems presented in said video, and in that link I linked in two previous comments. Well, if the doctype isn't changed, that doesn't mean there can be no solution. For example, adding |
|
Again: all of these ideas for HTML are out of scope here. Propose them to the WHATWG if you want (but the likelihood of being accepted still seems negligible to me). |
|
@sapioit again: you want to fix the web, thank you, but not like this |
HTML whitespace collapsing behavior makes it very difficult to directly manage individual spaces rendered in an HTML document. Whitespace collapsing has a few problems today:
Hello, Worldin a CMS system, it will be rendered asHello, Worldin HTML. The CMS can't really do anything about this to get the document to render as intended by the author without forcing all strings to usewhite-space: pre;.white-space: pre;applies to the whole element, but the user might want two spaces in a particular place within that element. For example, maybe I'm one of those people who insists on two spaces at the end of every sentence. sounds like an easy fix for "Just add a space here", but forces non-breaking and a forced-width behavior the user may not want (when line wrapped, always takes up one space of width, even when that's not needed). See the line wrapping behavior of this demo as the viewport shrinks. is the unnamed entity for a single space, which sounds like it would be a good alternative given that I really want the behavior for a simple space. However, is also subject to whitespace collapsing so it can't really solve this kind of problem. This feels especially weird since whitespace collapsing exists as an affordance to developers who want to format their HTML source code differently from the rendered output, but any developer who writes clearly wants that space to be rendered as-is. Collapsing those spaces goes directly against developer expectations.This is a shorter, more focused breakdown on some of the problems with whitespace collapsing, however I wrote a whole blog post digging deeper into the complexity at play here which motivated this particular issue and gives additional context and motivation.
I propose a new
&ncsp;entity which is treated identically to a regular space, however is not subject to whitespace collapsing. You could writeHello,&ncsp;&ncsp;&ncsp;&ncsp;&ncsp;Worldand actually get multiple adjacent spaces likeHello, World.Edit: It seems it is not possible to add new HTML entities so
&ncsp;as a syntax won't work. However, the key feature request is a non-collapsible space character. The exact syntax for producing that character is an implementation detail.This would address the above challenges because:
&ncsp;where white space is significant.&ncsp;without having to opt-in an entire element into the rules ofwhite-space: pre;.&ncsp;could serve as a drop-in replacement for existing usages of but present better line wrapping behavior.&ncsp;would work in the way I wish worked and behave in a more predictable fashion.I'm not 100% which standards body is the right one to own this particular issue, however I filed it here because whitespace collapsing seems to be a part of the
css-textstandard. In theory,&ncsp;is just an alias for a standard space, one which just gets ignored by the whitespace collapsing algorithm. However, as I understand it based on the current layering of browsers, the HTML parser would resolve&ncsp;into a regular space character, and it would then be impossible for the CSS to disambiguate spaces which originated from&ncsp;entities. Therefore I suspect this would actually require a brand new Unicode character. If one were added for this purpose, then the existingcss-textstandard likely wouldn't need to be changed at all. However, it feels weird to add one solely to solve an HTML issue like this and I'm not sure that's feasible. What exactly would a non-collapsible space do in a non-HTML context? An alternative approach might be for the HTML parser to convert&ncsp;to a different, user-space Unicode character known by thewhite-spacespec which gets rendered as a standard space but is otherwise ignored for collapsing. I'm not sure that's a great architectural idea, but its the one solution which comes to mind here.Feel free to move this issue to whichever standards body makes the most sense to evaluate it.
The text was updated successfully, but these errors were encountered: