[css-text] Hanging/collapsing of fixed-width spaces not specified #3879
Comments
|
Doing something like this could mean changing either or both of these sentences in 4.1.2 to cover more types of spaces, (maybe U+2000 to U+200A and U+205F)
Conceptually, that makes sense to me. |
|
There's like a million billion different flavors of spaces in Unicode. What was the reasoning for not including them since their inception? |
|
@litherum Legacy, I imagine. We can gather them up and call them by category Zs, fwiw. http://www.fileformat.info/info/unicode/category/Zs/list.htm Hanging Ogham Space Mark is a bit odd, though, since it's usually visible. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: Hanging/collapsing fixed-width spaces<fantasai> github: https://github.com//issues/3879 <fantasai> florian: Spaces ... <fantasai> florian: Currently only U+0020 and U+3000 are able to hang <fantasai> florian: But other fixed-width spaces don't <fantasai> florian: don't know if there was a specific reason not to include them, or some kind of oversight <fantasai> fantasai: I think we knew that nbsp couldn't hang <fantasai> fantasai: so we only had U+0020 hang <fantasai> fantasai: later on added ideographic space in response to feedback from Japan <fantasai> fantasai: Didn't re-evaluate other fixed-width space <fantasai> florian: Compat risk? <fantasai> fantasai: Probably low, most people don't know they exist <fantasai> fantasai: I'd be willing to change the spec and see how it goes <fantasai> fantasai: We'll need to except nbsp <fantasai> fantasai: also ogham space mark? <fantasai> florian: There's about whether spaces can hang at the end of the line in pre-wrap <fantasai> florian: separate question of whether they disappear when wrapping 'white-space: normal' <fantasai> florian: Not sure how to deal with ogham <fantasai> fantasai: will have to as i18n <fantasai> RESOLVED: fixed width spaces U+2000 and up are treated like U+0020 and U+3000 -- hang / disappear at end of line <fantasai> http://www.fileformat.info/info/unicode/category/Zs/list.htm |
I'm not disagreeing, but I don't understand that is special about nbsp that makes it necessary for it to be excepted. |
|
@briansmith It has a lot of legacy usage in holding space for various layouts, so changing its behavior is very risky from a Web-compat perspective. |
…estonly Automatic update from web-platform-tests [css-text] tests for css issue 3879 (#18273) See w3c/csswg-drafts#3879 -- wpt-commits: 4c93404d56218bb88f32b578ece7d47712952530 wpt-pr: 18273
…estonly Automatic update from web-platform-tests [css-text] tests for css issue 3879 (#18273) See w3c/csswg-drafts#3879 -- wpt-commits: 4c93404d56218bb88f32b578ece7d47712952530 wpt-pr: 18273
…estonly Automatic update from web-platform-tests [css-text] tests for css issue 3879 (#18273) See w3c/csswg-drafts#3879 -- wpt-commits: 4c93404d56218bb88f32b578ece7d47712952530 wpt-pr: 18273 UltraBlame original commit: ff2a357f450ebeccd8b745ea72476452743962cf
…estonly Automatic update from web-platform-tests [css-text] tests for css issue 3879 (#18273) See w3c/csswg-drafts#3879 -- wpt-commits: 4c93404d56218bb88f32b578ece7d47712952530 wpt-pr: 18273 UltraBlame original commit: ff2a357f450ebeccd8b745ea72476452743962cf
…estonly Automatic update from web-platform-tests [css-text] tests for css issue 3879 (#18273) See w3c/csswg-drafts#3879 -- wpt-commits: 4c93404d56218bb88f32b578ece7d47712952530 wpt-pr: 18273 UltraBlame original commit: ff2a357f450ebeccd8b745ea72476452743962cf
The definition of the various values of the white-space property in section 3 does not go into much detail about exactly how they work, and just provides a high level intro to what they do. The details are provided in section 4, and in particular 4.1 and 4.3 (so called “phase 1” and “phase 2” of white space processing). While this phase 2 has been updated (see w3c#2500 w3c#3879 w3c#4180) to define that not only space characters, but also other space separators hang / don't hang / wrap / don't wrap, etc, based on the value of the white-space property, the high level definition of these values was not updated to reflect that. While this is not necessarily a bug, as it is already called out that details are in section 4, apparent contradictions or omissions can be confusing. Therefore, in the part of these definitions that explicitly talked about white space wrapping/hanging (or not), include other space separators as well, as defined in 4.3.
https://www.w3.org/TR/css-text-3/#white-space-rules says "White space processing in CSS affects only the document white space characters: spaces (U+0020), tabs (U+0009), and segment breaks."
However, it is often/usually desirable for the collapsing/hanging behavior to apply to fixed-width spaces when the fixed-width space would cause a line break. Consider:
Which renders as:
The spaces on either side of the
+are U+205F Medium Mathematical Space and the spaces on either side of the=are U+2005. (This is the spacing recommended in http://www.unicode.org/notes/tn28 for these operators.)Lines wrap at fixed-width spaces already (at least in the browsers I tested). However, in the browsers I tested, these fixed-width spaces do not currently collapse or hang at the end of a line like U+0020. Either collapsing/hanging of these spaces like U+0020 should be the default behavior, or there should be some way to opt into them being treated like U+0020 for the purposes of collapsing/hanging.
The text was updated successfully, but these errors were encountered: