Open mnater opened 4 years ago
I'm not sure I understand completely.
Do you mean: if the author has inserted soft-hyphens into a word, that those soft-hyphens shouldn't be used as hyphenation points if they would violate the limits created by the hyphenate-limit-lines
and hyphenate-limit-last
properties?
If so, I think that's what the specification is already saying. Those two properties simply talk about limits on hyphenation - there's no distinction made about why the hyphenation occurred.
Do you mean: if the author has inserted soft-hyphens into a word, that those soft-hyphens shouldn't be used as hyphenation points if they would violate the limits created by the hyphenate-limit-lines and hyphenate-limit-last properties?
Yes. Thanks for rephrasing.
If so, I think that's what the specification is already saying. Those two properties simply talk about limits on hyphenation - there's no distinction made about why the hyphenation occurred.
Yeah, that's right. But as long as the other property has this note, you could interpret this to mean that this only applies to automatic hyphenation.
The same could be useful for the following rules:
hyphenate-limit-lines hyphenate-limit-last
(but not for hyphenate-limit-zone or hyphenate-limit-chars).
My interpretation of the spec is that it would be true for all 4 of these properties, not just the first two.
Were you treating the first two differently form the last two because something in the spec made you think that was the case, or based on how you want to use them? More details would be very helpful.
My interpretation of the spec is that it would be true for all 4 of these properties, not just the first two.
The note specific to hyphenate-character
made me think, these rules apply only to automatic hyphenation and not to hyphenation triggered by soft hyphens.
Were you treating the first two differently form the last two because something in the spec made you think that was the case
No, I haven't thought it through. Of course it makes sense if all the rules apply to both sorts of hyphenation.
The same could be useful for the following rules: hyphenate-limit-lines hyphenate-limit-last (but not for hyphenate-limit-zone or hyphenate-limit-chars).
My interpretation of the spec is that it would be true for all 4 of these properties, not just the first two.
Were you treating the first two differently form the last two because something in the spec made you think that was the case, or based on how you want to use them? More details would be very helpful.
As currently written, the draft spec doesn't explicitly say whether it's referring to manual or automatic hyphens (except for the note on hyphenate-character
calling out that it applies to both); perhaps it intends all these properties to apply to both kinds of hyphenation, but I think there's a reasonable case for saying that -- at least in the case of limit-chars
-- the intent is to control the UA's automatic hyphenation behavior, but if an author inserts explicit manual soft hyphens, we should assume they're deliberately diverging from the automatic behavior and so these limits are not relevant.
So I might say hyphenate-limit-chars: 6 3 3
to prevent auto-hyphenation breaking short words. But if I then include ex­pect
in my text, I expect the explicit soft hyphen to override what auto-hyphenation would do, and provide a possible break "ex-/pect" as an exception to the rules that are otherwise in effect.
hyphenate-limit-lines
, hyphenate-limit-last
and hyphenate-limit-zone
are about where the break falls as part of the overall layout, not about where the break occurs within the character stream, and so it probably makes sense for them to apply to both auto and manual hyphenation points. But hyphenate-limit-chars
is about where breaks are allowed within the character stream. I see hyphenate-limit-chars
as being essentially a parameter to tune the auto-hyphenation behavior, but ­
is an explicit manual control that is expected to take precedence over automatic behavior, so should not be subject to its parameters.
I agree with @jfkthame - the point made here and in #5157 is that manual hyphens inserted by the user should override everything else, which I agree that's the right approach. hyphenate-limit-chars
shouldn't have any impact on soft-hyphens, but the other three properties apply to all types of hyphenation opportunity.
I'm not convinced and I don't agree.
Let's imagine what it could look like in ten years if browsers supported these features: One browser (let's call it LavaLion) supports automatic hyphenation for almost all languages, the other browser (Quicksilver) can only hyphenate a few languages automatically. Web developers use a JavaScript library to insert soft hyphens in Quicksilver for unsupported languages.
If, as suggested here, some CSS properties only apply to automatic hyphenation, users will need to define their style settings in two places (CSS and JavaScript). If, on the other hand, the CSS properties apply to manual AND automatic hyphenation, the user can define these settings in one place (CSS) and it doesn't matter whether the possible hyphenation points come from automatic hyphenation or were marked by soft hyphens.
You could also put it like this: the "hyphenator" (be it a hyphenation algorithm or a user who inserts soft hyphens) specifies possible hyphenation points, the CSS properties define a style, which of these possible hyphenation points may be used.
There's a note in https://drafts.csswg.org/css-text-4/#hyphenate-character saying
The same could be useful for the following rules:
hyphenate-limit-lines
hyphenate-limit-last
(but not for
hyphenate-limit-zone
orhyphenate-limit-chars
).