On 10/08/2011 10:16 AM, Daniel Friesen wrote: > 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.
Why are you telling me? http://validator.w3.org/feedback.html > 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. If you'd seen Pirates of the Caribbean, you'd understand that there's a difference between rules and guidelines. Of course some of us take the guidelines rather seriously. > 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. Again, I think it's reasonable to engineer a system where policy decisions such as this are at the option of the user. I'm a user of MediaWiki, and I care more about strict compliance with open-standards than I do about supporting antiquated browsers, so I should be able to take the decision to not support that. > 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...). Again, there will be a class of MediaWiki users who have a different opinion. > 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. There is a process for this defacto standard to be integrated with web-standards, and by not supporting it until it has gone through that process you provide incentives for its proponents to ensure they do things in an amiable and collaborative fashion. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
