This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(from bug 23260) http://dev.w3.org/csswg/css-writing-modes > "In general, the paragraph embedding level is set according to the direction > property of the paragraph’s containing block rather than by the heuristic > given in steps P2 and P3 of the Unicode algorithm. That's non-normative (no MUST). And it doesn't use the HL* rules to define the override formally as the bidi spec requests. > [UAX9] When the computed > unicode-bidi of the paragraph’s containing block is plaintext, however, the > Unicode heuristics (rules P2 and P3) are used instead." That's non-normative (no MUST). > "If an inline element is broken around a bidi paragraph boundary (e.g. if > split by a block or forced paragraph break), then the bidi control codes > assigned to the end of the element are added before the interruption and the > codes assigned to the start of the element are added after it." That's non-normative (no MUST). Also it's vague — is "the bidi control codes assigned to the end" defined anywhere? Does it handle nested elements? How about bidi formatting codes that come from the block? (e.g. a block-level bdo) Overall, the spec's bidi integration should be changed to more formally refer to the HL* rules in the bidi spec, and to follow the bidi spec's rules on how to integrate a higher-level language with the bidi algorithm, and to make it clearer what is normative and what is merely informative.
(In reply to Ian 'Hixie' Hickson from comment #0) > > "If an inline element is broken around a bidi paragraph boundary (e.g. if > > split by a block or forced paragraph break), then the bidi control codes > > assigned to the end of the element are added before the interruption and the > > codes assigned to the start of the element are added after it." > > That's non-normative (no MUST). Also it's vague — is "the bidi control codes > assigned to the end" defined anywhere? Yes, the control codes are defined under the various unicode-bidi values in http://www.w3.org/TR/2013/WD-css-writing-modes-3-20131126/#unicode-bidi. But I agree that some sort of reference is needed. > Does it handle nested elements? Yes. If you have <span id="a" dir="ltr"><span id="b" dir="rtl"><br></span></span>, then both a and b are "broken around a bidi paragraph boundary", so the end control codes of both spans are added before the paragraph boundary, and the start codes of both are added after it. But it should define the order in which this should be done, just in case the reader does not feel like thinking for him or herself. > How about bidi formatting codes that come from the block? (e.g. a block-level > bdo) If a block-level element includes a bidi paragraph break, then each of its paragraphs has a paragraph direction as specified in the excerpt quoted above. No control codes are emitted for the paragraph direction (and the spec for embedded, isolate, and plaintext explicitly says that the control codes are only emitted for inline elements), so nothing needs to be closed and re-opened at a paragraph break inside a block-level element to get the paragraph direction. For unicode-bidi:bidi-override, the spec says "If the element is a block container, the override is applied to an anonymous inline element that surrounds all of its content", and thus the control codes for an anonymous bdo would be emitted at a paragraph break. Same thing for unicode-bidi:isolate-override, since that is specified as "combines the isolation behavior of isolate with the directional override behavior of bidi-override". I now realize, however, that the spec does not make it 100% clear for isolate-override whether it "combines" the isolate on the outside of the override or vice-versa. Obviously, the intent is to isolate on the outside of the override, but this should be specified explicitly.
Oh, as long as we are on this topic, let me add another small bidi spec fix needed in Writing Modes. In the opening paragraphs of http://www.w3.org/TR/2013/WD-css-writing-modes-3-20131126/#text-direction, the following sentence occurs: "Additionally, any such sequence forming part or all of the contents of a bidi-isolated inline element also forms a bidi paragraph." I believe that this sentence is left over from an earlier version of Writing Modes that indeed defined isolates as separate paragraphs. This is no longer the case, and this sentence should be removed.
Wrt the paragraph beginning "In general...", it has been revised: # In CSS, the paragraph embedding level must be set (following rule HL1) # according to the direction property of the paragraph’s containing # block rather than by the heuristic given in steps P2 and P3 of the # Unicode algorithm. There is, however, one exception: when the # computed unicode-bidi of the paragraph’s containing block is # 'plaintext', the Unicode heuristics in P2 and P3 are used as # described in [UAX9], without the HL1 override. Wrt referring to the HL* rules, the bidi spec does not appear to require such references, only that modifications to the algorithm conform to those rules. However I have added the references as you request to help clarify the intent. Wrt using "must" everywhere, whether you agree or disagree with the style, it is not a habit of the CSS specs to do so, and statements without the modifier are nonetheless normative per http://www.w3.org/TR/css3-writing-modes/#conventions > > is "the bidi control codes assigned to the end" defined anywhere? > > Yes, the control codes are defined under the various unicode-bidi > values [..] But I agree that some sort of reference is needed. Since this sentence is only a few paragraphs below the section that defines them, I haven't added a link. But all of them are now talking about rule HL3, so this will help create that correspondance. > I now realize, however, that the spec does not make it 100% clear for > isolate-override whether it "combines" the isolate on the outside of > the override or vice-versa. This is now specified explicitly. Comment #2 is handled separately, see thread at http://lists.w3.org/Archives/Public/www-style/2014Feb/0267.htm Updated ED: http://dev.w3.org/csswg/css-writing-modes/ Please let me know if this sufficiently addresses your comment.
Thanks, looks great! Just one nit: HL1 etc. are not rules. UAX9 referes to the HLs as "clauses". So, the references to them should be something like "clause HLx of [UAX9]".