[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.