On Tue, Mar 29, 2011 at 2:06 PM, Ryan Kaldari <rkald...@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's_%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).

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to