Last modified: 2013-05-04 12:04:02 UTC
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.
This also applies to history pages.
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?
Created attachment 11055 [details] 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.
(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.
(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?
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.
(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.
(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.
Note that enabling of $wgHtml5 on WMF wikis is currently scheduled for 17 September (bug 27478).
Issue is not relevant anymore.
