This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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."
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?
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
er, s/white-space/unicode-bidi/g
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.
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
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.
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.)
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.
You are right!
mass-move component to LC1