W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2018

Re: [csswg-drafts] [css-text] cursive shaping breaks needs better scoping (#698)

From: fantasai via GitHub <sysbot+gh@w3.org>
Date: Fri, 07 Dec 2018 00:37:12 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-445081663-1544143029-sysbot+gh@w3.org>
>  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:

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

@r12a raised this request in the OP, but later retracted in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-295383826 and confirmed in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-387814460

<h4>2. Borders should not break shaping</h4>

@r12a raised this in the OP, reiterated in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-295383826 and https://github.com/w3c/csswg-drafts/issues/698#issuecomment-387814460
fantasai objects to borders being handled differently than margins and padding in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-407588131 and https://github.com/w3c/csswg-drafts/issues/698#issuecomment-429716817
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 https://github.com/w3c/csswg-drafts/issues/698#issuecomment-444700062 backed by Jonathan Kew's arguments in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-444467145
@r12a accepts that the 'outline' property is a sufficient substitute for his use cases for border in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-437944436 and verifies acceptance of the CSSWG decision in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-444904200

<h4>3. Spec should lock down when shaping occurs</h4>

@behnam asserts the spec is too lenient in not requiring shaping in all cases where it would make sense in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-297472304
@behdad requests in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-297543175 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 https://github.com/w3c/csswg-drafts/issues/698#issuecomment-387814460
@fantasai points out that all font changes need to be handled the same way in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-407588131 @svgeesus concurs in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-427797013
@fantasai reiterates the limitations of what shaping can do across font changes in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-427797013 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 https://github.com/w3c/csswg-drafts/commit/dfa85aadd56d7743341c2f3acf5d4a7fd65bb4f3#diff-2eb05d513690e5c4031fdea92fa32604
Current state of the spec text, fwiw, is https://www.w3.org/TR/css-text-3/#boundary-shaping

<h4>4. Allow explicit control over shaping isolation</h4>

@behnam requests explicit control over shaping isolation in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-297472304
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.

<h4>5. Initial letters should join to adjacent content</h4>

@behnam raised this in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-297472304
@r12a requests clarification in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-297693106
@beham confirms in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-297796468
@fantasai files https://github.com/w3c/csswg-drafts/issues/2399 to track this issue
@r12a complains that inline margin/border/padding is handled differently than initial letter margin/border/padding in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-438549364
@jfkthame requests the opposite behavior (that initial letters *not* join to adjacent content) in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-444470317
@fantasai copies @jfkthame's comment into https://github.com/w3c/csswg-drafts/issues/2399

<h4>6. Text decoration should not break shaping</h4>

@r12a proposes that the spec explicitly say that text decoration not break shaping
@fantasai accepts in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-387814460 and commits changeset https://github.com/w3c/csswg-drafts/commit/5b26dfb9655b7963b9809854b96d2028954fed63

<h4>7. Color changes within grapheme clusters</h4>

Side discussion on color changes within clusters (for various definitions of clusters) starts in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-429716817, continues in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-437944436, and gets pushed out to https://github.com/w3c/csswg-drafts/issues/699

<h4>8. :first-letter should not break shaping</h4>

(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 https://github.com/w3c/csswg-drafts/issues/698#issuecomment-387814460
@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 https://github.com/w3c/csswg-drafts/issues/698#issuecomment-429716817
@r12a seems confused about this point in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-437944436 @frivoal attempts to clarify in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-438541355 This thread continues in https://github.com/w3c/csswg-drafts/issues/698#issuecomment-438549364 and https://github.com/w3c/csswg-drafts/issues/698#issuecomment-444303748

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. :)

GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/698#issuecomment-445081663 using your GitHub account
Received on Friday, 7 December 2018 00:37:14 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:40 UTC