Victor Engmark wrote:
> Davi Leal wrote:
> The third sends plain text as application/xhtml+xml.
This is the main test about XHTML. Tests whether application/xhtml+xml is
parsed with the tag soup parser. Note that about XHTML only
application/xhtml+xml is the recommended media type.
You can see at the below reference, that text/html is the only that works
well, but it is _not_ recommended.
Yep, but it works, today.
I am proposing to use "HTML 4.01 Strict", not HTML 5 which is not yet ready.
> My conclusion from these tests is that browsers are pretty lenient,
> and will parse XHTML as HTML if they don't support the former. How's
> that a good argument for HTML 5?
I am not proposing to use HTML 5 but "HTML
4.01 Strict", which is very well
supported on all browsers and devices!.
I know, I'm just refuting the statement you made before, "The reality is that mobile devices does not work with XHTML". Yes, most mobile devices don't work if you serve XHTML as application/xhtml+xml. But that's easy to fix, by sending it as text/html to the browsers which don't support application/xhtml+xml.
> By the way, the W3C did in fact not start the HTML 5 effort. That's done by
> WHATWG <http://www.whatwg.org/>. As of now, (X)HTML 5 are working drafts,
> while XHTML 1.0 has been a W3C recommendation since 2000.
I know W3C did not start it, but it seems they are all working now:
"W3C is pleased to announce the new HTML Working Group, chartered
to create the next HTML standard with the active participation
of browser vendors, ..."
Ref.: http://www.w3.org/html/
They are not working on HTML 5. The only references to HTML 5 on the
WG page were a
proposal for the WG to adopt it, and an
email from Microsoft explaining why HTML 5 should be adopted. Some of the statements (removed URLs in there) made the hair on my neck stand up:
- "Microsoft has always firmly backed compatibility - in its formats (
e.g. Office formats), operating systems (Win32 APIs), and browsers. On the IE team, we have had the same motto for every release I can remember back through IE4: Don't Break the Web."
- The absurdity of this (
OpenOffice.org conversion problems, NTFS write support, IE hacks, to mention a few) should be plain to us.
- "We (Microsoft) can't break the web that we support today, even if it is for a great cause like standards compliance and interoperability."
- You broke it in the first place, and are unwilling to fix it. Great.
- "We must remain 100% backward compatible, or we offend both our users and web developers in general."
-
At the cost of uncounted hours of extra work making web sites work in both IE and standards compliant browsers.
- "You can still run visicalc.exe on Windows Vista. That says something about compatibility."
- So you still have an ASCII compatible shell? How about the heaps of DOS programs that don't use ASCII graphics?
- "In the short run, this will mean they need to put some switch (probably a comment-based one, somewhat similar to IE conditional comments but a document-wide marker in the prolog). I don't like this, because it requires authors to opt in to standards-compliant behavior, and the default behavior is our current (broken) behavior - but that is exactly what we must keep shipping to not Break The Web."
- You will keep shipping broken web browsers, and don't like web developers making standard compliant sites.
- "Y'all better get working on that ActiveX support."
- "In short, I'm not that positive that HTML 5 will be the time we get it right for all time. I would suggest that we use <!DOCTYPE html5> [instead of <!DOCTYPE html>]"
-
That was the point of the whole email? Whew! Groundbreaking stuff!
OT, but I couldn't resist. IE is an abomination, and the sooner it's replaced by standard compliant browsers, the sooner we stop wasting time, code, bandwidth, and money.
Additional very interesting reference:
http://www.internetnews.com/xSP/article.php/3672011
Note: All that is _current_ information.
OK, so it seems like HTML5 will be a great improvement on what we've got now. How's that an argument for using HTML 4.01? The XHTML5 spec is developed with the HTML5 spec, and as far as I understand both of them will be very different from the current standards.
> > Using XHTML will lead to a number of desktop and mobile browsers being
> > unable to access the content.
> >
> > Unless you have some specific need which only XHTML 1.1 can fulfill,
> > "HTML 4.01 Strict" is the best bet today for universal support.
>
> I've used XHTML 1.1 for years, and by using HTTP Accept header sniffing
> it's easy to support all the browsers I've tried so far - IE6, Firefox
> 0.6+, and Opera 8+.
... all browsers *you have tried*. That is not universal support.
I know. I don't have the time to test against all browsers myself. I'm just following the recommendations I've read, and working the way I feel most efficient. In the end, maintainability of the code and usability of the site are the two things that matter most, and I believe XHTML helps both of these, indirectly, by enforcing a more rigid structure, and having simpler rules for that structure.
> The main reason I'm pushing for XHTML is simply that I think it'll make it
> easier for us in the long run to deal with other XML technologies, such as
> feeds, SVG, XForms, and others, and make it easier to maintain our
> _javascript_ and CSS.
The project must not lose the universal support just for "make it easier for
us in the long run to deal with XML technologies".
Anyway:
* HTML can <link> to feeds just like XHTML.
Never said it couldn't, but I was referring to embedding XML content in the markup.
* _javascript_ and CSS will work too.
Never said it wouldn't. But I still believe it's easier to maintain when dealing with a strictly hierarchical structure.
We could move to XHTML later, if needed, due to HTML 4.01 Strict is very
similar.
OK. Anyway, it's not that it's "needed", any more than I need a mouse for my PC.
> I just think it's a good idea that every page contains some instructions
> for how to contact the GNU Herds team, not anyone else.
Maybe it is a good idea. What address use for the contact information, the
association@ or the gnuherds-app-dev@ one?
If it's end users contacting us, we should probably use association, or create a new one for that purpose.