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
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
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
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.
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 Semenikmaxsem.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
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
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
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
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-821... instead of this: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearc...
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 Kaldarirkaldari@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
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.
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?
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
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-821... instead of this: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearc...
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.
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.
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 Kaldarirkaldari@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. Peacheyp858snake@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 Kaldarirkaldari@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-821... instead of this: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearc...
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.
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 Kaldarirkaldari@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. Peacheyp858snake@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 Kaldarirkaldari@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-821... instead of this: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearc...
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
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).
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/...
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
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 GregorSimetrical+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/...
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
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.
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
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#Propos...
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
Ryan — what is your goal with the cleanup? Part of the reason I think you're getting nowhere on Wiktionary is that as far as anyone there can tell you're just changing stuff for the fun of changing stuff (and breaking it in the process...). If you can tell us what you're trying to achieve, then (given that we wrote the code, and have a reasonably good idea of how it's used), we can probably help you.
Conrad
On Fri, Apr 1, 2011 at 5:11 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
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#Propos...
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
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here.
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
On 4/1/11 5:53 PM, Conrad Irwin wrote:
Ryan — what is your goal with the cleanup? Part of the reason I think you're getting nowhere on Wiktionary is that as far as anyone there can tell you're just changing stuff for the fun of changing stuff (and breaking it in the process...). If you can tell us what you're trying to achieve, then (given that we wrote the code, and have a reasonably good idea of how it's used), we can probably help you.
Conrad
On Fri, Apr 1, 2011 at 5:11 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
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#Propos...
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
Ok — yes loading speeds are definitely something worth improving.
WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact.
I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :).
Conrad
On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here.
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
On 4/1/11 5:53 PM, Conrad Irwin wrote:
Ryan — what is your goal with the cleanup? Part of the reason I think you're getting nowhere on Wiktionary is that as far as anyone there can tell you're just changing stuff for the fun of changing stuff (and breaking it in the process...). If you can tell us what you're trying to achieve, then (given that we wrote the code, and have a reasonably good idea of how it's used), we can probably help you.
Conrad
On Fri, Apr 1, 2011 at 5:11 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
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#Propos...
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
Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two:
http://www.mediawiki.org/wiki/Summer_of_Code_2011
best, Sumana Harihareswara
On 04/01/2011 10:11 PM, Conrad Irwin wrote:
Ok — yes loading speeds are definitely something worth improving.
WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact.
I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :).
Conrad
On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here.
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
I think the JS editor stuff would also fit well enough with the topics of the Berlin hackathon in May...
-- daniel
On 03.04.2011 15:30, Sumana Harihareswara wrote:
Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two:
http://www.mediawiki.org/wiki/Summer_of_Code_2011
best, Sumana Harihareswara
On 04/01/2011 10:11 PM, Conrad Irwin wrote:
Ok — yes loading speeds are definitely something worth improving.
WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact.
I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :).
Conrad
On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here.
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Maybe my brain just made a leap here, but is there a plan for implementing a web-based Javascript editor for MediaWiki?? This would be a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) which is really slick - syntax color-coding, tabbing that works, a Tidy button(!), integrated jsLint(!).
If not, hopefully, I've just created a self-fulfilling rumor :)
Ryan Kaldari
On 4/3/11 11:06 AM, Daniel Kinzler wrote:
I think the JS editor stuff would also fit well enough with the topics of the Berlin hackathon in May...
-- daniel
On 03.04.2011 15:30, Sumana Harihareswara wrote:
Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two:
http://www.mediawiki.org/wiki/Summer_of_Code_2011
best, Sumana Harihareswara
On 04/01/2011 10:11 PM, Conrad Irwin wrote:
Ok — yes loading speeds are definitely something worth improving.
WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact.
I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :).
Conrad
On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here.
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
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
Also see the freebase / google acre system inline editor: http://wiki.freebase.com/wiki/Acre
What is more impressive than the online editor, is the template and integrated data query system in an seamless sandboxed server / client javascript system. Its not perfect, but definitely includes some ideas that would be interesting to explore long term.
--michael
On 04/04/2011 10:09 AM, Ryan Kaldari wrote:
Maybe my brain just made a leap here, but is there a plan for implementing a web-based Javascript editor for MediaWiki?? This would be a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) which is really slick - syntax color-coding, tabbing that works, a Tidy button(!), integrated jsLint(!).
If not, hopefully, I've just created a self-fulfilling rumor :)
Ryan Kaldari
On 4/3/11 11:06 AM, Daniel Kinzler wrote:
I think the JS editor stuff would also fit well enough with the topics of the Berlin hackathon in May...
-- daniel
On 03.04.2011 15:30, Sumana Harihareswara wrote:
Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two:
http://www.mediawiki.org/wiki/Summer_of_Code_2011
best, Sumana Harihareswara
On 04/01/2011 10:11 PM, Conrad Irwin wrote:
Ok — yes loading speeds are definitely something worth improving.
WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact.
I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :).
Conrad
On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here.
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
http://www.mediawiki.org/wiki/WYSIFTW ;-)
On Mon, Apr 4, 2011 at 6:09 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Maybe my brain just made a leap here, but is there a plan for implementing a web-based Javascript editor for MediaWiki?? This would be a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) which is really slick - syntax color-coding, tabbing that works, a Tidy button(!), integrated jsLint(!).
If not, hopefully, I've just created a self-fulfilling rumor :)
Ryan Kaldari
On 4/3/11 11:06 AM, Daniel Kinzler wrote:
I think the JS editor stuff would also fit well enough with the topics of the Berlin hackathon in May...
-- daniel
On 03.04.2011 15:30, Sumana Harihareswara wrote:
Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two:
http://www.mediawiki.org/wiki/Summer_of_Code_2011
best, Sumana Harihareswara
On 04/01/2011 10:11 PM, Conrad Irwin wrote:
Ok — yes loading speeds are definitely something worth improving.
WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact.
I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :).
Conrad
On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here.
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ah, sorry, realized what you mean a second after sending...
On Mon, Apr 4, 2011 at 7:07 PM, Magnus Manske magnusmanske@googlemail.com wrote:
http://www.mediawiki.org/wiki/WYSIFTW ;-)
On Mon, Apr 4, 2011 at 6:09 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Maybe my brain just made a leap here, but is there a plan for implementing a web-based Javascript editor for MediaWiki?? This would be a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) which is really slick - syntax color-coding, tabbing that works, a Tidy button(!), integrated jsLint(!).
If not, hopefully, I've just created a self-fulfilling rumor :)
Ryan Kaldari
On 4/3/11 11:06 AM, Daniel Kinzler wrote:
I think the JS editor stuff would also fit well enough with the topics of the Berlin hackathon in May...
-- daniel
On 03.04.2011 15:30, Sumana Harihareswara wrote:
Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two:
http://www.mediawiki.org/wiki/Summer_of_Code_2011
best, Sumana Harihareswara
On 04/01/2011 10:11 PM, Conrad Irwin wrote:
Ok — yes loading speeds are definitely something worth improving.
WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact.
I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :).
Conrad
On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here.
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ryan,
My thoughts (from a sister project side)
It is useful to go through a few bits to manage expectations.
* General introductory information around the scope, expected outcomes, summary of what wikis can do and general dates and for this to be placed at the Techblog. This allows local wikis to know and prepare. As the importance rises, I think that a general sitenotice for a week is appropriate. Is it possible to do a site notice for admins only? As that would be most useful. [This lets those who are alert into the playpen and involved]
* A place where the detail of the project and outcomes, and how to participate, and where to advise (aka complain) where and when things stop working, or help is needed. If you are planning to go through series of wikis, then if there is a timetable to which people can prepare, or even be available to help, and how they can help. [This empowers people and puts the emphasis on them to get themselves organised for your timetable, your time being the limited factor]
* Where you are planning on doing work, having generic information at your local talk page about who you are and that points them to the information pages (general and detail), to the fact that they had been told it was going to happen and to where they should bitch and complain. [Akin to TALK TO THE HAND]
While admins will always be protective of their patch, especially if something breaks universally, none of us wishes to impede progress and we want to know how we can help. -> Make us do our homework -> Give us time to marshal resources, and -> Have expectations that we should be organised to help. If we cannot do that, then it is somewhat upon our heads if you have to do what you have to do.
Expectations and activities need to be reasonable and practical to both parties.
Regards, Andrew <- CSS clueless beyond the basics
On 1 Apr 2011 at 17:11, Ryan Kaldari wrote:
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#Propos...
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
Billinghurst billinghurst@gmail.com wrote:
Ryan,
While admins will always be protective of their patch, especially if something breaks universally, none of us wishes to impede progress and we want to know how we can help. -> Make us do our homework -> Give us time to marshal resources, and -> Have expectations that we should be organised to help. If we cannot do that, then it is somewhat upon our heads if you have to do what you have to do.
Frankly, from my experience as sysop at plwiki (not a sister project, though, but I did some of the css/js work for pl* sisters), I'd rather recommend to explain a bit (like "say who you are"), but go ahead with the changes. Maybe a single page on meta will do. The problem will be with non-English projects, as some people may not read English at all, like some of the quite MediaWiki-savvy admins in the projects for smaller languages in the former USSR.
Giving time and having much discussion serves little point, since from my experience those volunteers who spent lots of time on building those scripts now how little time to re-write them or review them (as many of stuff simply needs to be deleted). Some may react badly, like just reverting changes because "it works". Well, it works in a way, and very often some strange effect appear (mainly because changed loading order of js/css).
I am all for opening up extensions for sister projects - [[Extension:Proofread]] improved situation at many wikisources, I would envision we have more sister-project-related extensions in the SVN, even if they are CSS- or JS- only (or mostly). This gives core developers a chance to better understand of the impact they make and gives them the opportunity to fix problems themselves in a cross-repository sweeping commits with proper commit logs.
//Marcin
"MZMcBride" z@mzmcbride.com wrote in message news:C9BBCF19.1056A%z@mzmcbride.com...
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
I would be very interested to hear what criterion you would use to separate out a group of 200 (or any number other than zero, one or all [1]) wikis which are "maintained" from the rest which are "unmaintained"; where the distinction in quality of service, the ratio of Foundation resources to userbase or readership, or any other meaningful statistic, showed any obvious jump across the boundary. You would need to be able to show such a thing in order to make anyone believe that there is any "intention" (or lack thereof) for the Foundation to do anything with the sister projects.
It's one thing to argue that more of the Foundation's resources should be directed to particular projects; that's a perfectly reasonable discussion, but for foundation-l, not here. It's quite another to argue that an arbitrary number (don't forget that Ryan is referring to the number of wikis with broken JavaScript which are unable to fix it themselves, not any attempt to count every wiki in the cluster) represents some freudian slip into some diabolical scheme or even into a subconscious mindset. Even if that is what you want to claim, that belongs in foundation-l as well. "Our shell request workflow could use work" is a time-honoured topic which comes and goes and seems to be in a relatively successful era at the moment. Anything more political than that has nothing to do with, and no place on, wikitech-l.
--HM
Happy-melon wrote:
I would be very interested to hear what criterion you would use to separate out a group of 200 (or any number other than zero, one or all [1]) wikis which are "maintained" from the rest which are "unmaintained"; where the distinction in quality of service, the ratio of Foundation resources to userbase or readership, or any other meaningful statistic, showed any obvious jump across the boundary. You would need to be able to show such a thing in order to make anyone believe that there is any "intention" (or lack thereof) for the Foundation to do anything with the sister projects.
I'm not really sure what you're saying here. Are you trying to argue that the other projects get anywhere near as much attention as Wikipedia?
It's one thing to argue that more of the Foundation's resources should be directed to particular projects; that's a perfectly reasonable discussion, but for foundation-l, not here. It's quite another to argue that an arbitrary number (don't forget that Ryan is referring to the number of wikis with broken JavaScript which are unable to fix it themselves, not any attempt to count every wiki in the cluster) represents some freudian slip into some diabolical scheme or even into a subconscious mindset. Even if that is what you want to claim, that belongs in foundation-l as well. "Our shell request workflow could use work" is a time-honoured topic which comes and goes and seems to be in a relatively successful era at the moment. Anything more political than that has nothing to do with, and no place on, wikitech-l.
I considered the venue before posting. But the reality is that the tech side (or specifically MediaWiki) is currently at the core of every Wikimedia wiki. Its development, its features, its architecture, etc. all have a fundamental impact on what any Wikimedia site is.
The focus of MediaWiki should mirror the focus of the Wikimedia Foundation. Currently MediaWiki tries to do too much, tries to fill too many niches, and ends up not doing very much particularly well. I'd like to see that change. I'd like to see it focused, as I think it would benefit both MediaWiki and the Wikimedia Foundation to a huge extent. If you think that's a topic for foundation-l, I suppose we'll have to agree to disagree. Personally, I think it's a tech topic, given that nearly every change seems to at least begin with code development.
MZMcBride
MZMcBride z@mzmcbride.com 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....
The good thing about forgotten/abandoned/unloved/etc. projects is that they probably don't have lots of cruft accumulated in the global CSS/JS files (as they require quite lively tech-savvy community to maintain them).
So those sites will not probably require any changes and will survive HTML5 migration without any problems.
//Marcin
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.
"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
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
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@lists.wikimedia.org