On Tue, Mar 29, 2011 at 2:06 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Your analysis of the effects of the DOCTYPE change is not correct. As Entlinkt tried to point out at the HTML5 page on mediawiki.org, inline images, inline-blocks and inline-tables can also be affected (even outside tables). The search box is a good example of this. The DOCTYPE change affects the layout of the search box in both Firefox and Safari (and those are the only browsers I've check in so far), despite the fact that it doesn't use tables at all.
In that case, I was misled by the documentation I found on it:
https://developer.mozilla.org/en/Gecko%27s_%22Almost_Standards%22_Mode http://hsivonen.iki.fi/doctype/
I forgot about Entlinkt's comments, but my response is still mostly the same.
The fact that you don't see the difference in the two screenshots is not reassuring. In one, the search icon is clearly misplaced as it is overlapping the border of the search input, in the other it is not. This is caused solely by the DOCTYPE difference.
Now I see it, yes. They're cropped very differently, so I didn't spot the difference when flipping back and forth. I was looking at the boxes' edges, and didn't notice the difference in the position of the magnifying glass. Anyway, this is exactly the sort of minor bug where it's not worth it to worry too much about whether it breaks for a while -- certainly not to the extent of having to budget for the change, nor to the extent of reverting a change that's been in place for so long. To the extent of reviewing before deployment, sure, maybe. Doesn't bother me if we deploy without reviewing for this kind of thing, but I can see why you'd prefer to be more careful.
After doing some very limited tests this morning, it looks like the impact on the site will probably be small.
I'm glad we agree.
I would suggest that we check the effects of the DOCTYPE change in all of the browsers we support (including the mobile ones). Hopefully, the effect is minimal and we can proceed in due course. Having the attitude that it's not even worth checking, however, is disrespectful to the people who spend their time refining our CSS so that our sites look great in things like IE6, IEMobile, and the Playstation 3 browser.
I didn't intend any disrespect. I guess I just don't care as much as you do about minor aesthetic bugs. In any event, from what I've read (which may be wrong), almost-standards mode only exists in fairly recent versions of the major browsers, so it's unlikely to cause changes in old or obscure browsers like IE6. (IE apparently only implements the extra mode in version 8 and later.)
It occurred to me that we'd benefit from splitting up the HTML5 deployment. Switching $wgHtml5 to true might cause at least three types of compatibility issues:
1) Almost-standards vs. strict standards doctype
2) The use of new HTML5 markup
3) Switching to a doctype that doesn't specify a DTD, which breaks named entities
There's no need to risk all three issues at once. It would be better if we had a configuration option that overrode the doctype independent of $wgHtml5. Then we could first set it to a strict-mode doctype like XHTML 1.0 Strict, to test (1). Then enable $wgHtml5 to test (2) without a doctype change. Then finally restore the standard HTML5 doctype to test (3), which has been the only really problematic issue so far. If people other than me were interested, this should be possible to do pretty easily, but I don't really have any time to spend on MediaWiki stuff these days (and it's kind of hard to do deployment stuff without shell access).