You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
text-spacing is getting very complicated now. By my count, the current grammar accepts 769 different combinations of values (770 if you count auto). It's probably worth an investigation to determine which of these combinations are actually useful.
I think that the text-spacing property is like a short hand property such as font-variant whose total number of combinations is very large and hard to reduce.
Here's the PrinceXML property in action. It finds a period followed by a space, and replaces it with a period followed by an em-space (U+2003). PDF of the result attached.
p.space {
prince-text-replace:". "".\2003";
}
This has lots of problems, not least because you can't define under what context the replacements happen.
How about considering splitting into multiple longhands? I recall that was the original plan of @fantasai when this property gets more matured?
As suggested in #4246 (comment), similar to font-variant, having multiple longhands allows authors to change one of them without changing other values, such as enabling/disabling just ideograph-numeric oly for some text, or disabling no-compress only for a span.
Doing so might also address #7183, and it looks like there's a mild consensus on in at TPAC. /cc @r12a
For implementers, testing the parser for the 770 combinations of values without errors is not an easy task. Splitting to multiple longhands and using the existing already-tested mechnism for shothand helps.
The JIS standard defines a set of character classes and their relationships in terms of a spacing range and compression/expansion priority, but there are problems with how these classes are defined (not differentiating between proportional/half-width/full-width for example) as well as no consideration of mixed script text. We need a modular approach that defines the character classes, the spacing ranges (with priority) of each class pairing, according to the needs of the UA and how fancy it wants to be when supporting complex layout. A reasonable default behavior could also be proposed as part of the jlreq, I would hope, so the spec could then be about a sparse override of the default.
Activity
frivoal commentedon Sep 10, 2019
There probably are a number of unnecessary combinations in there indeed. We should get help from JLReq to figure which ones are essential.
cc: @r12a @macnmm @fantasai @MurakamiShinyu
[-]text-spacing is very complicated[/-][+][css-text] text-spacing is very complicated[/+]MurakamiShinyu commentedon Sep 15, 2019
I think that the
text-spacingproperty is like a short hand property such asfont-variantwhose total number of combinations is very large and hard to reduce.litherum commentedon Sep 17, 2019
@dauwhe mentioned that Prince has something similar (
prince-text-replace?). Perhaps he has some insight into how to better design text-spacing.dauwhe commentedon Sep 17, 2019
Here's the PrinceXML property in action. It finds a period followed by a space, and replaces it with a period followed by an em-space (U+2003). PDF of the result attached.
This has lots of problems, not least because you can't define under what context the replacements happen.
prince-text-replace.pdf
kojiishi commentedon Dec 8, 2022
How about considering splitting into multiple longhands? I recall that was the original plan of @fantasai when this property gets more matured?
As suggested in #4246 (comment), similar to
font-variant, having multiple longhands allows authors to change one of them without changing other values, such as enabling/disabling justideograph-numericoly for some text, or disablingno-compressonly for a span.Doing so might also address #7183, and it looks like there's a mild consensus on in at TPAC. /cc @r12a
For implementers, testing the parser for the 770 combinations of values without errors is not an easy task. Splitting to multiple longhands and using the existing already-tested mechnism for shothand helps.
macnmm commentedon Jan 5, 2023
The JIS standard defines a set of character classes and their relationships in terms of a spacing range and compression/expansion priority, but there are problems with how these classes are defined (not differentiating between proportional/half-width/full-width for example) as well as no consideration of mixed script text. We need a modular approach that defines the character classes, the spacing ranges (with priority) of each class pairing, according to the needs of the UA and how fancy it wants to be when supporting complex layout. A reasonable default behavior could also be proposed as part of the jlreq, I would hope, so the spec could then be about a sparse override of the default.
litherum commentedon Jan 20, 2023
Agenda+ to discuss the possibility of splitting up the property into longhands (just like how we did with text-decoration-skip)
text-spacing is something we’d like to start implementing soon (weeks not months).
33 remaining items
Implement text-autospace parser for auto and no-autospace
[css-text-4] Redesign text-spacing
[css-text-4] insert not replace, is the default for text-autospace
fantasai commentedon Feb 28, 2023
OK, we've edited in the refactoring described in #4246 (comment) as resolved by the CSSWG, along with the suggestion to rename
trim-alltotrim-autoper @MurakamiShinyu's #4246 (comment).Follow-up issues filed:
trim-allvalue for handling number formatting etc.Please file additional follow-up issues if anything else needs fixing. Thanks!
[css-text-4] Add missing text-autospace:auto value #4246 #8512