Page MenuHomePhabricator
Create Task
Maniphest T41912

Invalid value for HTML5 dir attribute ("auto")
Closed, DeclinedPublic
Actions

Description

I have noticed for a while that there are spacing errors in the watchlist comments, often with the comment text moving to the right over the right parenthesis. I have traced this back to the following HTML source: <span dir="auto">...some comment...</span>. Having searched the docs for the dir attribute, I can only conclude that "auto" in *not* a valid value for this attribute. Removing it, or changing it to "ltr" does fix the issue.

Version: 1.20.x
Severity: normal
URL: http://en.wikipedia.org/wiki/Special:Watchlist

Details

Reference
bz39912

Event Timeline

• bzimport raised the priority of this task from to Low.Nov 22 2014, 12:57 AM
• bzimport added a project: MediaWiki-Watchlist.
• bzimport set Reference to bz39912.
• bzimport added a subscriber: Unknown Object (MLST).
Edokter created this task.Sep 2 2012, 5:31 PM
Edokter added a comment.Sep 2 2012, 5:35 PM

This also applies to history pages.

• brion added a comment.Sep 2 2012, 5:43 PM

http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-dir-attribute

"The auto keyword, which maps to the auto state

Indicates that the contents of the element are explicitly embedded text, but that the direction is to be determined programmatically using the contents of the element (as described below).

Note: The heuristic used by this state is very crude (it just looks at the first character with a strong directionality, in a manner analogous to the Paragraph Level determination in the bidirectional algorithm). Authors are urged to only use this value as a last resort when the direction of the text is truly unknown and no better server-side heuristic can be applied. [BIDI]"

Offhand I don't see any problems in Firefox 17 nightly or in Chrome 21 on my watchlist. Can you provide a screenshot?

Edokter added a comment.Sep 2 2012, 6:14 PM

Created attachment 11055
Screenshot depicting error caused by dir="auto"

"auto" is only valid in HTML5, not XHTML. And why use it when even the doc states only to use it as a last resort due to the incertainties it entails?

Screenshot attached. Basically, dir="auto" makes Chrome treat any preceding spacing in span.comment as if word-wrap: nowrap; is applied.

Attached:

DirAutoBug.png (23×791 px, 4 KB)

Anomie added a comment.Sep 2 2012, 8:01 PM

(In reply to comment #3)

And why use it when even the doc
states only to use it as a last resort due to the incertainties it entails?

Well, in this case we don't know whether the user-entered edit summary is LTR or RTL, do we? That seems to fit "when the direction of the text is
truly unknown and no better server-side heuristic can be applied", unless we want MediaWiki to be hard-coding the same check the browser is supposed to do to output the dir="...".

Screenshot attached. Basically, dir="auto" makes Chrome treat any preceding
spacing in span.comment as if word-wrap: nowrap; is applied.

In other words, Chrome has a bug.

BTW, for anyone following along, the link for the comment in the screenshot appears to be https://en.wikipedia.org/w/index.php?title=Talk:Main_Page&offset=20120902180000&limit=1&action=history, if further testing is needed. A potentially more useful link is https://en.wikipedia.org/w/index.php?title=Special:Contributions/Gilderien&offset=20120605185300&target=Gilderien&limit=1 (from an earlier discussion at [[Wikipedia:Village pump (technical)/Archive 100#Anomalous Edit Summary]]), which has more spaces for Chrome to screw up on.

Edokter added a comment.Sep 2 2012, 8:35 PM

(In reply to comment #4)

Well, in this case we don't know whether the user-entered edit summary is LTR
or RTL, do we? That seems to fit "when the direction of the text is
truly unknown and no better server-side heuristic can be applied", unless we
want MediaWiki to be hard-coding the same check the browser is supposed to do
to output the dir="...".

So why don't we?

In other words, Chrome has a bug.

A I said earlier, "auto" is only valid in HTML5, and we don't serve HTML5. In other words, it's a MediaWiki bug :)

Is there any way to test how Chrome reacts as if it were HTML5?

• brion added a comment.Sep 2 2012, 8:46 PM

I can't reproduce a clear rendering bug with the first link https://en.wikipedia.org/w/index.php?title=Talk:Main_Page&offset=20120902180000&limit=1&action=history in Chrome 21 under Mac OS X 10.8.1 or Windows 8.

I can though see a weird spacing on https://en.wikipedia.org/w/index.php?title=Special:Contributions/Gilderien&offset=20120605185300&target=Gilderien&limit=1 in Chrome 21 under both Mac OS X 10.8.1 and Windows 8: huge space gets snuck down to a single space if I change dir="auto" to dir="ltr" or dir="rtl".

Note there's another bug related to Chrome's handling of dir="auto" (bug 38109), which has corresponding upstream bugs filed for Chromium and WebKit.

• brion added a comment.Sep 2 2012, 8:48 PM

(In reply to comment #5)

Is there any way to test how Chrome reacts as if it were HTML5?

  • Save to disk.
  • Replace the XHTML doctype with just <!DOCTYPE html>
  • Load that html file.

Exact same behavior for me.

Anomie added a comment.Sep 2 2012, 9:05 PM

(In reply to comment #5)

A I said earlier, "auto" is only valid in HTML5, and we don't serve HTML5. In
other words, it's a MediaWiki bug :)

If that's your position, you might want to check http://www.w3.org/TR/xhtml1/normative.html#uaconf item 6. Still a Chrome bug.

Is there any way to test how Chrome reacts as if it were HTML5?

Sure, just make an edit with multiple consecutive spaces in the summary and an autocomment on a test wiki where you can toggle $wgHtml5 on and off as needed. I don't have Chrome to test with, but in Chromium 21 here it happens regardless of the $wgHtml5 setting.

SPQRobin added a comment.Sep 5 2012, 11:31 PM

Note that enabling of $wgHtml5 on WMF wikis is currently scheduled for 17 September (bug 27478).

Edokter added a comment.May 4 2013, 12:04 PM

Issue is not relevant anymore.

Aklapper removed subscribers: Anomie, • wikibugs-l-list.Oct 16 2020, 5:29 PM
Aklapper added a project: HTML5.May 17 2021, 11:52 AM
Aklapper removed a parent task: T21719: [DO NOT USE] HTML5 features (tracking) [superseded by #HTML5].May 17 2021, 11:57 AM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL