On Tue, Aug 9, 2011 at 10:43 PM, Platonides Platonides@gmail.com wrote:

ResourceLoaderDynamicStyles was purposefully added even though it is not conforming.

AFAIK <meta> tags with made-up name="" attributes are perfectly legal, at least in HTML5.

I think that by removing it you disabled some ResourceLoader feature.

Yes, you will have broken CSS precendence order for site/user CSS.

Roan Kattouw (Catrope)

On 10/08/2011 6:43 AM, Platonides wrote:

Theoretically, the wiki should never generate invalid HTML, but it's not perfect.

It was pretty close to perfect. I only had to comment out two features to get conformance with the (experimental) HTML5 validator. I assumed HTML5 output in my code, although AIUI MediaWiki also supports other varieties of HTML.

You could have also just used the hook.

Ah, but I don't know how to use the hook (yet), do I? :P I'll figure it out and fix up my code.

Thanks for sharing!

No worries.

I did a fast review of it below: You have an html injection problem in the extended links.

OK, I'll look into that.

What I don't understand is why you worked so hard to make the extended link use the canonical domain. A relative link would have worked fine.

Yeah, I have relative links if the canonical domain features aren't specified. (I added that as an after-thought, and you might have reviewed my code before I'd posted the update.)

Also, all the $wgCanonical* pieces could have been replaced with setting $wgServer to the chosen domain and a few calls to getFullUrl. (if $wgCanonicalSecureHost != $wgCanonicalHost, $wgServer can be set conditionally)

Ah, I didn't know about $wgServer.

Finally, if you wanted to mark one of them as canonical, IMHO you should have added a<link rel="canonical"> (but be careful with redirects, when MediaWiki adds one itself).

I don't know anything about <link rel="canonical">, nor do I really know how/where to go about adding it. Maybe I'll look into that.

Thanks.

John.

On 10/08/2011 6:53 AM, Daniel Friesen wrote:

Please don't edit DefaultSettings.php; Your $wgFooterIcons change could have been done in LocalSettings.php without causing trouble for yourself when you upgrade.

Ah, didn't realise LocalSettings.php was the right place to do my edits.

I guess I was coming from the perspective that I was contributing to core.

We have a DoEditSectionLink hook, adding those links should be possible without any modifications to core.

Yep, got that now. I'll fix that up. Thanks.

Though I don't really see anything we could add to MediaWiki. Most can already be done with hooks and config and fit more as extensions than default core features.

Fair enough.

And removing functionality of MediaWiki doesn't really count as adding something to core.

I kinda felt like I was adding more than I was taking away.

I can't comprehend the obsession with killing de-facto standardized patterns just to shove a button on a site to a picky validator that only takes into account a single relevant standard.

I'd rather not confuse my users who are trying to validate the HTML in their wiki text with noise from the platform. I don't control the validator, but I think it's a useful tool to incorporate on my web-site.

Maybe there should be a setting for 'strict html' which leaves out features that services like validator.w3.org don't accept.

John.

On 10/08/2011 9:13 AM, Platonides wrote:

John Elliot wrote:

...

Ah, but I don't know how to use the hook (yet), do I? :P I'll figure it out and fix up my code.

See docs/hooks.txt from your mediawiki folder.

Will do. Thanks!

On Tue, Aug 9, 2011 at 6:37 PM, John Elliot jj5@jj5.net wrote:

On 10/08/2011 6:53 AM, Daniel Friesen wrote:

...

I can't comprehend the obsession with killing de-facto standardized patterns just to shove a button on a site to a picky validator that only takes into account a single relevant standard.

One reason would be to help avoid embarrassments like this:

http://validator.w3.org/check?uri=http://en.wikipedia.org

I guess that's only embarrassing if those sorts of things bother you. I'm with Dan on this one, I've never thought those validator buttons are very nice additions to a website. Remind me a little too much of the "Optimized for NN4" buttons of old.

-Chad

On Tue, Aug 9, 2011 at 6:52 PM, John Elliot jj5@jj5.net wrote:

On 10/08/2011 8:47 AM, Chad wrote:

...

I guess that's only embarrassing if those sorts of things bother you.

I think it would be fair to have it both ways. There are a class of people who are bothered by things of that sort. I'm sure I'm not alone, at least on this issue. :P

...

I'm with Dan on this one, I've never thought those validator buttons are very nice additions to a website. Remind me a little too much of the "Optimized for NN4" buttons of old.

I think there's a pretty big difference between providing a feature whereby a user can validate the HTML they've just authored and proclaiming browser patronage.

Most of our users won't know or care whether their pages validate. Those that do presumably know how to use a validator already.

-Chad

On 11-08-09 04:01 PM, John Elliot wrote:

On 10/08/2011 8:55 AM, Chad wrote:

...

Most of our users won't know or care whether their pages validate. Those that do presumably know how to use a validator already.

Isn't an unstated goal of MediaWiki/Wikipedia to decrease ignorance?

If you already know how to use a validator you might still be pleased to have it easily integrated for you.

WikiText != (X)HTML

<br> -> <br /> <ul> -> nothing (user generated empty lists are killed) <script></script> -> &lt;script&gt;&lt;/script&gt; <b>a<i>b</b>c</i> -> <b>a<i>b</i></b><i>c</i>

In the interest of letting you output things like <div>s, and outputting things like lists with requirements that can't be fulfilled with the built-in syntaxes WikiText includes a SUBSET of HTML. Since it's impractical to re-invent the syntax for all of the stuff you may want to output into the content of your page. However we DO NOT just output this. Everything a user inputs is preprocessed and run though an entire parser. That <br>, the handling that decides that the end result of that should be a br tag in the right syntax for the XHTML or HTML5 output is the WikiText parser, not a html parser. WikiText is a loose syntax, and by the time (X)HTML is output that entire subset of HTML you have in your page has been parsed by MW's Preprocessor which has decided what (SG|HT|X)ML like structures should semantically mean and pieced together the markup. Incorrectly formed html will already have been re-formed to be correct and only interpretable one way. WikiText is loose so instead of errors, if the parser doesn't like something you inputted it's not going to pass that through raw and let a html validator say it's wrong, it's going to decide it doesn't like it and treat it as plaintext. By the time the parser is done with your input MediaWiki will have already re-formed or rejected any of your errors in your page, and the last thing you'll care about is a html validator, it'll be the way your page looks after MediaWiki has rejected tags and outputted some tags as plaintext.

Frankly... Fixing our abuse of : (definition lists) for talk page indentation is probably a higher priority than getting the few things like use of obsolete valign attributes that will cause a validator to revolt to validate.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On 11-08-09 05:03 PM, John Elliot wrote:

On 10/08/2011 9:49 AM, Daniel Friesen wrote:

...

WikiText is loose so instead of errors, if the parser doesn't like something you inputted it's not going to pass that through raw and let a html validator say it's wrong, it's going to decide it doesn't like it and treat it as plaintext.

Well, the validation feature that I added to my web-site helped me catch a bug for you.

If you are outputting WikiText that includes the HTML-like <h1>, <h2>, etc., tags, then make sure you're not outputting them in the context of table content, because that is invalid. In order to turn such WikiText into compliant HTML, the <h1> WikiText should be converted to a <span class="h1"> HTML element, and so forth. The various skins should be updated to do something sensible with the h* classes.

<h#> tags are not invalid inside of table contents. <tr>'s contents are flow content, and <h#> tags are flow content.

<h#> tags are however invalid inside of <th> tags which are phrasing content. However in that context the correct thing would not necessarily be to turn the h# into a span, but fold it into the header that's already there. Which may or may not be what the user wants. Both of those changes can break a user's site styles.

Would you like to argue for a $wgStricterParsing bool that will sacrifice parser output consistency for things like folding == headers into parent th's (perhaps turn into a span if they explicitly use a <h#> instead of ==), and other things we haven't been able to do to the parser for compat reasons?

I'll let you know if my HTML validator helps me to easily catch any other bugs like this for you.

We've already established that MediaWiki is broken because it's outputting empty <ul> elements, so maybe you can have a look at fixing that up too.

That was a HTML4/XHTML1 rule that's been removed. An empty <ul></ul> is valid HTML5. Wikipedia is just currently set to output an XHTML DOCTYPE and well-formed XML output because of some bots that still use screen-scraping content that were given a second chance to have their developers fix them to use the api before HTML5 is turned on permanently.

Thanks.

John.

On 10/08/2011 11:19 AM, Daniel Friesen wrote:

Would you like to argue for a $wgStricterParsing bool that will sacrifice parser output consistency for things like folding == headers into parent th's (perhaps turn into a span if they explicitly use a<h#> instead of ==), and other things we haven't been able to do to the parser for compat reasons?

Sure. I'll argue for that. :)

That was a HTML4/XHTML1 rule that's been removed. An empty<ul></ul> is valid HTML5.

I wasn't sure if the empty <ul> was valid HTML5, or if the validator wasn't strict enough about it yet. In any event, I'm happy to take your word for it. If XHTML support is being deprecated, I won't argue for fixing the empty <ul> elements. As I mentioned, the only two features that were a concern for me in providing valid HTML(5) were the two meta elements, and it's been suggested that each of these can be removed.

I still think that having 'link' and 'top' anchors on section headings next to edit links would be a good thing to have on by default in core. There is provision for disabling them, and having them available by default is a sensible and productive course of action in my opinion. It's handy to be able to right-click on the 'link' anchor and copy the canonical URL of the section you're looking at, and it's handy to be able to jump back to the top of the page (indeed, I discovered that the #top functionality was already half implemented, so presumably there is a plan for something like this).

On 10/08/2011 12:19 PM, Daniel Friesen wrote:

Oh right, one the 'other' things I had one mind but couldn't remember while writing was converting things like valign, width/height, etc... into css styles.

That'd be nice.

Though given the fact that block content in a th in XHTML was valid and is essentially a regression in the unfinished html5 and there is an open bug report on it I'll opt for the stance that folding headers there should wait till we see what the decision on that is.

I'm happy with that. As I tried to point out in my first post, the whole HTML validation icon was just a bit of fun (it pleased at least one person [1] :P), and the feature I actually care about is the extended section edit links.

[1] http://www.progclub.org/wiki/User_talk:Sclaughl

John Elliot wrote:

...

That was a HTML4/XHTML1 rule that's been removed. An empty<ul></ul> is valid HTML5.

I wasn't sure if the empty<ul> was valid HTML5, or if the validator wasn't strict enough about it yet. In any event, I'm happy to take your word for it. If XHTML support is being deprecated, I won't argue for fixing the empty<ul> elements.

Those <ul> are an old discussion https://bugzilla.wikimedia.org/show_bug.cgi?id=24500

* Daniel Friesen wrote:

Embarrassing? You do realize that the validator is complaining that it sees `<ul></ul>`, right? I can't even find the spot in the HTML4 or XHTML1 spec where it says that a perfectly fine marked up list is invalid if it doesn't contain any items.

http://www.w3.org/TR/html4/struct/lists.html#edef-UL defines it as taking `(LI)+` as content, where `+` means "one or more".

On 11-08-09 04:14 PM, John Elliot wrote:

On 10/08/2011 9:08 AM, Daniel Friesen wrote:

...

I can't even find the spot in the HTML4 or XHTML1 spec where it says that a perfectly fine marked up list is invalid if it doesn't contain any items.

Well you could save yourself some trouble and let validator.w3.org guide you in that matter.

Guide? You mean link to that information so I have the actual words of the spec that browsers are supposed to implement? It doesn't give any link. You mean take the validator's interpretation as the absolute an unequivocal authority that it's wrong without seeing the information in the actual spec saying it's wrong? Like hell... If I accepted a validator's narrow (potentially incorrectly implemented) interpretation of something I wouldn't be using CSS vendor prefixes like -moz-border-radius since last time I checked the css validator says they're wrong, even though vendor prefixes are a valid part of the spec.

That's actually a pretty good direction to take explaining the fallacy of validators and badges for them. Our css includes output like: .foo { background-image: url(data:...); background-image: url(...) !ie;} Strict interpretation wise, that's invalid css because !ie is not valid inside the background-image. Are we going to remove that? Hell no, if we did versions of IE people are still using would stop displaying background images because they can't handle data uris.

Likewise with HTML what matters is NOT that a strict validator says it's ok, but that it's well-formed so that all browsers have the same interpretation of it, and conforms to understandable patterns either de-facto or detailed in external specs (like the RSD spec, Universal Edit Button, etc...). eg: EditURI is part of RSD [Really Simple Discovery], it's a standard way of letting software discover the api endpoint(s) for a page. In the future not having that could mean that a tool one of your users may use could break because it can't find the api.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]