[css-text] cursive shaping breaks needs better scoping

[r12a]

8.3. Shaping Across Element Boundaries
https://drafts.csswg.org/css-text/#boundary-shaping

previous discussion on this topic can be found at:
http://www.w3.org/Mail/flatten/index?subject=Arabic+letters+connecting+between+elements+with+display%3A+inline&list=www-style

Text shaping should not be broken across inline box boundaries otherwise, if it is reasonable and possible for that case given the limitations of the font technology.

I think this is too broad. I created a set of tests for arabic script text at
https://w3c.github.io/i18n-tests/results/css-text-shaping (click on the link in the left column to see the test run)

The results show that no browser tested maintains the joining behaviour where font-weight and font-style and font-size are different. (Red appears because the spec currently implies that those shouldn't break the cursive shaping.) Those should probably be added to the list of styles that break the text shaping. Either that, or it may be simpler to list styling that should not break shaping.

Note also that a border doesn't break the joining behaviour in Firefox and Edge. This perhaps seems like reasonable behaviour for highlighting items, and i wonder whether we should drop that from the list of things that break shaping? I suppose the argument (as for margins and padding) is that this might have been a block element that has been added inline. It seems a pity, however, that such a possibility would rule out the ability to put a border around one character in a cursive sequence using inline markup when wanted.

[fantasai]

Are you arguing that shaping shouldn't, on principle, be applied across changes in font weight/style/size, or that because this is not implemented it should be considered a spec bug and not an implementation bug?

We definitely should be maintaining shaping across font family changes, fwiw, simply because that's a font fallback issue.

[r12a]

Trying to remember what i was thinking back then. Coming to it fresh, i also wonder why i suggested that changes in font weight/style/size should break the shaping.

I'm now thinking that we should probably call out at least the more obvious things we believe should not break the shaping, to improve consistency across browsers. And i guess i'd include font weight/style/size in that list, as well as non-zero width borders and font-family.

[behnam]

From https://drafts.csswg.org/css-text-3/#boundary-shaping

Text shaping should not be broken across inline box boundaries otherwise, if it is reasonable and possible for that case given the limitations of the font technology.

Although it's a good start, but the "if it is reasonable and possible for that case given the limitations of the font technology" part apparently makes it a matter of choice again and leaves a lot of room for inconsistency between implementations, and eventually, as a result of the inconsistencies, users not being able to rely on it.

Regarding "joining context" of elements, has it been discussed to allow user to control it for inline elements, with options to isolate the element regarding joining or absorb context from surrounding?

Why I think explicit method is better than implicit is that there exist cases that the element can have a margin/border/padding and also a non-baseline vertical alignment, and still the joining context should be preserved, for example, "drop caps" for Arabic.

Here's an example of a drop caps being applied without proper joining context for either the first letter or the rest of the word:

Example is from this discussion: https://groups.google.com/forum/#!topic/persian-computing/W-Upl6DAEcg

[behdad]

I agree it would be good to call out property changes that MUST NOT break shaping. For the rest (font change), I like to still suggest the correct behavior, even if no implementation does it currently. FWIW, the layout-ng rewrite effort in Chrome is going to fix that. That has been one of the design goals.

[r12a]

@behnam, just to be sure i'm clear, i think you saying that the paragraphs should start with

rather than what is shown in your picture. Is that right?

[behnam]

That's correct, @r12a. For both cases.

[fantasai]

Filed #2399 about drop-caps.

Fwiw, the current text is the result of discussions in the thread at https://lists.w3.org/Archives/Public/www-style/2014Aug/0217.html which would be worth a read. I agree that there's no excuse to break Arabic joining in #2; I would find that unreasonable, and therefore a spec violation, but I suppose we can make it more explicit. :)

[fantasai]

Possible edits: add the following note

Note: The correct choice of joining forms in Arabic (initial, medial, final, isolated) is always reasonable and possible; even given no support in the text rendering back-end, the UA can always pass in strings marked up with U+200D Zero Width Joiner.

Open to suggestions/comments, but only from people who have read the thread linked above. ;)

[r12a]

Here's an easier to read version of the thread mentioned by @fantasai
https://www.w3.org/Mail/flatten/index?subject=Shaping+Isolation+and+Layout+Separation+of+Inlines&list=+www-style

[r12a]

Based on the classification in the thread @fantasai pointed to, here's a first proposal:

1. (must not break shaping) includes: change to colour, border, font-weight, font-style, text-decoration, first-letter styling
2. (should not break, if possible) includes: font-size, font-family
3. (must break) includes: one of margin/padding are non-zero, baseline change, isolation boundary

[palemieux]

Is this related to https://bugs.webkit.org/show_bug.cgi?id=6148 ?

[fantasai]

@r12a Font changes should all be handled as a single category, and same with margin/border/padding.

[css-meeting-bot]

The Working Group just discussed cursive shaping breaks needs better scoping.

The full IRC log of that discussion

<dael> Topic: cursive shaping breaks needs better scoping
<dael> github: https://github.com//issues/698
<dael> Rossen: Who wants this? fantasai ?
<dael> fantasai: This was from F2F. Not sure ther's anything to talk about. Trying to figure out what to put. There was a lot of pushback when first drew up text to not being specific enough. There's a lot about shaping like Arabic doesn't need a lot of assistance like more complex scripts
<dael> fantasai: Issues is b/c there's a certain amount of shaping you can do across font changes. In terms of what edits need to be made brings in a q as to how to handle other aspects of glyph shaping.
<dael> fantasai: I don't know enough about this to figure out the issue. There's a long thread. I'd appreciate help from someone who knows more about this topic.
<dael> myles: I can take a look. I have some opinions but no proposal. I can come up with something for next call
<dael> fantasai: That's all on this one. I need help.
<dael> Rossen: I'll get our fonts people to look and comment and ideally we can resolve on github and put on agenda for resolution.

[r12a]

If you want to draw a box around a character without affecting anything, use 'outline' instead.

i was unaware of the outline property (!). Ok then.

A color change partway through a ligature is not likely to work out....

Sure, there are things that are more difficult, and content authors are not likely to try mark colouring, if it doesn't work for those, but it can still be useful in many situations. [text & image removed here, because it belonged in a different issue]

The third case, :first-letter should be treated the same as any other inline box, and should already be covered by this statement: "Text shaping must not be broken across inline box boundaries when there is no change in formatting."

I begin to wonder what is the meaning of 'change in formatting' if first-letter styling doesn't result in any?? What would be the point in using first-letter unless it changed the formatting? Can you make that clearer?

[frivoal]

Using ::first-letter to change the formatting would do so. But merely selecting something with first letter shouldn't do anything, just like merely putting a span around something shouldn't.

So, if you put ::first-letter { text-transform: uppercase; } on some arabic text, it doesn't affect the formatting, since arabic is unicameral, and it isn't allowed to break letter shaping.

[r12a]

Sure, i understand that, but the example you give is not a particularly useful thing to do. I suspect that much of the time one will apply first-letter in order to change the formatting (see the image at #698 (comment)).

We have https://drafts.csswg.org/css-inline-3/#initial-letter-shaping saying that

When initial-letters is not normal, shaping should still occur across an inline initial letter box’s boundaries. ... For example, if the first letter of the Farsi word “پس” were styled with initial-letters: 2 1, both letters would be styled in their joined forms, with initial-form “ﭘ” as the initial letter, followed by the normally-styled final-form “ﺲ”. Note that the two letters might not always graphically connect, even when shaped in their joining forms. (my emphasis)

But we have https://drafts.csswg.org/css-text/#boundary-shaping saying that

Text shaping must be broken at inline box boundaries when any of the following are true for any box whose boundary separates the two typographic character units: Any of margin/border/padding separating the two typographic character units in the inline axis is non-zero. ...

The two things seem to be contradictory, or at least to warrant some additional explanation.

[fantasai]

@r12a

Sure, i understand that, but the example you give is not a particularly useful thing to do. I suspect that much of the time one will apply first-letter in order to change the formatting

Well, yes. But we still have to define what happens in all cases. This is a Web Platform spec after all. :)

Wrt initial-letter vs regular inlines, were were made aware that the specific requirements around initial letter formatting that requires shaping across that boundary, so that's explicitly specced. Initial letter formatting is a specialized form of layout, and is different form inline layout. (I also want to point out that initial letter styling and :first-letter styling are not the same thing. Initial letter styling can be applied to spans, and :first-letter elements are just like spans and not like initial letters unless they're explicitly styled as initial letters.)

Agenda+ to ask the WG if we should have margins/borders/padding not affect shaping in regular inlines, as Firefox now appears to do. @jfkthame Any opinions? testcase

[jfkthame]

The WG decided several years ago that non-zero margins/borders/padding should interrupt shaping at inline boundaries; the fact that Firefox currently applies shaping across these is simply a Gecko bug and we should fix it. (I thought I had an experimental patch for this somewhere, even; maybe I can resurrect it.)

[fantasai]

@jfkthame Right, but @r12a seems to be challenging that decision so wanted to ask your opinion.

[jfkthame]

@jfkthame Right, but @r12a seems to be challenging that decision so wanted to ask your opinion.

IIUC, this was mostly about font-related properties (size, weight, etc); he then mentioned border as well:

Note also that a border doesn't break the joining behaviour in Firefox and Edge. This perhaps seems like reasonable behaviour for highlighting items, and i wonder whether we should drop that from the list of things that break shaping? I suppose the argument (as for margins and padding) is that this might have been a block element that has been added inline. It seems a pity, however, that such a possibility would rule out the ability to put a border around one character in a cursive sequence using inline markup when wanted.

but the hypothetical use-case suggested here would be better served by outline, IMO.

I think the properties that introduce visual separation between the adjacent elements (so any of margin/border/padding at the relevant side) should indeed interrupt shaping, and I've seen sites where the current Firefox behavior of shaping across such gaps results in broken rendering. People do things like navigation or menu bars across a page:

<div class="nav"><a>home</a><a>away</a></div>

and apply margins to the <a> elements to spread them across the line, and when Firefox applies shaping across the resulting gaps, the result looks terrible. (I don't have a bug number to hand but we've had real-world reports of this.)

[jfkthame]

Sure, i understand that, but the example you give is not a particularly useful thing to do. I suspect that much of the time one will apply first-letter in order to change the formatting (see the image at #698 (comment)).

We have https://drafts.csswg.org/css-inline-3/#initial-letter-shaping saying that

When initial-letters is not normal, shaping should still occur across an inline initial letter box’s boundaries. ... For example, if the first letter of the Farsi word “پس” were styled with initial-letters: 2 1, both letters would be styled in their joined forms, with initial-form “ﭘ” as the initial letter, followed by the normally-styled final-form “ﺲ”. Note that the two letters might not always graphically connect, even when shaped in their joining forms. (my emphasis)

But we have https://drafts.csswg.org/css-text/#boundary-shaping saying that

Text shaping must be broken at inline box boundaries when any of the following are true for any box whose boundary separates the two typographic character units: Any of margin/border/padding separating the two typographic character units in the inline axis is non-zero. ...

The two things seem to be contradictory, or at least to warrant some additional explanation.

If the first letter is styled with a different font-size, font-family, etc it's entirely possible it won't actually connect to the next letter even when the appropriate contextual forms are used; I think that's what the emphasized sentence above is pointing out.

Adding margin or border around the letter, OTOH, would be a cause for not shaping between the initial letter and following text.

Raised caps are an interesting edge case, where I guess it's reasonable to maintain joining as the baseline isn't changed and no horizontal separation is being introduced (though it seems an unlikely thing for someone to really want to do in such a script).

The few examples I've seen of traditional practice (see #698 (comment) and the linked discussion) don't appear to support shaping across more general drop-cap-like formatting: the large dropped, boxed initial in https://upload.wikimedia.org/wikipedia/commons/6/6a/Hafezeshamlu02.jpg, for example, is not shaped in an initial form.

[css-meeting-bot]

The CSS Working Group just discussed cursive shaping breaks needs better scoping, and agreed to the following:

• RESOLVED: Close issue #698 no shaping across positive margin/border/padding

The full IRC log of that discussion

<dael> Topic: cursive shaping breaks needs better scoping
<dael> github: https://github.com//issues/698#issuecomment-437944436
<dael> Rossen: Reopened a couple weeks ago.
<dael> fantasai: This was an issue where Richard asked us to clarify or change where we have breaks across element boundries or not. I think he was asking for it to not break when there's a border. There's a span mid-word. Current spec requires if you have border, margin, or padding we don't shape across that boundry
<dael> fantasai: Richard asked to have that changed. Asked Jonathan for his opinion and that FF does that is a problem. We're keeping current set of rules is that latest on the issue
<dael> fantasai: Wanted to ask if there's anyting to add. If not I'll close editorial for clarifications, but no change
<dael> Rossen: I support the no change. Change would be nontrivial and i'm not sure how it would impact web compat.
<dael> Rossen: Objections?
<dael> RESOLVED: Close issue #698 no change

[fantasai]

Closing out as a mix of Editorial and Wontfix per #698 (comment) and WG resolution supporting @jfkthame's position that margin/border/padding should break shaping across boundaries.

Wrt #698 (comment) about shaping initial letters, re-opening #2399 and copying over @jfkthame's comment.

@r12a If you want something changed here or would like to object to the resolution, please open a new issue. This one has turned into issue salad.

[r12a]

@jfkthame Right, but @r12a seems to be challenging that decision so wanted to ask your opinion.

Not correct. @jfkthame said earlier

The WG decided several years ago that non-zero margins/borders/padding should interrupt shaping at inline boundaries;

(my emphasis) which is fine by me. I was only suggesting that zero m/b/p should not interrupt, but i think i'm fine breaking for any m/b/p – particularly now that i know that the outline property can be used for drawing around things. (see above)

The i18n WG will keep our tracker issue open until we've seen the edited text. Btw, it would be nice if you could briefly summarise the conclusions reached (preferably before closing the issue), wrt the other aspects.

PS: Please don't open another issue to continue this discussion. Apart from a small but mostly relevant digression into first-letter, i don't see any salad. The really useful thing about github issue threads is that you don't have to go chasing all over the place to find the discussion about a particular topic/request.

[fantasai]

I was only suggesting that zero m/b/p should not interrupt, but i think i'm fine breaking for any m/b/p

Unfortunately, due to some historical decisions made back in the 90s, we can't distinguish between zero m/b/p and no m/b/p, so indeed zero m/b/p will not interrupt because it's the default case. :P

i don't see any salad

Heh. Here, I'll sort it into piles for you so you can see how many different issues have been raised in this thread:

1. font-weight / font-style / font-size changes should break shaping

@r12a raised this request in the OP, but later retracted in #698 (comment) and confirmed in #698 (comment)

2. Borders should not break shaping

@r12a raised this in the OP, reiterated in #698 (comment) and #698 (comment)
fantasai objects to borders being handled differently than margins and padding in #698 (comment) and #698 (comment)
CSSWG had resolved that non-zero margins/borders/padding must break shaping in http://www.w3.org/2014/09/08-css-irc#T08-02-24. CSSWG re-resolves that non-zero margins/borders/padding break shaping in #698 (comment) backed by Jonathan Kew's arguments in #698 (comment)
@r12a accepts that the 'outline' property is a sufficient substitute for his use cases for border in #698 (comment) and verifies acceptance of the CSSWG decision in #698 (comment)

3. Spec should lock down when shaping occurs

@behnam asserts the spec is too lenient in not requiring shaping in all cases where it would make sense in #698 (comment)
@behdad requests in #698 (comment) that the spec call out changes which must not break shaping; the spec already tries to do this to the extent it can without listing all CSS properties which would be an extremely long and increasingly incomplete list. @bedad also requests that in other cases the correct behavior is suggested; the spec also does this already.
@fantasai points out that “shaping” is a much broader topic than the choice of isolated/initial/medial/final forms in Arabic and that the current spec text is the result of discussions in thread at https://lists.w3.org/Archives/Public/www-style/2014Aug/0217.html (consolidated view at https://www.w3.org/Mail/flatten/index?subject=Shaping+Isolation+and+Layout+Separation+of+Inlines&list=+www-style )
@r12a proposes list at #698 (comment)
@fantasai points out that all font changes need to be handled the same way in #698 (comment) @svgeesus concurs in #698 (comment)
@fantasai reiterates the limitations of what shaping can do across font changes in #698 (comment) and points out that breaking Arabic shaping would be a spec violation even under the current intentionally-not-entirely-deterministic text. Adds examples to the spec in dfa85aa#diff-2eb05d513690e5c4031fdea92fa32604
Current state of the spec text, fwiw, is https://www.w3.org/TR/css-text-3/#boundary-shaping

4. Allow explicit control over shaping isolation

@behnam requests explicit control over shaping isolation in #698 (comment)
This point was missed in the replies, but the answer there is that unicode-bidi: isolate can already enforce isolation (usually the desire for shaping isolation will coincide with the desire for bidi isolation). So far we haven't see any strong use cases for either a) an independent switch to trigger isolation b) a switch to enforce joining across a boundary where we're currently requiring a break. Hence, my conclusion is no change to the specs for this point.

5. Initial letters should join to adjacent content

@behnam raised this in #698 (comment)
@r12a requests clarification in #698 (comment)
@beham confirms in #698 (comment)
@fantasai files #2399 to track this issue
@r12a complains that inline margin/border/padding is handled differently than initial letter margin/border/padding in #698 (comment)
@jfkthame requests the opposite behavior (that initial letters not join to adjacent content) in #698 (comment)
@fantasai copies @jfkthame's comment into #2399

6. Text decoration should not break shaping

@r12a proposes that the spec explicitly say that text decoration not break shaping
@fantasai accepts in #698 (comment) and commits changeset 5b26dfb

7. Color changes within grapheme clusters

Side discussion on color changes within clusters (for various definitions of clusters) starts in #698 (comment), continues in #698 (comment), and gets pushed out to #699

8. :first-letter should not break shaping

(Note that :first-letter styling is not synonymous with initial letter formatting. :first-letter styling is the styling of an inline box (similar to a span) which is automatically generated around the first letter of a paragraph. Initial letter styling is a type of special formatting--effectively a different display type--that is sometimes but not exclusively applied to :first-letter pseudo-elements.)

@r12a asserts that :first-letter should not break shaping in #698 (comment)
@fantasai points out that whether :first-letter breaks or does not break shaping depends on the style rules applied to the :first-letter, and that this behavior is already defined since it is (per spec) identical to the requirements applied to any other inline element (such as a SPAN), see #698 (comment)
@r12a seems confused about this point in #698 (comment) @frivoal attempts to clarify in #698 (comment) This thread continues in #698 (comment) and #698 (comment)

Essentially this sub-issue is invalid. I suppose I can add a “Closed as Invalid” tag to the soup here.

---

As we can see here, there are at least 8 separate sub-issues discussed in this issue. I think I'm thoroughly justified in calling it an issue salad. :)

[r12a]

I guess it depends on the vantage-point of the reader. For me, those are all just facets of the discussion that addresses the original comment, where i was asking, essentially "what things should or shouldn't break cursive joining behaviour". It wasn't just about border.

So the summary appears to be that which is currently stated in the spec as of https://www.w3.org/TR/2018/WD-css-text-3-20181206/#boundary-shaping. Good.

[fantasai]

And a salad is just a single dish, but the chef still has to prep each ingredient independently. ;) OK, then, closing out as Commenter Satisfied!

Note: Initial letter discussion continues in #2399 Current status of that issue is that @behnam and @jfkthame are arguing for opposite behavior, so we're going to need some help sorting it out. :)