On Wed, Jul 8, 2009 at 10:58 AM, William Allen
Simpson<william.allen.simpson(a)gmail.com> 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<sergey.chernyshev(a)gmail.com> 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.