Mailing List Archive

On HTML5
Hello!

What is the current concensus on HTML5?
Are we going to fully support it and use as many features as we can or
are we going to keep just using javascript alterntives?
I would assume that we would continue to use javascript in the case
that the client does not support HTML5, though that may mean we have
to write things twice.
Also, if we are indeed going to use HTML5, are we going to use XHTML5?
I would like to work on integrating MediaWiki with HTML5 if at all
possible, I am just unsure on what parts we wish to use the new
standard.

TIA - Joseph Roberts

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On 22.03.2011, 19:05 Joseph wrote:

> Hello!

> What is the current concensus on HTML5?
> Are we going to fully support it and use as many features as we can or
> are we going to keep just using javascript alterntives?
> I would assume that we would continue to use javascript in the case
> that the client does not support HTML5, though that may mean we have
> to write things twice.
> Also, if we are indeed going to use HTML5, are we going to use XHTML5?
> I would like to work on integrating MediaWiki with HTML5 if at all
> possible, I am just unsure on what parts we wish to use the new
> standard.

As the matter of fact, MediaWiki serves HTML5 by default. The only
reason why it is still not enabled on Wikipedia is backward
compatibility with numerous screen-scraping scripts/tools. However,
they had their last warning recently - HTML5 was briefly enabled a
couple of times and there's no guarantee that next time it will not
stick :D

--
Best regards,
Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
Joseph Roberts wrote:
> Hello!
>
> What is the current concensus on HTML5?
> Are we going to fully support it and use as many features as we can or
> are we going to keep just using javascript alterntives?
> I would assume that we would continue to use javascript in the case
> that the client does not support HTML5, though that may mean we have
> to write things twice.
> Also, if we are indeed going to use HTML5, are we going to use XHTML5?
> I would like to work on integrating MediaWiki with HTML5 if at all
> possible, I am just unsure on what parts we wish to use the new
> standard.
>
> TIA - Joseph Roberts

Do you know about $wgHtml5 ?
http://www.mediawiki.org/wiki/Manual:$wgHtml5



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On Tue, Mar 22, 2011 at 12:25 PM, Max Semenik <maxsem.wiki@gmail.com> wrote:
> As the matter of fact, MediaWiki serves HTML5 by default. The only
> reason why it is still not enabled on Wikipedia is backward
> compatibility with numerous screen-scraping scripts/tools. However,
> they had their last warning recently - HTML5 was briefly enabled a
> couple of times and there's no guarantee that next time it will not
> stick :D
>

Was a date given for that? I might've missed it.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On Wed, Mar 23, 2011 at 2:25 AM, Max Semenik <maxsem.wiki@gmail.com> wrote:
> As the matter of fact, MediaWiki serves HTML5 by default. The only
> reason why it is still not enabled on Wikipedia is backward
> compatibility with numerous screen-scraping scripts/tools. However,
> they had their last warning recently - HTML5 was briefly enabled a
> couple of times and there's no guarantee that next time it will not
> stick :D
Was this written anywhere? where and what is the date?

I thought it was the issue that broke access for certain IE users that
resulted in it disabled last time..... We have been telling people not
to screen scrape for YEARS and to use the api instead where possible,
We should just re-enable it and let them solve their own problems.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
"K. Peachey" <p858snake@yahoo.com.au> wrote in message
news:AANLkTinaNRjcoHO_0rAc4AmFS3gT98HKR0nz2yzpkOHk@mail.gmail.com...
> On Wed, Mar 23, 2011 at 2:25 AM, Max Semenik <maxsem.wiki@gmail.com>
> wrote:
>> As the matter of fact, MediaWiki serves HTML5 by default. The only
>> reason why it is still not enabled on Wikipedia is backward
>> compatibility with numerous screen-scraping scripts/tools. However,
>> they had their last warning recently - HTML5 was briefly enabled a
>> couple of times and there's no guarantee that next time it will not
>> stick :D
> Was this written anywhere? where and what is the date?
>
> I thought it was the issue that broke access for certain IE users that
> resulted in it disabled last time..... We have been telling people not
> to screen scrape for YEARS and to use the api instead where possible,
> We should just re-enable it and let them solve their own problems.

In a perfect bonsai model of the IPv6 implementation, the recent enabling of
$wgHTML5 prompted a mass panic to rewrite TWINKLE, enwiki's flagship
javascript anti-vandal-plus-hundreds-of-extra-random-bells-and-whistles
package, which had sat essentially untouched throughout our many warnings.
It's moderately amusing to watch, but to be fair to them it is a huge
codebase and it's not unreasonable to give them a month or so to sort it
out. Most other wikis just copy from enwiki, so they're both the driving
force, and the heel draggers... :-D

--HM



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On Tue, Mar 22, 2011 at 12:05 PM, Joseph Roberts
<roberts.joseph@ntlworld.com> wrote:
> What is the current concensus on HTML5?

http://www.mediawiki.org/wiki/HTML5

> Are we going to fully support it and use as many features as we can or
> are we going to keep just using javascript alterntives?

We're fine with using HTML5 features wherever possible, if $wgHtml5 is
true. Whether we need JavaScript fallback follows from the general
principle of graceful degradation -- if the user experience is still
acceptable without the HTML5 feature being supported, fallback is not
mandatory.

> Also, if we are indeed going to use HTML5, are we going to use XHTML5?

No. XHTML5 is fragile and provides no practical benefits over
well-formed HTML5. Instead, we will continue to serve text/html but
try to keep it well-formed when possible, as we always have.

> I would like to work on integrating MediaWiki with HTML5 if at all
> possible, I am just unsure on what parts we wish to use the new
> standard.

We're happy to use anything that's useful.

On Tue, Mar 22, 2011 at 12:25 PM, Max Semenik <maxsem.wiki@gmail.com> wrote:
> As the matter of fact, MediaWiki serves HTML5 by default. The only
> reason why it is still not enabled on Wikipedia is backward
> compatibility with numerous screen-scraping scripts/tools. However,
> they had their last warning recently - HTML5 was briefly enabled a
> couple of times and there's no guarantee that next time it will not
> stick :D

The goal is currently to enable HTML5 on Wikimedia sites without
breaking screen-scrapers that use XML libraries. (Screen-scrapers
that use regex can drop dead.) I made some fixes a while back and
tagged them to be picked up by Wikimedia, so hopefully the Wikimedia
branch can now try turning on HTML5 mode again. If it still causes
well-formedness errors, I'd really need to know the exact URLs to
figure out what they are.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
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
"standards mode". Testing and tweaking all the CSS in Mediawiki for this
DOCTYPE change is a huge task. I'm already getting bug reports due to
this issue, and I wasn't even aware we were making the change.

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.

How exactly was the conclusion reached that this change would only
affect screen-scraping tools? The MediaWiki page on the HTML5 transition
lists several other issues, none of which seem to have been adequately
discussed or addressed.

Ryan Kaldari


On 3/22/11 9:35 AM, Chad wrote:
> On Tue, Mar 22, 2011 at 12:25 PM, Max Semenik<maxsem.wiki@gmail.com> wrote:
>> As the matter of fact, MediaWiki serves HTML5 by default. The only
>> reason why it is still not enabled on Wikipedia is backward
>> compatibility with numerous screen-scraping scripts/tools. However,
>> they had their last warning recently - HTML5 was briefly enabled a
>> couple of times and there's no guarantee that next time it will not
>> stick :D
>>
> Was a date given for that? I might've missed it.
>
> -Chad
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On Mon, Mar 28, 2011 at 10:47 PM, Ryan Kaldari <rkaldari@wikimedia.org> wrote:
> 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.
>

It *was* reverted, it hasn't been deployed again since.

> How exactly was the conclusion reached that this change would only
> affect screen-scraping tools?
>

It was the only noticed/complained about failure when we did enable it.
That doesn't mean it can't/won't cause other things to break as well.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On 3/28/11 7:53 PM, Chad wrote:
> It *was* reverted, it hasn't been deployed again since.

Well, it still seems to be in place on truck, which is why I'm getting
CSS bug reports. Can someone revert it on trunk as well?

The brief discussion of the CSS rendering-mode issue on Mediawiki.org
seems to be nicely wrapped up by Simetrical: "I don't think there's any
better transition plan than just breaking it." Is this really the best
plan we can come up with? In case you didn't know, the Foundation
actually has paid front-end developers now (like Brandon and myself). If
our EMPs are informed of the issue ahead of time, we could actually fix
the CSS problems before you guys break the site rather than after, but I
guess that's a pretty novel idea :P

Ryan Kaldari

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
Ryan Kaldari 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. I'm already getting bug reports due to
> this issue, and I wasn't even aware we were making the change.

Can you elaborate on some of the harmful or potentially harmful effects that
you're talking about?

> How exactly was the conclusion reached that this change would only
> affect screen-scraping tools? The MediaWiki page on the HTML5 transition
> lists several other issues, none of which seem to have been adequately
> discussed or addressed.

I assume you're referring to <http://www.mediawiki.org/wiki/HTML5>? (I
didn't see a link in the previous e-mails.)

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On Mon, Mar 28, 2011 at 11:11 PM, Ryan Kaldari <rkaldari@wikimedia.org> wrote:
> On 3/28/11 7:53 PM, Chad wrote:
>>
>> It *was* reverted, it hasn't been deployed again since.
>
> Well, it still seems to be in place on truck, which is why I'm getting CSS
> bug reports. Can someone revert it on trunk as well?
>

I highly doubt it. It's been set to true in trunk for about a year now,
running on live sites (Translatewiki) for nearly as long, and this is
the absolute first I've heard of any such issues.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On Tue, Mar 29, 2011 at 1:11 PM, Ryan Kaldari <rkaldari@wikimedia.org> wrote:
> Well, it still seems to be in place on truck, which is why I'm getting
> CSS bug reports. Can someone revert it on trunk as well?
>
> The brief discussion of the CSS rendering-mode issue on Mediawiki.org
> seems to be nicely wrapped up by Simetrical: "I don't think there's any
> better transition plan than just breaking it." Is this really the best
> plan we can come up with? In case you didn't know, the Foundation
> actually has paid front-end developers now (like Brandon and myself). If
> our EMPs are informed of the issue ahead of time, we could actually fix
> the CSS problems before you guys break the site rather than after, but I
> guess that's a pretty novel idea :P
>
> Ryan Kaldari
I think running trunk on HTML5 is correct, We want to upgrade so by
trunk we are doing that and yes it will break stuff, but people should
expect that when running svn trunk on any install (It's one of the
many reasons we don't recommend people installing it on production
sites).

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. As well
that, our testing playground (Translatewiki) is apprently already
running it so we can find these breakages.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On Tue, Mar 29, 2011 at 1:11 PM, Ryan Kaldari <rkaldari@wikimedia.org> wrote:
> Well, it still seems to be in place on truck, which is why I'm getting
> CSS bug reports. Can someone revert it on trunk as well?
Which bug reports? can you link to some in Bz or the like please?

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
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.
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-82155.png
instead of this:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearch-84908.png

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? At the very least, we should get some
developers to inventory the CSS changes that will be needed and have
patches ready for the switch. Otherwise each project is going to
implement their own fixes locally and we'll end up with totally
fragmented CSS. Also, does anyone know if this will affect $wgUseTidy?

Ryan Kaldari


On 3/28/11 8:21 PM, Chad wrote:
> On Mon, Mar 28, 2011 at 11:11 PM, Ryan Kaldari<rkaldari@wikimedia.org> wrote:
>> On 3/28/11 7:53 PM, Chad wrote:
>>> It *was* reverted, it hasn't been deployed again since.
>> Well, it still seems to be in place on truck, which is why I'm getting CSS
>> bug reports. Can someone revert it on trunk as well?
>>
> I highly doubt it. It's been set to true in trunk for about a year now,
> running on live sites (Translatewiki) for nearly as long, and this is
> the absolute first I've heard of any such issues.
>
> -Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On Mon, Mar 28, 2011 at 10:47 PM, Ryan Kaldari <rkaldari@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@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@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-82155.png
> instead of this:
> https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearch-84908.png

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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
On Wed, Mar 30, 2011 at 12:21 AM, Aryeh Gregor
<Simetrical+wikilist@gmail.com> wrote:
> On Mon, Mar 28, 2011 at 11:22 PM, K. Peachey <p858snake@gmail.com> wrote:
>> .....
> 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.
Obviously i retract my comment about the lack of disucssion, As a non
developer and not noticing anything recently had happened, I had to
fail to consider the fact that it might of been that long ago so I
didn't think to search for it.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
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.

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@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@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@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-82155.png
>> instead of this:
>> https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearch-84908.png
> 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
I went ahead and asked my EMPs if I could take a couple days to do an
assessment of what CSS will be affected by the switch to HTML5. The
request was granted and I should have some time to work on it next week.
My apologies for being so aggressive on this issue, as it will probably
turn out to be a minor problem in the end. If anyone is interested in
helping with the assessment, please let me know.

Ryan Kaldari


On 3/29/11 11:06 AM, Ryan Kaldari 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.
>
> 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@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@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@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-82155.png
>>> instead of this:
>>> https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearch-84908.png
>> 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@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
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'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
Re: On HTML5 [ In reply to ]
>> Aryeh Gregor <Simetrical+wikilist@gmail.com> wrote:
>
>> 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.

Sorry for bringing this up, I was the one who cropped those screenshots that way.
Those screetshots are best viewed within the context of:

http://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/82155#c15527

By the way, I am not happy with the "reverted" version either, the search
icon is a bit too high and the box is overlapping the line.
In general, this CSS is probably too fragile and to prone to
font/platform/resolution/zoom factor/whatever problems.

I really hope that getting proper CSS for HTML5 in *core* is just a matter of
checking few workarounds in Vector and maybe Monobook and that's it.

However, for successful Wikimedia deployment, there is a different problem:

For years already I was fighting a happy-go-lucky approach to styling
in MediaWiki:Common.css/Monobook.css as well as in individual templates.
(My battleground is Polish Wikipedia). There are dozens of quick fixes
and workarounds there also for various browsers issues. It is indeed
the problem they haven't been sometimes properly communicated back upstream.

Actually I was wondering - and we need to discuss this with
plwiki's tech community - to literally throw out all of MediaWiki:Common.js/Common.css
code and "see what breaks" once Wikimedia moves to HTML5.
Maybe this could be a sort of heads-up message given out to the community
once we are ready to switch over to HTML5?

We have a huge backlog in converting our JavaScript already
(ResourceLoader for one, removing all the library code we should
get rid of once we have jQuery). Only most rudimentary
fixes to sitewide js has been done so far and maybe some gadgets.

While I deeply believe we can quickly sort out all the issues with
the MediaWiki codebase. The real problem is with the global
css/js cruft, that major Wikipedias accumulated over years.
I am afraid that's something that WMF developers cannot really handle,
since they didn't put this in there in the first place, but
maybe this is the problem with just few major wikis only?

Maybe there aresome things that would help, like
unning copies of major wikis on prototype (including the content!)
or something like that. Any suggestions?

//Marcin






_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing
clean-up on a few wikis, but I usually just get chewed out by the local
admins for not discussing every change in detail (which obviously
doesn't scale for fixing 200+ wikis). I would love to hear ideas for how
to address this problem.

Ryan Kaldari


On 3/30/11 4:57 AM, Marcin Cieslak wrote:
>>> Aryeh Gregor<Simetrical+wikilist@gmail.com> wrote:
>>> 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.
> Sorry for bringing this up, I was the one who cropped those screenshots that way.
> Those screetshots are best viewed within the context of:
>
> http://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/82155#c15527
>
> By the way, I am not happy with the "reverted" version either, the search
> icon is a bit too high and the box is overlapping the line.
> In general, this CSS is probably too fragile and to prone to
> font/platform/resolution/zoom factor/whatever problems.
>
> I really hope that getting proper CSS for HTML5 in *core* is just a matter of
> checking few workarounds in Vector and maybe Monobook and that's it.
>
> However, for successful Wikimedia deployment, there is a different problem:
>
> For years already I was fighting a happy-go-lucky approach to styling
> in MediaWiki:Common.css/Monobook.css as well as in individual templates.
> (My battleground is Polish Wikipedia). There are dozens of quick fixes
> and workarounds there also for various browsers issues. It is indeed
> the problem they haven't been sometimes properly communicated back upstream.
>
> Actually I was wondering - and we need to discuss this with
> plwiki's tech community - to literally throw out all of MediaWiki:Common.js/Common.css
> code and "see what breaks" once Wikimedia moves to HTML5.
> Maybe this could be a sort of heads-up message given out to the community
> once we are ready to switch over to HTML5?
>
> We have a huge backlog in converting our JavaScript already
> (ResourceLoader for one, removing all the library code we should
> get rid of once we have jQuery). Only most rudimentary
> fixes to sitewide js has been done so far and maybe some gadgets.
>
> While I deeply believe we can quickly sort out all the issues with
> the MediaWiki codebase. The real problem is with the global
> css/js cruft, that major Wikipedias accumulated over years.
> I am afraid that's something that WMF developers cannot really handle,
> since they didn't put this in there in the first place, but
> maybe this is the problem with just few major wikis only?
>
> Maybe there aresome things that would help, like
> unning copies of major wikis on prototype (including the content!)
> or something like that. Any suggestions?
>
> //Marcin
>
>
>
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: On HTML5 [ In reply to ]
Ryan Kaldari wrote:
> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing
> clean-up on a few wikis, but I usually just get chewed out by the local
> admins for not discussing every change in detail (which obviously
> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how
> to address this problem.
>
> Ryan Kaldari

Make a central page in meta giving a general overview of the changes
you're doing?
I suppose they all could be clasified in a few classes.



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Focus on sister projects [ In reply to ]
Ryan Kaldari wrote:
> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing
> clean-up on a few wikis, but I usually just get chewed out by the local
> admins for not discussing every change in detail (which obviously
> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how
> to address this problem.

This caught my eye as Wikimedia has far more than 200 wikis. There seems to
be a shift happening within the Wikimedia Foundation. The sister projects
have routinely been ignored in the past, but things seem to be going further
lately....

Personally, I'm in favor of disbanding all of the projects that Wikimedia
has no intention of actively supporting in the near-future or even mid-range
future. I think the current situation in which certain sister projects are
supported in name only is unacceptable to the users and to the public.

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Focus on sister projects [ In reply to ]
Can you possibly get any more hyperbolic? For your information, I've
been trying to clean up the Javascript of en.wiktionary.org this past
week, which is a total nightmare (and it's a sister project!). If you'd
like to help, feel free to join the discussions:
http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js
http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library

Ryan Kaldari

On 4/1/11 4:51 PM, MZMcBride wrote:
> Ryan Kaldari wrote:
>> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing
>> clean-up on a few wikis, but I usually just get chewed out by the local
>> admins for not discussing every change in detail (which obviously
>> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how
>> to address this problem.
> This caught my eye as Wikimedia has far more than 200 wikis. There seems to
> be a shift happening within the Wikimedia Foundation. The sister projects
> have routinely been ignored in the past, but things seem to be going further
> lately....
>
> Personally, I'm in favor of disbanding all of the projects that Wikimedia
> has no intention of actively supporting in the near-future or even mid-range
> future. I think the current situation in which certain sister projects are
> supported in name only is unacceptable to the users and to the public.
>
> MZMcBride
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

1 2  View All