Slashdot Mirror

Ian Hickson: About ten years from now, the de facto Web application standard will be Microsoft's Avalon and the .NET framework. (See Microsoft's position paper if you doubt that this is what Microsoft has planned for us.)

*shivers

Anyone who cares about the browser that 80% of the population will continue to use (because they don't know any better, because their bank only works with IE, because...). That includes anyone trying to implement a successful web technology - see Ian Hickson's weblog entry about a paper submitted to the W3C by Mozilla and Opera (Hixie is employed by Opera, sits on two or three W3C working groups and does QA for the Mozilla Foundation).

The situation is this:

Internet Explorer may never be updated. Sure, the longhorn version might get tabs and good history and bookmarks handling, and so on, but there are suggestions that the renderng engine won't be changed one whit. On the other hand, it wouldn't be surprsng if there were some way to render XAML pulled off the web.

This means that any non-proprietry future development of the web has to deal with IE as itt stands now. If the tech doesn't work in IE, people won't use it.

This quite clearly sucks. Microsoft's monopoly is destroying innovation (surprise!). But there's nothing that can realistically be done about it unless people can somehow be convinced to swtch from IE. Which they can't because it's 'good enough' (and will be 'better good enough' once it gets a lick of paint, even if it's still, fundamentally, a broken piece of shit).

i usually recommend a sctrict-dtd.

I moved my site back to Transitional when I found a bug in the W3C's Strict DTDs, namely that the value attribute of the li element was removed on a mistaken notion that value was presentational rather than semantic. Thus, HTML 4 Strict and XHTML 1 Strict make it impossible to start a list anywhere other than 1, a, or i. No, "use CSS instead" is not an option because the list will start on the wrong number in UAs such as Lynx that don't support CSS in general or that particular CSS property in specific. I find the starting number of a list a semantic datum rather than a presentational one; if I wanted to number items from 1 to 10 in the first part of a document and 11 to 25 in the second, would displaying them as 1 to 10 and 1 to 15 be correct? No.

I moved my site back to HTML 4 when I found that 1. Microsoft Internet Explorer 6 doesn't provide a default XHTML stylesheet for documents that specify the XHTML namespace, and 2. XHTML sent with Content-type: text/html causes some serious problems.

By the way, I do xhtml 1.1 strict, no tables.

Then either you're serving your pages with the wrong MIME type, or they can't be seen in IE at all.

You're not supposed to serve XHTML 1.1 as text/html: you should use application/xhtml+xml. See the W3C's XHTML Media Types. If you're labelling your XHTML 1.1 as text/html, then your browser isn't treating it as XML (note that Mozilla is using Quirks mode, for instance).

Snag is, Internet Exploder (to IE6SP1) doesn't know what to do with application/xhtml+xml, even though there's been a built-in XML parser since IE5, and application/xhtml+xml was defined in RFC 3236 over 2 years ago (and was presumably floating around the standards track for some months before that). But don't worry: just remember that Internet Explorer 6 SP1 gives you the freedom to experience the best of the Internet. At least, that's what it says on the box.

Assuming you're not prepared to be held hostage to the Great Beast, the best workaround at the moment seems to be to use Apache's content negotiation (MultiViews) to lie to IE (and anything else that doesn't know about application/xhtml+xml) that you're giving it text/html.

There's more on this here and here.

Surely it's about time for Slashdot to go XHTML+CSS?

I sure hope not.

XHTML sent as text/xml is unsupported by 95% of the browser market. Sending XHTML as text/html works in many cases, but is an even worse idea because agents that XHTML as HTML wind up interpreting something that is neither correct XHTML or HTML.

On the other hand, there's little wrong with HTML 4.01.

So, has anyone heard of a word processor that has an XML file format that contains all its binary data?

Does there need to be an implementation? XHTML has supported this since it was first published (Jan 2000, not including public drafts).

Specifically, you embed the binary data using the data: URL scheme, so, for example, you would write:

<img src="data:image/jpeg;base64,ggifudghifudgdfig">

The data: URL scheme RFC was published in August 1998. However, to my knowledge, the only implementation was first created six months ago (the Opera web browser).

While XForms may have its place, a much more useful and practical extention to standard HTML forms is Webforms 2.0. It more or less solves the 80% most common client-side validation tasks without adding a lot of complexity. This is a standard that will be intuitive to the average web developer, who is likely to be able to use it properly with a minimum of fuss. XForms is hugely compilicated in comparison, though it does solve a much bigger problem.

Additionally, according to an Opera developer, Webforms 2.0 has a good chance of being implemented in web browsers (meaning Opera and mozilla, I'd guess).

While XForms may have its place, a much more useful and practical extention to standard HTML forms is Webforms 2.0. It more or less solves the 80% most common client-side validation tasks without adding a lot of complexity. This is a standard that will be intuitive to the average web developer, who is likely to be able to use it properly with a minimum of fuss. XForms is hugely compilicated in comparison, though it does solve a much bigger problem.

Additionally, according to an Opera developer, Webforms 2.0 has a good chance of being implemented in web browsers (meaning Opera and mozilla, I'd guess).

As far as an ol starting at something other than 1--such as ten (and possibly counting down), I really don't know

This is a bug in the Strict specifications. W3C mistakenly deprecated the value attribute of the li element in HTML 4 and carried the mistake through to XHTML 1.0. That's why I'm sticking with Transitional DTDs, where the attribute is still present (though deprecated). I'm sending HTML 4+CSS rather than XHTML+CSS to the client because IE can't read XHTML, and HTML is different enough from XHTML to make writing a document that's valid in both languages nearly impossible, especially with the script/style escaping issue and the SGML SHORTTAG issue.

The designer hardcoded a fontface because CSS doesn't automatically resize columns like tables do.

Er, 'fontface'? WTF is a 'fontface'?

As for CSS resizing automagically, resize in relation to what, pray tell? A box with width: 30%; resizes in relation to the viewport, a box with width: 15em; resizes in relation to font size, as of CSS 2.1 a box with float: left or float: right and no width resizes in relation to content (most browsers--including IE/Win--do this anyway) and table-layout will get you table-style layout with whatever tags you like. MS just didn't feel the need to support it in IE 5/Win or IE/Mac so people don't use it much. That's Microsoft's fault, not the W3C's

Because CSS was designed by doofus eggheads and not experts in solving real world web design problems.

Ian Hickson edited the CSS2.1 spec, and he's been 'solving real world web design problems' since at least 1998 when I worked with him at the Web Stanards Project. Hakon Wium Lie edited CSS 1, 2 and 2.1 and has been working on Opera since 1999, earned an MS in Visual Studies from MIT and wrote his thesis on electronic display of newspapers. TantekCelik is responsible for the widely-lauded Tasman rendering engine used in IE 5.x/Mac. These people do use this stuff in the real world, and if you don't like the directions they're taking your'e free to join the www-style discussion list and let them know.

Which then forces me to do a bunch of work

One line of CSS is 'a bunch of work'? I suppose you find tying your own shoes a pretty onerous task as well?

or accept undesirable browser settings

Let me get this straight: you're hacked because the site doesn't use your settings for font size and face, but setting your browser to override the site's settings with your choices is 'undesirable'? Huh?

If XHTML, there are some things to consider:

It's important to note that using XHTML 1.1 requires you to send your documents as XML. This means the document should have an XML declaration above the doctype, and needs to be sent with an XML mime-type, ideally application/xhtml+xml. This has a significant drawback; IE can't see it.

A fairly well established workaround is to use mod_rewrite and munge the mime-type of a document based on what a user agent sends in its Accept header (To date, Mozilla is the only browser to include application/xhtml+xml in its Accept header). However, some would argue that this too has drawbacks. Since only Mozilla understands application/xhtml+xml, your documents will be sent as text/html, and XHTML does not validate as HTML.

The arguments around this issue have been summarized in the widely linked "Sending XHTML as text/html Considered Harmful"

There's also more volunteers than the early days, not just with coding and testing, but with user support too, such as the excellent Mozilla Firebird and Thunderbird Help sites.

But in reality to the end user, it does not matter how many people are developing it, it's the quality of the product that counts, and I think that with recent releases there's nothing that can beat Mozilla in all round usefulness. If you've not tried it for ages then it's worth a try now, features like type ahead find, tabbed browsing and of course pop-up blocking make it an excellent product and make using IE a painful process. The fact is on any platform IE looks like the third rate choice, if you don't like Mozilla then there's always Opera, although personally I hate the interface to it - but others will disagree, choice is good, and having a situation where more people try alternative browsers is good for making sure we don't get tied into a Windows (i.e. IE) only web.

Ian Hickson makes a good case here that using XHTML may not be the right direction to go -- at least at this point.

(IE also doesn't use "tag soup" to render anything, but that's beside the point. Your DOM shit will still work.)

wtf are you ranting on about? The DOM is one of the things that works differently depending on if it's HTML/tag soup or XHTML.

As for IE not rendering tag soup, take a look here.

Why are we using xpcom considering the huge bloat/threading issues on non-win32?

Why do the signatures on our api make almost no sense to outsiders?

Why do we compare our performance almost exclusively to IE?

If Apple wont use our code because it's too big, do we have any real chance of being used on small devices?

Why are we still using xul now that we ifdef out platform-specific ui code?

I'm sure there are more questions that someone more knowledgable than I am can come up with, but these are questions that haven't been taken very seriously up to now, because there has not been a high-profile alternative to gecko.

I've been using mozilla/phoenix for several years (I've even submitted a few patches), and I think it's an absolutely amazing peice of software, but it *is* huge and hard to understand. It is hard to recognize the size and complexity for what it is without a highly visible comparison like khtml.

Actually, IE6 does a decent job. Their DOM1 support is good, their CSS1 is more or less complete, but their CSS2 is pretty crappy. Fixed positioning doesn't work, selectors like E[attr] are missing, etc.

Lately I've been working on an app for a company's internal use, which means the delightful situation of being able to dictate minimum browser requirements. As a result, the app is designed for IE6/Mozilla. All development has been in Mozilla, and a lot of DOM use goes on. And it all works in IE6, no browser checking anywhere. My only regrets is I can't make use of the more advanced selectors provided by CSS2, so the HTML has a few more class attributes than it would need otherwise. But, overall, not bad.

Another positive note, IE6 SP1 finally supports XHTML sent as text/xml. So at last, XHTML documents can be sent with the proper mime type.

So despite being a Mozilla (Galeon) user, as a web developer who makes heavy use of modern standards, I look forward to seeing IE continue to catch up to Mozilla so that I can worry even less about browser-specific issues.

Because if you serve XHTML to IE 5.x or 6.x under the application/xhtml+xml content-type, IE will render it not as an XHTML page but in a form more similar to source code: an XML tree.

That's quite simply an awful reason.

Actually you can define your content-type and encoding via META tags. In fact, that's exactly what the w3 recommends you do!

You are refering to the XHTML standard, appendix C. "This appendix is informative", which means that a contradiction with other standards should be resolved in favor of said standards.

The META tags are (supposed to be) read by the HTTP server so as to send the right encoding in HTTP headers; and my point was that, contrarily to what the XHTML standard implies, they cannot replace the ?xml declaration if the actual encoding is not UTF-8/UTF-16.

Therefore, if one is to stick with XHTML and try not to break older browsers, the document must be UTF-8 or UTF-16 (or ASCII, of course, since it is a subset of UTF-8). This is not my encoding of choice, so I call it bugware.

Furthermore, some of the links posted elsewhere in the thread (e.g. "Sending XHTML as text/html Considered Harmful") are quite interesting in that they point out that valid XHTML sent as text/html will be parsed as tag soup (since it is not HTML), negating any advantage such as using an XML parser. But backwards compatibility imposes that the content-type be text/html. HTML4, at least, doesn't have this problem.

Sure XHTML+CSS is easier on the browser, and that may help rendering issues. However, the reality is that old browsers will be with us for a while.

• Run the browser buster
• Visit any weird and unusual pages you know
• Try running some of Hixie's tests
• Explore various options in the preferences and experiement with different settings

Konqueror will soon come to a roadblock. Their HTML layout code it uses takes shortcuts that prevent them from implementing interesting things like DOM access to CSS, DOM animation, and even HTML 4.0. Let's take a short tour, of test cases that have been developed by the W3C, and some for testing Mozilla:

• Does Konq grok Basic CSS1 font properties? Not quite.
• Backgrounds on line boxes? No.
• Word spacing? No.
• FLoat and clear? Ack, dataloss!
• How is Konq's whitespace handling? Terrible!

• Does Konq understand Simple CSS borders?: No.
• Does Konq know how to Render styled tables? Not really.
• Does Konq have a robust CSS parser? Not by a long shot.
• Can Konq Style the HTML and body elements? No.
• What about Positioning the background image?. Eh, no.
• Z-index? Not.

Prefer some real-world sites? How about a site for HTML writers who are sick and tired of broken browsers like Konqueror? Here's something totally stupid, but cool. How about another goofy test that Konqueror butchers?

Mozilla has a large set of tests that it fails, too, but it is much smaller than Konqueror's. As a web monkey today, supporting Konqueror is in the same league as supporting Netscape 4.7. If Konqueror ever becomes standards-compliant, then it will be useful, but until then it will be just another on a large pile of browsers that are getting left behind by new, innovative content.

Konqueror will soon come to a roadblock. Their HTML layout code it uses takes shortcuts that prevent them from implementing interesting things like DOM access to CSS, DOM animation, and even HTML 4.0. Let's take a short tour, of test cases that have been developed by the W3C, and some for testing Mozilla:

• Does Konq grok Basic CSS1 font properties? Not quite.
• Backgrounds on line boxes? No.
• Word spacing? No.
• FLoat and clear? Ack, dataloss!
• How is Konq's whitespace handling? Terrible!

• Does Konq understand Simple CSS borders?: No.
• Does Konq know how to Render styled tables? Not really.
• Does Konq have a robust CSS parser? Not by a long shot.
• Can Konq Style the HTML and body elements? No.
• What about Positioning the background image?. Eh, no.
• Z-index? Not.

Prefer some real-world sites? How about a site for HTML writers who are sick and tired of broken browsers like Konqueror? Here's something totally stupid, but cool. How about another goofy test that Konqueror butchers?

Mozilla has a large set of tests that it fails, too, but it is much smaller than Konqueror's. As a web monkey today, supporting Konqueror is in the same league as supporting Netscape 4.7. If Konqueror ever becomes standards-compliant, then it will be useful, but until then it will be just another on a large pile of browsers that are getting left behind by new, innovative content.

Konqueror will soon come to a roadblock. Their HTML layout code it uses takes shortcuts that prevent them from implementing interesting things like DOM access to CSS, DOM animation, and even HTML 4.0. Let's take a short tour, of test cases that have been developed by the W3C, and some for testing Mozilla:

• Does Konq grok Basic CSS1 font properties? Not quite.
• Backgrounds on line boxes? No.
• Word spacing? No.
• FLoat and clear? Ack, dataloss!
• How is Konq's whitespace handling? Terrible!

• Does Konq understand Simple CSS borders?: No.
• Does Konq know how to Render styled tables? Not really.
• Does Konq have a robust CSS parser? Not by a long shot.
• Can Konq Style the HTML and body elements? No.
• What about Positioning the background image?. Eh, no.
• Z-index? Not.

Prefer some real-world sites? How about a site for HTML writers who are sick and tired of broken browsers like Konqueror? Here's something totally stupid, but cool. How about another goofy test that Konqueror butchers?

Mozilla has a large set of tests that it fails, too, but it is much smaller than Konqueror's. As a web monkey today, supporting Konqueror is in the same league as supporting Netscape 4.7. If Konqueror ever becomes standards-compliant, then it will be useful, but until then it will be just another on a large pile of browsers that are getting left behind by new, innovative content.

Konqueror will soon come to a roadblock. Their HTML layout code it uses takes shortcuts that prevent them from implementing interesting things like DOM access to CSS, DOM animation, and even HTML 4.0. Let's take a short tour, of test cases that have been developed by the W3C, and some for testing Mozilla:

• Does Konq grok Basic CSS1 font properties? Not quite.
• Backgrounds on line boxes? No.
• Word spacing? No.
• FLoat and clear? Ack, dataloss!
• How is Konq's whitespace handling? Terrible!

• Does Konq understand Simple CSS borders?: No.
• Does Konq know how to Render styled tables? Not really.
• Does Konq have a robust CSS parser? Not by a long shot.
• Can Konq Style the HTML and body elements? No.
• What about Positioning the background image?. Eh, no.
• Z-index? Not.

Prefer some real-world sites? How about a site for HTML writers who are sick and tired of broken browsers like Konqueror? Here's something totally stupid, but cool. How about another goofy test that Konqueror butchers?

Mozilla has a large set of tests that it fails, too, but it is much smaller than Konqueror's. As a web monkey today, supporting Konqueror is in the same league as supporting Netscape 4.7. If Konqueror ever becomes standards-compliant, then it will be useful, but until then it will be just another on a large pile of browsers that are getting left behind by new, innovative content.

Konqueror will soon come to a roadblock. Their HTML layout code it uses takes shortcuts that prevent them from implementing interesting things like DOM access to CSS, DOM animation, and even HTML 4.0. Let's take a short tour, of test cases that have been developed by the W3C, and some for testing Mozilla:

• Does Konq grok Basic CSS1 font properties? Not quite.
• Backgrounds on line boxes? No.
• Word spacing? No.
• FLoat and clear? Ack, dataloss!
• How is Konq's whitespace handling? Terrible!

• Does Konq understand Simple CSS borders?: No.
• Does Konq know how to Render styled tables? Not really.
• Does Konq have a robust CSS parser? Not by a long shot.
• Can Konq Style the HTML and body elements? No.
• What about Positioning the background image?. Eh, no.
• Z-index? Not.

Prefer some real-world sites? How about a site for HTML writers who are sick and tired of broken browsers like Konqueror? Here's something totally stupid, but cool. How about another goofy test that Konqueror butchers?

Mozilla has a large set of tests that it fails, too, but it is much smaller than Konqueror's. As a web monkey today, supporting Konqueror is in the same league as supporting Netscape 4.7. If Konqueror ever becomes standards-compliant, then it will be useful, but until then it will be just another on a large pile of browsers that are getting left behind by new, innovative content.

Konqueror will soon come to a roadblock. Their HTML layout code it uses takes shortcuts that prevent them from implementing interesting things like DOM access to CSS, DOM animation, and even HTML 4.0. Let's take a short tour, of test cases that have been developed by the W3C, and some for testing Mozilla:

• Does Konq grok Basic CSS1 font properties? Not quite.
• Backgrounds on line boxes? No.
• Word spacing? No.
• FLoat and clear? Ack, dataloss!
• How is Konq's whitespace handling? Terrible!

• Does Konq understand Simple CSS borders?: No.
• Does Konq know how to Render styled tables? Not really.
• Does Konq have a robust CSS parser? Not by a long shot.
• Can Konq Style the HTML and body elements? No.
• What about Positioning the background image?. Eh, no.
• Z-index? Not.

Prefer some real-world sites? How about a site for HTML writers who are sick and tired of broken browsers like Konqueror? Here's something totally stupid, but cool. How about another goofy test that Konqueror butchers?

Mozilla has a large set of tests that it fails, too, but it is much smaller than Konqueror's. As a web monkey today, supporting Konqueror is in the same league as supporting Netscape 4.7. If Konqueror ever becomes standards-compliant, then it will be useful, but until then it will be just another on a large pile of browsers that are getting left behind by new, innovative content.

Konqueror will soon come to a roadblock. Their HTML layout code it uses takes shortcuts that prevent them from implementing interesting things like DOM access to CSS, DOM animation, and even HTML 4.0. Let's take a short tour, of test cases that have been developed by the W3C, and some for testing Mozilla:

• Does Konq grok Basic CSS1 font properties? Not quite.
• Backgrounds on line boxes? No.
• Word spacing? No.
• FLoat and clear? Ack, dataloss!
• How is Konq's whitespace handling? Terrible!

• Does Konq understand Simple CSS borders?: No.
• Does Konq know how to Render styled tables? Not really.
• Does Konq have a robust CSS parser? Not by a long shot.
• Can Konq Style the HTML and body elements? No.
• What about Positioning the background image?. Eh, no.
• Z-index? Not.

Prefer some real-world sites? How about a site for HTML writers who are sick and tired of broken browsers like Konqueror? Here's something totally stupid, but cool. How about another goofy test that Konqueror butchers?

Mozilla has a large set of tests that it fails, too, but it is much smaller than Konqueror's. As a web monkey today, supporting Konqueror is in the same league as supporting Netscape 4.7. If Konqueror ever becomes standards-compliant, then it will be useful, but until then it will be just another on a large pile of browsers that are getting left behind by new, innovative content.