-
Notifications
You must be signed in to change notification settings - Fork 715
[css-text-3] Insufficient normative reference to UAX14 for the ID line breaking class #567
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Agenda+ing because this should be addressed in the disposition of comments for css-text-3. |
The proposed text looks like a partial copy of UAX 14, I think we should avoid copying the logic. I'm fine to say "ID must be honored", which I suppose should suffice your request, but I think @fantasai had a strong opinion on which class to include and which not to, so I'd like to see what she says. |
If "ID must be honored" is acceptable, I'd be OK with that. I was worried that it wouldn't be, because the rules in UAX14 that pertains to ID characters are not well contained, and defining the interaction between ID characters and other types of characters when they're adjacent pulls in a large part of the rest of the spec, and at the same time, that doesn't resolve all ambiguities, and yet still defines a specific behavior for kinsoku-shori, which is something we were trying to leave partly undefined, partly influenced by the line-break property. The text I proposed was an attempt to extract from UAX14 the key part of what makes line breaking for ID characters work the way it should, and defer the rest to the But if you think that's overkill or fragile, and that we can just point to UAX14 and require that ID line breaking be honored, then great. |
From the teleconf: Not normatively requiring UAX14 is intentional, because the rules are not only complex, but also not ideal. They are a good baseline, but not necessarily something that must be followed to the letter. The argument against inlining into our spec some simplified statements like the one I proposed is that including such rules would be a significant scope increase to css-text, and not one we are well equipped to handle. However, the spec does have a requirement that customary line breaking rules be followed. This is vague, but it is normative, and by group consensus can be used to justify certain obvious line breaking behaviors in tests, even if they are not explicitly spelled out individually in the spec. For instance, this is sufficient to expect wrapping opportunities between two kanji, and to depend on this in tests. I'll use this to simplify the tests I proposed in w3c/csswg-test#1135. |
Assuming that there are wrapping opportunities between ideographic characters allows a few tests to be simplified. Although this is not explicitly mentioned in the specification, it is still normatively required. See w3c/csswg-drafts#567 (comment) for rationale.
Css-text-3 refers normatively to UAX14 in a few places, including:
However, I cannot find any normative reference that requires the line-breaking behavior for characters with the line breaking class ID in UAX14 (Ideographic characters) to be honored, either directly or as part of a broader claim.
The 3rd and 4th bullets above suggest that it is expected, since something else is expected to behave like characters with that line breaking class, which doesn't make much sense if no particular behavior is expected of that class. Also, the design of the
break-word: normal
implicitly depends on this behavior being honored.The following paragraph in section 5 also indicates that this behavior is expected, but this sentence reads like informative prose, or at least seems too vague to be effectively testable.
The spec does (normatively) state that
and (informatively) that
and for sure, the full logic of where soft wrap opportunities should go is complex and impractical to specify, but without going into the full gory details of opening and closing punctuation and non-starter characters etc, it should be possible to ensure that at least the general case works out as expected.
I think we should add a bullet point to section 5.1 "Line breaking details. Maybe something like:
This still leaves some wiggle room since the
line-break
property itself doesn't define exhaustive rules, but I think this should give a decent baseline requirement.EDIT: typos
The text was updated successfully, but these errors were encountered: