Slashdot Mirror

The Acid2 site itself is broken. Try the Acid2 author's website.

It shows up like that because of a misconfiguration on webstandards.org. (In particular, "not found" pages are served as 200 instead of 404.) Safari and Opera will show you the same thing. Hixie is trying to get it fixed.

The version of Acid 2 on the author's website works fine.

It does pass. The original Acid 2 test page http://www.webstandards.org/files/acid2/test.html accidentally got changed a bit (so that a missing link returns error code 200 instead of 404 not found). That's why FF (and other browsers like Safari and Opera) "fail" on that page. But see the mirrored page here http://www.hixie.ch/tests/evil/acid/002/ to verify that FF 3b2 (and Safari and Opera and IE 8... OOoops! can't test that one!) do pass...

For XHTML 1.1 to be valid, it has to be served with the application/xhtml+xml content-type.

This is not true. "Valid" means that it conforms to the syntax and structural requirements defined by the document type. An incorrect content type is a mistake at a completely different level, it's a mistake with HTTP, not the resource itself.

Because Internet Explorer doesn't recognize this content-type (even though it probably would have required 2 minutes of coding to add it)

That would have been a disaster. It takes a hell of a lot more than that to support XHTML, and if you lie by claiming your client supports it when it doesn't, you screw up things like content negotiation and the possibility of a replacement for doctype switching when Internet Explorer does implement XHTML.

And because you can't serve XHTML pages with the correct content-type to 90% of users

This is not true. There is more than one correct content type for XHTML. One of them, for XHTML 1.0 documents that conform to the HTML compatibility guidelines, is text/html, which is understood by Internet Explorer.

many experts insist that no one should be writing XHTML pages.

You are misrepresenting that document. It makes the case that XHTML as text/html is a bad idea, not that XHTML is a bad idea.

And I think the main problem that XHTML+CSS has had is Internet Explorer and its craptastic handling of CSS

Actually, I think the main problem XHTML+CSS has had is that Internet Explorer just doesn't support XHTML. For XHTML 1.1 to be valid, it has to be served with the application/xhtml+xml content-type. Because Internet Explorer doesn't recognize this content-type (even though it probably would have required 2 minutes of coding to add it) it will offer the user a download dialog when it is offered. And because you can't serve XHTML pages with the correct content-type to 90% of users, many experts insist that no one should be writing XHTML pages.

It's a mess.

XHTML has only been taken up quite recently in comparison to how long it's been about, and even then it's been implemented incorrectly. Most of us will have become accustomed to creating clean xhtml pages that rely on css for styling, however a vast majority of the web have, it seems, jumped the bandwagon without reading the fine print. I'll be the first to admit I was one of them thanks to numerious net articles, books and even lectures at university.

XHTML is a derivative of XML that uses html-like tags and syntax. When used correctly it will be parsed as XML. This was supposed to be the future - no more varying designs through different browsers or funny rendering quirks because the XML framework and the strict syntax rules prevent this. A page will do just this if the headers are set to 'application/xhtml+xml'. The problem comes in that most people are doing everything right but sending the wrong headers - 'text/html'. When this is done, your lean, tight xml markup becomes html and all the benefits that XHTML was supposed to bring are lost.

But what about the W3C validator I hear you say? Well, yes, it validates just fine because it is correct - but then it doesn't check if you've sent the right content headers as that isn't its job (they can be sent through the server before the page is even sent anyway). Go to an XHTML site, view the source and see how many have a meta content of 'text/html' - a lot I bet.

One major reason why XHTML has ultimately failed is that Internet Explorer hasn't implemented it correctly. I believe it does have the capacity but requires some funky server workaround, as the ' to '>' and putting in the right doctype header and .dtd.

I recommend you check out the following source which was written in 2002. This has been going on for a while - no wonder HTML5 is being considered.

http://hixie.ch/advocacy/xhtml

Wow. I hate you.

The working group is open to the public and costs nothing to join. If you don't like the state of HTML, come over and help make it better.

Why bother with allowing the HTML mimetype, if it has no advantages other than it's what was done in the past?

Because XHTML adoption has been slowed by a lack of backwards compatibility: you can't currently deliver XHTML in a standards-compliant way and expect it to work on anything other than a small minority of browsers. Sending the data with content type 'application/xhtml+xml' or whatever confuses the current installed base of internet explorer, making it an extremely bad idea, and probably unusable for general consumption sites for at least the next 5 years. See this excellent article for more reasons why this is a good idea.

After all, XHTML is currently considered harmful.

Sure, HTML includes browser-specific extensions, but if you do not use those, and instead HTML+CSS, you'll end up as more standards compliant than using XHTML with CSS and the wrong MIME type.

Why not? The site in the "homepage" link below your user name in your comment is http://chris.brimson-read.com.au/. Its content-type is text/html, not the correct application/xhtml+xml. Conforming user agents will process XHTML marked as text/html as tag soup, not XHTML.

And in HTML 4.01 Strict or XHTML Strict, how does one start an ordered list at any value other than 1, such as starting the track listing of Follow the Leader by Korn at the correct 13?

No it isn't. The page http://www.geekbiker.net/ is served with the content type text/html, not the correct application/xhtml+xml.

One question: In HTML 4.01 Strict, XHTML 1.0 Strict, or subsequent versions of XHTML, the value attribute of the li element is removed. So in these languages, how do you make an ordered list with values other than starting at 1 and increasing by 1? For instance, how would you express a top ten list where natural reading order of the elements is from the element numbered 10 to the element numbered 1 rather than from 1 to 10, or the track listing of Follow the Leader by Korn where the first element is numbered 13? Are people supposed to make lists with a dozen empty li elements that are styled display: none?

The mistaken deprecations of some attributes such as the value attribute of the li element are why I continue to use the Transitional DTD despite following the spirit of Strict. The inability of the web user agent with 80 percent market share to correctly interpret XHTML's correct DOCTYPE (application/xhtml+xml which results in a download rather than a displayed page), combined with the idiotic gyrations needed to incorporate CSS and script into an "appendix C" XHTML file due to the change from CDATA to PCDATA and the fact that XHTML served as text/html is actually tag soup, are why I continue to use HTML 4.01.

Well, CSS 3 selectors is done, so it should be supported by all web browsers.

No, it's not. It's been flagged for "Last Call" since the end of 2005 and is still aways from full recommendation status. CSS 2.1 (farther along, but similarly mired) to date is patchily implemented by all — some moreso than others, for various reasons — so why should one expect full support for this CSS3 Working Draft?

(Some do say the W3C is a bit byzantine, and yes, they are cranky about it. You, too, can be the judge of that.)

IE6/7 have all those weird box model problems with XHTML 1.0

No, IE can handle box model perfectly. It's XHTML it can't handle at all. You must be sending your pages as HTML (text/html) and you've put XML prolog in your HTML, which triggers quirks mode (you may think it's XHTML, but browsers see it as HTML with lots of syntax errors and bogus DOCTYPE).

obligatory hixie reference

Of course nevermind that VS2005 defaults to strict XHTML 1.1 code

You know, it would have been better if they hadn't. The problem is they make code that pretends to be XHTML, but it isn't. They still use the HTML mime type: sending XHTML with the text/html mime-type is bad. If they had stuck with XHTML 1.0 Transitional that would have been okay, because those specs make room for nasty browsers that don't support XHTML, but XHTML 1.1 should always be sent as application/xhtml+xml.

More on IE support for columns:

http://ln.hixie.ch/?count=1&start=1070385285

It's one of the oldest bugs in Bugzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=915

(It's marked helpwanted, so it looks like it'll remain for even longer)

More on IE support for columns:

http://ln.hixie.ch/?count=1&start=1070385285

I find that making sure you use a strict XHTML doctype definition, IE behaves remarkably well.

XHTML is not appropriate on Internet Explorer. I use XHTML 1.0 Strict on my site, but I also know that the vast majority of my regular visitors are using Firefox. I'd certainly never suggest using XHTML to make things easier on IE. You can get the same advantages, and avoid the complications, if you just use semantic-meaningful HTML 4.01 and CSS, making sure each validate.

Of course just because you can doesn't mean you should.

If it's not really changing anything, then why do it?

Uh... Hello, you said XHTML would force everyone to create well-formed documents.

Ok, so some people write bad XHTML. Fault THEM, not just anyone who chooses to implement XHTML when they don't necessarily have to.

Fault them, and IE, for letting them do it.

It does break things when sent as text/html. Not to mention it changes JavaScript when the page does get sent with the proper MIME type.

You're probably not as smart as you think.

Every day I see websites, blogs, wikis, forums, and other such software all claiming "XHTML compliance". And sure, for the most part, many of them are well formed and run throught the w3 parser just fine.

HOWEVER, the vast majority of them are _not_ compliant!

Why is this? While the _markup_ is fine, the content is not being sent with the correct _mime type_, invalidating the document before parsing can even begin.

You see, the vast majority of XHTML documents are sent with the text/html header. Think of the mime type as being like an envelope that the document is sent inside.* The browser, when it gets the envelope, decides what parser it is going to use to process the contents inside. And it sees text/html, and sends it straight off to the tag soup parser, the _HTML_ parser, NOT the XHTML one.

The relevant standards show that unless you are serving "HTML compatible" XHTML (this is XHTML 1.0 transitional), you are in violation of the standards by serving XHTML as text/html. And since everyone's favourite web browser, IE6 (and 7), do not support proper XHTML mime types, you're stuck with at most XHTML 1.0 transitional.

And then, given the problems outlined with serving XHTML as HTML anyway, you may as well just use HTML 4 strict or transitional (if you want iframes).

So what does this have to do with this issue? Well, sure the vast majority of websites on the 'net do not use XHTML. But maybe that's partly because the user agent space simply isn't ready for it. Fix the user agents, then the supposed XHTML software out there can become compliant, and from there you may see more people make the transition.

Note: I'm not in any way defending _all_ of the websites out there that don't use XHTML. Just some of them :)

* With apologies to Martyn Smith, whom I borrowed the analogy from :)

For development, I agree with you completely. Every page I author is written in a real XHTML templating language, but I do not serve XHTML. It's just not ready and serving XHTML as text/html is bad. Moreover, both the Gecko and WebKit developers recommend against serving XHTML and Trident (IE) doesn't support it.

tl;dr: XHTML is good for development, bad for serving and will remain that way till IE6 can be ignored.

One of the best texts I've read on this subject can be found here... http://www.hixie.ch/advocacy/xhtml

Yeah, technically the XHTML 1.0 spec allows to send documents with the text/html mime type, but please don't do it!

If you care about standards and want something readable by IE (which isn't always necessary), then better HTML 4 Strict than some XHTML Transitional sent as text/html (Gecko uses Standards Mode for the former and Quirks Mode for the latter).

The Acid2 test isn't a true test, it's more of a demo, aimed at the public. As a true test it is terrible: it mixes a bazillion things all at once. Debugging that kind of test is a nightmare. Opera engineers, for example, aren't working on fixing the Acid2 bugs directly: instead, I spent an hour or two minimizing the Acid2 test into eleven separate real test cases, which show the real bugs our latest code has with Acid2. These are the test cases that Opera engineers then work on.

when you install the AHEM font six out of seven pass.

It's great that IE7 users are getting some UI hotness

The W3C publishes their specs; Microsoft does not. If they did [emphasis mine], I'm sure the Mozilla folks would be more than happy to implement it. As it stands, they're forced to try and emulate some of IE's bugs and quirks in order to render poorly-written, IE-only pages correctly.

But as I pointed out earlier in the discussion, they generally haven't done this.

He said that if Microsoft published specifications for MS-HTML, MS-CSS, etc, Mozilla might do something about it. Microsoft leaves a lot of things undocumented, so pointing out that Mozilla hasn't been forthcoming with support for these things doesn't contradict what he said.

Historically, their attitude has been that they would support only the "official" (i.e., W3C and such) specs, and would not implement any concessions to IE compatibility.

This is not the case. Their main focus is obviously on standards, and if the standard way of doing something conflicts with the Microsoft way of doing something, they tend to pick the standard way. But Mozilla have implemented plenty of stuff in the name of compatibility with Internet Explorer. Off the top of my head, there's document.all, favicons, two quirks modes and XMLHttpRequest. I'm sure there's more.

For all the bitching some people have been doing in this discussion about MS not documenting anything, they've also been bitching about IE6 has been standing still for years. It's not like there's a moving target to emulate, and the main differences are well enough known that pro web developers use them on auto-pilot these days!

There's a difference between web developers being able to work around issues and browser developers being able to correctly emulate issues. Compare, for example Microsoft's documentation for hasLayout, and its reverse-engineered description. This one facet of rendering has huge implications on layout, yet it remained an undocumented mystery for five years and still hasn't been totally cracked. Or look at Hixie's description of the way Internet Explorer comes with a DOM tree that isn't actually a tree. Or look at Hyatt's description of the "residual style" problem.

Mozilla and other browser developers already spend plenty of time reverse-engineering Internet Explorer. Are you really criticising them for choosing to implement some standards stuff too rather than spending 100% of their time on reverse-engineering Internet Explorer's crazy behaviour?

Because of the way inheritance works. See http://ln.hixie.ch/?start=1070385285&count=1.

The problem isn't HTML vs. XHTML and passing self-closing tags as HTML, the problem is that 99.999% of people using XHTML content in their pages, are not sending the proper XHTML Content-type for those pages.

There is ONLY ONE valid Content-type for XHTML content, and that is application/xml+xhtml, not text/html.

Thankfully, MSIE doesn't even support XHTML at all, so we're safe there... for now.

This writeup is very clear on the matter.

Not a bug. Ian Hickson explains:

http://ln.hixie.ch/?start=1070385285&count=1

I never said code for a specific browser -- I said don't use XHTML. I'm a supporter of valid code, and the Any Browser Campaign, but I don't currently support XHTML, because there is better cross platform support for HTML4 than there is for XHTML 1, because XHTML is not directly compatable with HTML

You can write pages that will degrade gracefully under both XHTML and HTML -- but you can't write a valid XHTML page that will parse cleanly in IE, XHTML is not backwards compatable with HTML, due to the need of an XML declaration before the HTML doctype.

To get XHTML to work in browsers that don't directly support XHTML, you'll have to serve it as text/html, which can then cause problems which correctly support XHTML. more details at wikipedia.

You get better overall support in browsers by coding to HTML4.01 -- there are few advantages to the user to using XHTML 1.0 (it's easier on the browser code, that's about it). That's not true with XHTML 2, which offers better alternative text for images and objects, as well as more easily arranged sections and dramatically updated Web Forms, but I have no idea when we'll get browser support for it. (hell, we don't even have good support for CSS2, much less CSS3 in most browsers)

Does Opera pass the test without data URLs that is here? Safari sure doesn't. :(

As Internet Explorer has shown, having a solid JS DOM...

DOM Level 1 Core states that "The DOM presents documents as a hierarchy of Node objects". As IE/Win is capable of creating a node with two parents and creating a node whose parent is the child of one of its siblings - that is, a non-hierarchical structure - it can hardly be claimed that it has anything to teach anybody in this area.

(I'm aware that these effects are caused by invalid markup, and that other browsers also have problems agreeing on what to do; but the simple fact is that the DOM is defined as a tree, and IE/Win internally uses a data structure which is not a tree. So it's difficult to see how its DOM implementation can ever work properly.)

As Internet Explorer has shown, having a solid JS DOM...

DOM Level 1 Core states that "The DOM presents documents as a hierarchy of Node objects". As IE/Win is capable of creating a node with two parents and creating a node whose parent is the child of one of its siblings - that is, a non-hierarchical structure - it can hardly be claimed that it has anything to teach anybody in this area.

(I'm aware that these effects are caused by invalid markup, and that other browsers also have problems agreeing on what to do; but the simple fact is that the DOM is defined as a tree, and IE/Win internally uses a data structure which is not a tree. So it's difficult to see how its DOM implementation can ever work properly.)

As with most Google-related things, they've focussed on the interface, but skipped QA when it comes to the code they put out. Five minutes with a validator would have been enough to ensure that they output valid code, but it seems they haven't bothered.

I'm also surprised that they are generating XHTML rather than HTML. There's no benefit in this case, and given that Ian Hickson, author of Sending XHTML as text/html Considered Harmful, works for them, they should know better.

They use embedded <style> elements instead of simply linking to an external stylesheet - what a pointless waste of bandwidth. The default style reduces the font size by 15%, although they probably don't realise because it also uses Verdana. The visitors using other fonts are going to get very small text compared with the visitors using Verdana.

All in all, exactly what I'd expect from Google - decent interface, poor front-end code. They get a C.

I didn't RTFA, but: Just translate every "src",etc. attributes http:, https: ftp:, etc. into int's corresponding data: URI? It's not exactly hard, try it yourself at http://software.hixie.ch/utilities/cgi/data/data. The result is not /. comment compatible, but quite usable in html per se. Scripts and CSS can be embedded even easier.

For more see:

• The data: URI kitchen
• Wikipedia - data: URI scheme

Well, help users to understand, and teach them to use it correctly.

"Correctly" in this case meaning on private intranets and specifically not on the public World Wide Web, as all publicly available versions of the web browser with 85 percent market share do not read XHTML anywhere close to correctly. Microsoft Internet Explorer 6 doesn't display pages sent as application/xhtml+xml at all, and sending XML as text/html is considered harmful.

Or at least, don't write XHTML unless you really know what you're doing, and know to send real XHTML (application/xhtml+xml) to compliant browsers.)

Sending XHTML as text/html Considered Harmful. (Written by Ian Hickson, who's an editor of half a dozen CSS drafts, QA person for Mozilla, ex-QA for Opera, and nowadays works on 'HTML 5' (WHATWG web apps) for Google.)

Existing web is in html (and bad html at that).
ANYTHING offering 'web access' is going to support
the existing web.

Thus, HTML 5 is the future. Especially since xhtml isn't even supported properly in today's most used browser (ie. IE). And no, sending as html does not count and is even bad (yes, I'll change my own website to reflect this in the future).

Competant developers have been using xhtml and css for 10 almost years

Ignoring for a second how these standards haven't been out that long, hardly anyone is currently supporting XHTML strict properly anyway: using the correct MIME type. In short, if it works in Internet Explorer, it's the wrong MIME type, even if w3.org's validator says it's fine. No company is yet happy with the idea of their web site not working in IE, so they use the incorrect MIME type.

Incidentally, there's a version of XHTML intended specifically to make sites easy for mobile devices and such to swallow: XHTML Basic. From W3's site:

It is designed for Web clients that do not support the full set of XHTML features; for example, Web clients such as mobile phones, PDAs, pagers, and settop boxes.

I've never felt a need to use regular XHTML for my home projects, as XHTML Basic is more than enough, but I use the latter at work. Oddly enough, the article doesn't even seem to mention XHTML Basic.

Well, my biggest problem with that is that it doesn't take q values into account; I could accept application/xhtml+xml, but prefer text/html, a possiblity your script ignores.

The second problem is that you're lying about the page's content. Easily fixed with an s/1.1/1.0 Strict/ (please don't actually use this as there's a bit more to it than that); better fixed with some really simple XSLT (which is what I do on my website).

The third (potential) problem is that there are differences in the way CSS and Javascript work that can trip you up.

Unlike some, I have no objection to serving XHTML 1.0 as text/html (since it's explicitly allowed for if you follow Appendix C), but doing the same with XHTML 1.1 isn't allowed, and seems like nothing more than buzzword compliance. Unless you're using Ruby, the differences are pretty insignificant so you have no reason to anyways.

As long as IE doesn't understand application/xhtml+xml I see no reason to switch.

Read more about it here: Sending XHTML as text/html Considered Harmful.

I'm talking about things like the W3C's HTML reference or this page. I'm talking about stuff you'd bookmark and then spend a minute finding and then three minutes looking around on the site to find the specific bit of information you wanted.

The point of the method I spoke of is not to keep 'your' data. I agree, people who search for their own files need to be a bit better organized. It's to have a full-text search of a tiny, self-collected part of the internet, from whole websites to single sentences, and it will never be screwed up by search engines reranking things or pages going dead. All you have to do is say 'Hey, that's a useful page, File, Capture page' and continue on your way, and never worry abut it again, until you think 'Hey, what was that page that had...'.

Incidentally, Google desktop tries to index your browser cache for exactly this reason, but that is rather idiotic and doesn't work well as pages disappear from that but not the index. Turn that feature off.

And an added bonus, my bookmarking has gone down immensely, now only to pages with changing content, so now I can actually find things there, too.

As for the other stupid stuff in google desktop? Well, you can easily turn it off. Or you can find another tool that does the same thing for desktop searches, I'm sure they exist. The indexing tool is not important.

Ajax is the first genuinely new thing I can think of this century.

Because then you have to put in special detection code, because IE doesn't support it.

You also don't have to deal with the differences between xhtml in text/html vs. xhtml in application/xhtml+xml. (see Sending XHTML as text/html Considered Harmful)

I tried the whole XHTML for a while, but it's not worth the headache to try to support it as a developer until you have better support from the browsers.

I let someone else explain this one, but basically you should be using html 4.01 and not xhtml unless you really know what you are doing and have good reason to do so.
http://hixie.ch/advocacy/xhtml