Your analysis of the effects of the DOCTYPE change is
not correct. As
Entlinkt tried to point out at the HTML5 page on
, 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.
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.
After doing some very limited tests this morning, it looks like the
impact on the site will probably be small. This is probably due to the
fact that we are already using standards-compliant HTML and CSS
throughout the site. However, we do have some CSS hacks and non-standard
workarounds to deal with bugs in browsers like IE6 (both in Vector and
various extensions). These are probably the areas in which the DOCTYPE
change will have an impact.
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.
Ryan Kaldari
On 3/29/11 7:21 AM, Aryeh Gregor wrote:
On Mon, Mar 28, 2011 at 10:47 PM, Ryan
Kaldari<rkaldari(a)wikimedia.org> wrote:
In case no one has mentioned this, changing the
DOCTYPE has a pretty
huge effect on how CSS gets rendered. Wikimedia's current DOCTYPE (XHTML
transitional) maps to "almost standards mode" or "limited quirks
mode"
in Firefox, Safari, Chrome, Opera, IE8 and IE9. Changing to "<!DOCTYPE
html>" will switch the rendering mode in all of those browsers to
"standards mode". Testing and tweaking all the CSS in Mediawiki for this
DOCTYPE change is a huge task.
Why? I did research this issue before changing the
default doctype,
and as far as I found out, there's exactly one difference between
standards and almost-standards: the way images in tables are handled.
This will only seriously disrupt table-based layout that relies
heavily on images, like where you have a single image that you've
broken up into pieces and you're lining them up again by putting them
in a table. Other layouts will shift a bit, with some extra gaps
appearing, but it should be only a minor aesthetic issue that can be
fixed after the fact.
I'm already getting bug reports due to
this issue, and I wasn't even aware we were making the change.
"Already"? You realize the default doctype in trunk has been strict
standards mode continuously since **July 2009**?
<http://www.mediawiki.org/wiki/Special:Code/MediaWiki/53142> That's
more than a year and a half. In that whole time, nobody has told me
about *any* bug caused by the switch to strict standards mode. Maybe
there are some I'm not aware of, but people usually CC me on bugs
related to the HTML5 doctype.
What bugs exactly were filed, and how are they so difficult to fix?
The switch to<!DOCTYPE html> should be
reverted immediately. If we want
to switch to this DOCTYPE, we need to plan and budget for the front-end
development that will be necessary to support this change.
We can talk about this
when you point out specific issues that were
caused by the change that are severe enough to justify a revert
despite the fact that apparently no one noticed them for over a year
and a half.
How exactly was the conclusion reached that this
change would only
affect screen-scraping tools?
Because that's the only actual problem
that's been reported with the
doctype change that anyone has told me about, when it's been enabled
on trunk since July 2009 and enabled on Wikimedia sites for several
hours on two separate occasions. If you have other actual specific
problems that you'd like to point out, please do so.
(I'm not counting the fact that we were serving KHTMLFixes.css to
modern-day WebKit, which happened not to break in old WebKit versions
as long as we were in almost-standards mode instead of standards mode.
This would have come up anyway, since WebKit changed their code so we
broke in either mode, and the correct fix was to delete
KHTMLFixes.css.)
The MediaWiki page on the HTML5 transition
lists several other issues, none of which seem to have been adequately
discussed or addressed.
Such as?
On Mon, Mar 28, 2011 at 11:22 PM, K. Peachey<p858snake(a)gmail.com> wrote:
In hindsite, probably changing it on trunk should
of probably got a
tad more discussion (although I havn't looked for the revision where
this occured to see what the CR discussion/comments are like), but
it's only trunk (where stuff is ment to break), where as changing it
in a release should really be where the discussion starts.
I started a whole
thread on it back in 2009 before I changed it:
http://lists.wikimedia.org/pipermail/wikitech-l/2009-July/043865.html
There was loads of discussion, over sixty posts to the thread. I also
made a point of asking Brion (then the lead developer) for approval
before switching it on.
On Tue, Mar 29, 2011 at 12:52 AM, Ryan Kaldari<rkaldari(a)wikimedia.org> wrote:
So which rendering mode should I be vetting CSS
for? Strict or limited
quirks? Some of the CSS that I review is specifically tweaked for
limited quirks since that's what the Wikimedia sites are running in.
Wikimedia
should be switched to $wgHtml5 = true like trunk has been
for ages now, and then everyone should write for strict mode. The
problem here is Wikimedia, not trunk.
Honestly, I don't know all of the problems
that this change will cause.
I imagine it will just be lots of slight changes to how elements line
up, i.e. things shifting by a few pixels in most cases. For example, this:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-applied-82…
instead of this:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesear…
I don't know how those pictures are relevant, because one of them
appears to be a cropped version of the other. But I've taken a quick
look at the markup around the search box and it doesn't use any
tables, so the expected changes should be none. In fact, I'd expect
that the largest effect will be on wiki content, not the software
interface, because the software interface uses table layout sparingly
and images even more sparingly. But if it causes problems, they'll
only be aesthetic warts, not serious issues, so they can be fixed
after the fact.
I haven't thoroughly investigated the
ramifications of switching our
rendering mode, and apparently no one else has either. I'm just as
anxious to start using HTML5 as everyone else, but I think we should
have a better plan than "break stuff and revert if enough people
complain". If we know that there are potential issues, shouldn't we have
developers assigned to investigate those issues and report back before
we start deploying things?
No. Why? If it really causes serious display problems
that can't be
immediately fixed, we can always turn it off, but that's unlikely.
It's a waste of resources to preemptively find and fix minor aesthetic
issues when we don't even know whether they'll occur. We're not
talking about a change that might break the site.
Also, does anyone know if this will affect
$wgUseTidy?
There have been no problems reported related to $wgUseTidy since July
2009, so I'd hazard a guess that it will not. I run with $wgUseTidy =
true on my localhost wiki, and I've tested every HTML5 feature I added
and they all work. Raymond has pointed me to translatewiki.net's
config file, and they use $wgUseTidy and have reported no problems I
know of:
http://translatewiki.net/wiki/BetawikiSettings.php
I think it's fair to say that at this point, $wgHtml5 = true has a
strong presumption of working in every respect except breaking
well-formedness. If anyone *knows* of any further problems, please
give evidence that they exist, but there are no grounds for suggesting
it be reverted on trunk or anything like that.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org