On Wed, Jul 8, 2009 at 10:58 AM, William Allen Simpson<[email protected]> wrote: > Remember Postel's robustness principle (paraphrased): > > be conservative in what you send, liberal in what you accept
This applies only if there's some reason to be conservative. There's no reason to arbitrarily send only a subset of possible markup if every browser that supports that subset will support the full range of markup as well. Restricting ourselves to HTML 4 based on the principle of being conservative in what we send makes no more sense than restricting ourselves to, I don't know, class names that contain only the letters z, f, and q. It won't increase compatibility -- it's just a pointless inconvenience. > If quotes are always permitted, then always send the quotes. > > If closing tags are always permitted, then always send the tags. > > The browsers will handle them, and we don't need to worry about the > flavor of browser. There is *no* flavor of browser that requires quotes or closing tags. None. I'd be willing to bet there's not a single one released in the last ten years that ever attained more than 0.1% overall market share, say. Any browser that did things like requiring quotes or closing tags would *completely* *break* the web. It wouldn't display a majority of websites correctly, and nobody would use it. This is a fact. (In any event, HTML 4 doesn't require either quotes or closing tags in all circumstances, although it requires them more often than HTML 5 does.) > There's no need to over-optimize the output. The intended viewer isn't > human, and we're not talking about enough extra characters that very > slow links will be congested.... We're talking about a few percent difference in size, for almost no effort on our part. And I would say that it definitely is a slight plus if the HTML is more human-readable. What are the concrete downsides? > Great. Does that mean HTML 5 browsers will still accept formal HTML 4? > > Then, let's stick to the "stricter" interpretation. All browsers are "HTML 5 browsers" in the sense of not requiring quotes or closing tags when HTML 5 doesn't require them. Those parts of HTML 5 are just reverse-engineered from existing behavior that's been de facto standard since early in the IE-Netscape wars, at least. > My thought is that the 5 tags that are marked as well-supported could be > used, but be very cautious about abandoning 4. There are a lot of old > machines out there, and many cannot upgrade to newer browsers, because > they cannot upgrade their underlying operating systems. > > For example: schools, already heavy *pedia users. And political campaigns > often use cast-off machines. Win98 or 2K means no upgrades. Nothing I have proposed will have even the smallest negative impact on anyone's ability to view Wikipedia in a web browser, even with very old browsers. The only negative effect will be on non-web-browser users, who we don't want screen-scraping anyway. On Wed, Jul 8, 2009 at 11:15 AM, Sergey Chernyshev<[email protected]> wrote: > I'm only considering the projects I was going to work on and can't talk for > all the things MediaWiki team should have in mind - I was going to add > support for RDFa (http://www.w3.org/TR/rdfa-syntax/) which currently is W3C > Recomendation, but only for XHTML and even though HTML profiles (or whatever > they are called) are in the works they are not ready yet. > > Switching to non-recomendation will mean that implementing RDFa in standard > compliant form will have to be postponed for quite a while. I'm pretty sure this will be resolved within a matter of months, one way or another. Either Ian will cave and support RDFa, or RDFa will support HTML 5 (at least in a usable draft form) without HTML 5's explicit agreement, or microdata will gain support as wide as RDFa. At worst, you can still use MW 1.15 while things are being worked out. Or maybe we could provide a switch to allow HTML 5 or XHTML, but I'm leery of that, since it negates most of the benefits. I admit that I don't follow RDF and "semantic web" stuff too closely, so I'm not very qualified to address this objection. I'm pretty sure that RDFa support is not an issue for the overwhelming majority of our users, however. On the other hand, improved <video> support and better form handling for a significant percentage of our users are examples of clear and concrete benefits from HTML 5. Is this actually a *practical* problem even for the very small number of users who want to use RDFa? I mean, will RDFa really not work with HTML 5 in practice, or will it work but it's not standardized? > As for commotion I mentioned, I believe there is at least tension between > RDFa world and "Microdata" world that is being pushed along HTML 5 spec. Yes, there definitely is tension there! Just not between HTML 5 and XHTML 2 -- that's over, even if a few people might not have gotten the message yet. I don't know what will happen with RDFa vs. microdata. I find it unlikely that anyone will convince Ian to include RDFa at this point with just arguments. But if it sees much wider adoption than microdata, he'd probably include it. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
