This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11829 - parts of default stylesheet setting unicode-bidi and direction should be normative
Summary: parts of default stylesheet setting unicode-bidi and direction should be norm...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-21 06:41 UTC by Aharon Lanin
Modified: 2011-08-11 02:56 UTC (History)
10 users (show)

See Also:


Attachments

Description Aharon Lanin 2011-01-21 06:41:05 UTC
The default stylesheet section (http://dev.w3.org/html5/spec/Overview.html#the-css-user-agent-style-sheet-and-presentational-hints) is non-normative ("expected to be used"). However, the parts of it dealing with the bidi properties - unicode-bidi and direction - are not merely presentational in nature, but required for the correct rendering of the document's content. They should be broken out into a normative section.
Comment 1 KangHao Lu 2011-01-21 08:22:19 UTC
The rationale of this is to prevent bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=503957 . Now we have significant changes to the default style sheet because the introduction of the "isolate" value, to reach compat in maximum speed, it makes sense to have a section of default style sheet of "unicode-bidi" and "direction" for implementers to just copy and paste.

If for editorial reasons this is not doable, I think it's fine as long as the spec is clear that tests can be written for these default values.
Comment 2 Ian 'Hixie' Hickson 2011-02-16 09:05:26 UTC
The CSS rules can't really be normative, since the browser doesn't have to implement CSS at all, and even if it does, it doesn't really technically have to implement unicode-bidi to do the bidi stuff, it could just hard-code that behaviour.  If a browser _does_ implement CSS and unicode-bidi, then it is already required to put in the UA style sheet the rules in the spec, because if it doesn't then it will violate the other parts of the spec that says how these bidi features work, as far as I can tell.
Comment 3 KangHao Lu 2011-02-16 16:54:59 UTC
(In reply to comment #2)
> If a browser _does_ implement CSS and unicode-bidi, then it is
> already required to put in the UA style sheet the rules in the spec, because if
> it doesn't then it will violate the other parts of the spec that says how these
> bidi features work, as far as I can tell.

Let me try to pull the bits here. I am probably missing something so any help is appreciated.

3.2.3.5 The dir attribute

The effect of this attribute is primarily on the presentation layer. For example, the rendering section in this specification defines a mapping from this attribute to the CSS 'direction' and 'unicode-bidi' properties, and CSS defines rendering in terms of those properties.

3.2.6 doesn't mention anything about CSS and extra characters imposed by having the dir attribute, etc.

4.6.22 The bdi element

This is the place where the 'unicode-bidi: isolate' algorithm is specified.

== Problem ==

In HTML4, there was a sentence:

[[
When a block element that does not have a dir attribute is transformed to the
style of an inline element by a style sheet, the resulting presentation should
be equivalent, in terms of bidirectional formatting, to the formatting obtained
by explicitly adding a dir attribute (assigned the inherited value) to the
transformed element.
]]

This was not implementable and later on an modified approach was taken (giving several elements 'unicode-bidi: embed' as default) by Mozilla (see the bug in comment #1).

They are changed to 'unicode-bidi: isolate' in the current draft. While rules for the dir attribute and the bdi elements are more or less implied by the sentences listed above, as far as I can tell, the current spec does not have a sentence corresponding to 'li { unicode-bidi: isolate; }' and similar rules.

Is it possible to say, *if* the browser supports CSS and 'unicode-bidi', here's a normative section of CSS rules? Or perhaps you just want to write a sentence that unambiguously implies these rules.
Comment 4 fantasai 2011-02-16 17:36:06 UTC
No, it's not about whether the browser supports CSS. The issue here, if I'm interpreting Aharon correctly, is that even if the browser does not support this CSS, it should still be required to handle the bidi controls in HTML -- i.e. these requirements, though part of the presentation layer, should be normative for any UA that has a presentation layer, whether or not the implementation supports the relevant CSS controls.
Comment 5 Aharon Lanin 2011-02-16 17:59:40 UTC
(In reply to comment #4)

Yes, that is a good formulation of the problem.
Comment 6 KangHao Lu 2011-02-16 18:32:39 UTC
(In reply to comment #4)
> No, it's not about whether the browser supports CSS. The issue here, if I'm
> interpreting Aharon correctly, is that even if the browser does not support
> this CSS, it should still be required to handle the bidi controls in HTML --
> i.e. these requirements, though part of the presentation layer, should be
> normative for any UA that has a presentation layer, whether or not the
> implementation supports the relevant CSS controls.

The question is how far we want to do it. For example, I assume we want to fix the list of elements that have 'unicode-bidi: isolate' as default for compat, but I can see editorial difficulty if we want to write this down as CSS-independent natural sentence. Perhaps the editor can think of a way.
Comment 7 Ian 'Hixie' Hickson 2011-05-04 20:25:15 UTC
As far as I can tell, we already require the behaviours that the CSS properties imply, e.g.:

"If the element's dir attribute is in the rtl state, then for the purposes of the bidirectional algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element."
"If the element's dir attribute is in the ltr, then for the purposes of the bidirectional algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element."
"A br element should separate paragraphs for the purposes of the Unicode bidirectional algorithm."
"A newline in a textarea element, and in its raw value, should separate paragraphs for the purposes of the Unicode bidirectional algorithm."

...etc.

Isn't that sufficient?
Comment 8 Aharon Lanin 2011-05-05 08:10:02 UTC
(In reply to comment #7)

Thinking through all this again, I now see that the problem is even bigger than I originally realized.

The excerpts quoted in comment 7 are taken from descriptions of the <bdo> element and the <br> element. The comment also refers to specs on the <bdi> element. *None of these* apply to the elements that used to be called block elements in HTML4. *At no point does the current HTML spec define the role of these elements in breaking the text of the document into paragraphs for the purposes of the Unicode Bidirectional Algorithm.* The role of <br> (and newlines in <textarea>) in this matter is now defined (in the sections quoted above), but the role of a <div>, <p>, etc. is not.

Paragraph breaks have a crucial effect on bidi text, so the absence of a complete spec for them in HTML is highly problematic.

Nor does the spec how these elements affect the bidirectional algorithm when their "block" nature is modified by something outside HTML, e.g. a stylesheet.

In HTML4 there is an attempt at such a spec in <http://www.w3.org/TR/html401/struct/dirlang.html#h-8.2>. Here are the most relevant sections:

"The Unicode bidirectional algorithm requires a base text direction for text blocks. To specify the base direction of a block-level element, set the element's dir attribute."

"When an inline element that does not have a dir attribute is transformed to the style of a block-level element by a style sheet, it inherits the dir attribute from its closest parent block element to define the base direction of the block."

"When a block element that does not have a dir attribute is transformed to the style of an inline element by a style sheet, the resulting presentation should be equivalent, in terms of bidirectional formatting, to the formatting obtained by explicitly adding a dir attribute (assigned the inherited value) to the transformed element."

This part of the HTML4 spec was far from perfect, but at least it was something. As far as I know, it is completely missing in the current spec, with the single exception of the unicode-bidi:isolate on the what-used-to-be-called-block elements in the default stylesheet.

The bidi paragraph role of the blocks is currently only completely spelled out in the CSS spec. Thus, in the CSS3 Writing Modes module, we have:

- User agents that support bidirectional text must apply the Unicode bidirectional algorithm to every sequence of inline boxes uninterrupted by a forced (bidi class B) paragraph break or block boundary. This sequence forms the paragraph unit in the bidirectional algorithm.

- If [an inline element has unicode-bidi:embed, it] opens an additional level of embedding with respect to the bidirectional algorithm. The direction of this embedding level is given by the direction property. Inside the element, reordering is done implicitly. This corresponds to adding a LRE (U+202A), for direction: ltr, or RLE (U+202B), for direction: rtl, at the start of the element and a PDF (U+202C) at the end of the element.

- 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 corresponding to the end of the element are added before the interruption and the codes corresponding to the start of the element are added after it. (In other words, any embedding levels or overrides started by the element are closed at the paragraph break and reopened on the other side of it.)

I believe that the role of what-used-to-be-called-block elements in determining the bidi paragraphs needs to be spelled out in the HTML5 spec, for the sake of user agents that do not implement CSS, and for the sake of clarity.

By this role, I mean:

- Normally, a "block" element's boundaries form paragraph boundaries for the purposes of the bidirectional algorithm. Thus, in <div>A<div>B</div>C</div>, each of A, B, and C are, by default, separate UBA paragraphs. The base direction of these paragraphs is specified by their respective containing elements' directionality.

- When, by some extra-HTML mechanism (e.g. "display:inline" or "display:inline-block" in a stylesheet), a "block" element ceases to act as a block boundary between the content preceding and following it, user agents should treat it for the purposes of the bidirectional algorithm exactly as specified for the <bdi> element, except that its directionality must default to that of its parent.

- When the dir attribute is present on an element that does not act as a block boundary, it opens an additional level of embedding with respect to the bidirectional algorithm. That is, for the purposes of the bidirectional algorithm, the user agent must act as if there was a U+202A LEFT-TO-RIGHT EMBEDDING character at the start of such an element with ltr directionality, a U+202B RIGHT-TO-LEFT EMBEDDING character at the start of such an element with rtl directionality, and a U+202C POP DIRECTIONAL FORMATTING at the end of such an element.

- When an element that does not act as a block boundary is interrupted by a bidi paragraph boundary (e.g. contains a "block" element or <br>), then the bidi control codes, if any, corresponding to the end of the element are added before the interruption and the codes, if any, corresponding to the start of the element are added after after the interruption. (In other words, any embedding levels or overrides started by the element are closed at the paragraph break and reopened on the other side of it.)
Comment 9 Ian 'Hixie' Hickson 2011-05-08 00:29:39 UTC
I can add a normative subsection to the rendering section that applies to visual UAs that don't implement CSS, and says what the default rendering in bidi terms should be, sure.
Comment 10 Aharon Lanin 2011-07-14 15:00:33 UTC
(In reply to comment #9)
> I can add a normative subsection to the rendering section that applies to
> visual UAs that don't implement CSS, and says what the default rendering in
> bidi terms should be, sure.

If this was really a question asking whether that is what I want, then the answer is yes, that would be great.
Comment 11 Martin Dürst 2011-07-15 02:04:16 UTC
(In reply to comment #9)
> I can add a normative subsection to the rendering section that applies to
> visual UAs that don't implement CSS, and says what the default rendering in
> bidi terms should be, sure.

I agree that this is the right way to go. I think this could be as simple as saying something like "If you don't implement bidi CSS, then you still have to implement rendering as if you implemented bidi CSS with the bidi parts from the default stylesheet fixed.".

[In RFC 2070, we also had a way out for implementations that didn't want to implement bidi at all; that was allowed if an implementation didn't display RTL scripts. But I'm not sure this is still needed/appropriate.]
Comment 12 Michael[tm] Smith 2011-08-04 05:04:02 UTC
mass-moved component to LC1
Comment 13 Ian 'Hixie' Hickson 2011-08-11 02:55:43 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

Instead of repeating the whole rendering section in different words for non-CSS UAs, I've just added a paragraph saying non-CSS UAs still have to apply the default rules if they want to classify as "supporting the suggested default rendering" (which is now a conformance class, by the way, so you can write tests for it without having to worry about the section not being normative and whatnot).
Comment 14 contributor 2011-08-11 02:56:46 UTC
Checked in as WHATWG revision r6415.
Check-in comment: Require non-CSS UAs to honour the default style sheet too.
http://html5.org/tools/web-apps-tracker?from=6414&to=6415