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 11734 - Document the special effect of dir=auto on <pre> and <textarea>
Summary: Document the special effect of dir=auto on <pre> and <textarea>
Status: CLOSED NEEDSINFO
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-11 13:35 UTC by Aharon Lanin
Modified: 2011-08-04 05:14 UTC (History)
8 users (show)

See Also:


Attachments

Description Aharon Lanin 2011-01-11 13:35:09 UTC
This originally appeared as bug 10808 comment 51.

While most of the directional effects of the dir attribute (like those of the bdo and bdi elements) are explicitly documented, it is not documented that the <pre> and <textarea> elements significantly modify the effects of dir=auto (by setting unicode-bidi:plaintext). That this happens only in the presentation layer, via the default sylesheet, is irrelevant: the effects of <bdo> are also entirely defined by the default stylesheet, but are nevertheless explicitly documented.

I would therefore suggest something like the following note under the description of the dir attribute, perhaps after "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."):

"Please note that this mapping is significantly augmented for the pre and textarea elements, where dir=auto results in unicode-bidi:plaintext, which determines the base direction of each bidi paragraph of these elements' content independently."
Comment 1 Ian 'Hixie' Hickson 2011-02-14 23:27:08 UTC
So I started doing this (I'll push an incomplete patch below) but I realised I have no idea what white-space:plaintext means, so I actually can't write the relevant style rules. In particular it's not clear to me what it means when applied to <textarea>, since CSS generally applies to DOM contents and the contents of replaced elements like <textarea> aren't affected by it, and it's not clear to me what it means on <pre> when <pre> has explicit <br>s and implicit line breaks from line-wrapping and explicit line breaks from embedded newlines or double-newlines.

What behaviour do you want to require from browsers?
Comment 2 contributor 2011-02-14 23:27:35 UTC
Checked in as WHATWG revision r5886.
Check-in comment: Incomplete requirement text for <pre dir=auto> and <textarea dir=auta> (blocked on getting spec for white-space:plaintext)
http://html5.org/tools/web-apps-tracker?from=5885&to=5886
Comment 3 Ian 'Hixie' Hickson 2011-02-14 23:28:37 UTC
er, s/white-space/unicode-bidi/g
Comment 4 Ian 'Hixie' Hickson 2011-02-14 23:52:10 UTC
Ok, fantasai pointed me to the right specs.

I've updated the spec to be consistent with how other such requirements are made and how they defer to CSS. Please don't hesitate to reopen the bug if there's something else that can be done to make this clearer.

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.
Comment 5 contributor 2011-02-14 23:52:28 UTC
Checked in as WHATWG revision r5887.
Check-in comment: Update bidi requirements for <pre>, <textarea>, and <br>.
http://html5.org/tools/web-apps-tracker?from=5886&to=5887
Comment 6 Aharon Lanin 2011-02-16 16:45:34 UTC
The change made by http://html5.org/tools/web-apps-tracker?from=5886&to=5887 is partially incorrect, because it says that the style layer can implement the bidi paragraph breaking requirements of <br>, as well as newlines in <pre> and <textarea> by "implementing the CSS 'unicode-bidi' property". As far as I know, unicode-bidi can not implement the bidi paragraph breaking requirements of these elements. What the style layer can and should do, however, is simply implement the Unicode Bidi Algorithm re newlines, which the UBA defines to be bidi paragraph breaks. This will result in the newlines in <pre> and <textarea> serving as paragraph breaks, since the existing default white-space style of these elements, as implemented by the style layer, will leave the newlines in these elements' content. For <br>, the style layer should be able to implement it being a paragraph break via the default stylesheet settings for <br>, as they already appear in http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#punctuation-and-decorations:

br { content: '\A'; white-space: pre; }

I do realize that this comment has nothing to do with the subject of this bug (which is dir=auto), and will file a separate bug on the above if you prefer I do so.
Comment 7 Aharon Lanin 2011-02-16 17:04:26 UTC
The note added re dir=auto, i.e. "For textarea and pre elements, the heuristic is applied on a per-paragraph level" is great!

However, you might want to also tack on the standard disclaimer there: "This requirement may be implemented indirectly through the style layer. For example, an HTML+CSS user agent could implement these requirements by implementing the CSS 'unicode-bidi' property." (The unicode-bidi property *is* relevant here, since its plaintext value is what turns on the per-paragraph directionality estimation.)
Comment 8 Ian 'Hixie' Hickson 2011-05-03 22:15:35 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: Did Not Understand Request
Change Description: no spec change
Rationale:

I don't understand what is being requested here.

Please make sure to file separate bugs for separate issues, so that I can clearly track each issue and make sure nothing gets overlooked. Is comment 6 now dealt with in a separate bug? (It's unclear whether you did or did not file a new bug as mentioned in that comment.)

For comment 7, the suggested text is already present at the bottom of the section in question.
Comment 9 Aharon Lanin 2011-05-04 09:04:48 UTC
You are right!
Comment 10 Michael[tm] Smith 2011-08-04 05:14:58 UTC
mass-move component to LC1