Well at this point it's important to note one of the things that HTML 5 is not: XML. HTML 5 is plain-old HTML, meaning it's syntactically forgiving (ie. case-insensitive elements and attributes, closing tags optional).
Actually, it's not plain-old HTML either. It's no longer based on SGML, HTML 5 defines its own parsing rules.
Can you imagine what Myspace would look like if everyone were required to use Strict XHTML or XML+XSL on their pages? Errors as far as the eye can see I'd wager
I wouldn't. Have you noticed that practically everybody using a custom page layout on MySpace uses a tool to do it? Jane Random Teen isn't writing HTML by hand. If any tool like that produced errors, people would simply use one that didn't.
Raw XML is learnable too, if somewhat inconvenient for beginners in its strictness when hand-editing.
Strictness isn't inconvenient for beginners, laxness is. The traditional laxness of HTML lets beginners twist their code further and further out of shape until when their code finally breaks, they've got so much to fix that they don't know where to begin. They just start hacking at it randomly hoping to change something that might have an effect. XML, on the other hand, has regular rules, and lets you know the second you screw up, so you don't get ahead of yourself, so you know which change it was that broke your page, so you have a chance of learning the rules.
Laxness has a reputation for being beginner-friendly because it enables beginners to speed ahead without really learning what it is they are doing. Thinking that's a good idea is short-sighted though, because as soon as they run into difficulty, they are already way out of their depth. Strictness is better in the long run.
Look: JPEG is patent encumbered; nonetheless, it is the standard. GIF was encumbered; nonetheless, it was the standard. Likewise MP3.
Well if we are applying this reasoning equally, then fine. No version of HTML requires browser vendors to implement JPEG. No version of HTML requires browser vendors to implement GIF. And now, the new version of HTML won't require browser vendors to implement MP3. Fair, yes?
It flat out isn't the place of a committee to define things out of public use because there is a commercial tie
And they haven't done any such thing. They haven't banned the use of MP3, they just aren't requiring browser vendors to implement it. In all likelihood, every major browser vendor that implements <audio> will include MP3 support. But "it flat out isn't the place of a committee" to force browser vendors to infringe on patents.
Personally I think that's a bad idea, since CLASS carries style information, not semantic information
This is a common misconception. The class attribute is intended for general purpose classification of elements, not merely as a style hook. The idea is that you classify your elements in a meaningful way (i.e. provide semantics), and then your stylesheets, scripts, etc, can use those semantics to manipulate the document in a useful way.
there's probably already a ton of documents out there using, say [...] and their owners are gonna be really surprised when browsers suddenly start parsing those classes in new and unexpected ways.
No, they wouldn't be parsed any differently, but they might be rendered differently.
A big advantage of XHTML was that the conversion to a parse tree was unambiguous.
It was unambiguous in SGML as well. The advantage XML had was that the tree was explicit in the document rather than being implied by a bunch of complex rules in the SGML standard and the external DTD subset.
I've seen a lot of people wrongly claim that forbidding things like <b><i>...</b></i> is an advantage of XHTML — are you making the same mistake? Such things are forbidden in HTML too, it's just people tend to get away with things like that with HTML because of its undefined error handling.
There are plenty of deprecated tags in HTML4 for instance.
People keep using them because W3C never bothers to explain what they were deprecated by
This is not true. The HTML 4.01 specification includes numerous explanations of what should be used instead of deprecated element types and attributes. I quote from the specification:
However, since style sheets offer more powerful presentation mechanisms, the World Wide Web Consortium will eventually phase out many of HTML's presentation elements and attributes. Throughout the specification elements and attributes at risk are marked as "deprecated". They are accompanied by examples of how to achieve the same effects with other elements or style sheets.
This specification includes examples that illustrate how to avoid using deprecated elements. In most cases these depend on user agent support for style sheets. In general, authors should use style sheets to achieve stylistic and formatting effects rather than HTML presentational attributes.
That doesn't make Internet Explorer support XHTML. It makes it automatically convert XHTML to HTML, which it does support. This is not the same thing. For example, try document.getElementsByTagName("HTML") in JavaScript. When applied to an XHTML document, that should return no elements. When applied to an HTML document, it should return the root element. Or try styling <tbody> elements. Unless you put them in explicitly, there won't be any in an XHTML document. In an HTML document, they are automatically implied for every <table> element.
What you are doing with the XSLT approach is covering up Internet Explorer's inadequacy by automatically transcoding to HTML on the client. Internet Explorer isn't seeing XHTML though, so if you attempt to use anything XHTML-specific, then it won't work. And if you aren't attempting to use anything XHTML-specific, then it's not worth bothering with XHTML in the first place, you might as well just use HTML.
Microformats are a good solution where a problem is domain-specific. HTML is extensible with mechanisms like the class attribute so that HTML doesn't have to include lots of element types that aren't useful to most people.
But when something is applicable to a wide variety of situations, the right place for it is in the HTML specification, not as an ad-hoc extension. Otherwise, you could just make the argument for every element type under the sun being replaced with <div class="..."> or <span class="..."> . At that point, you're just using the class attribute as a bodge to avoid new element types, not because it's a good idea.
Yeah, sure, it's nice that browsers don't have to be updated for microformats to work. But that doesn't mean it's good design to try to stuff everything under the sun into the class attribute. Sometimes the right place for something is in the HTML specification.
On the contrary, web designers should be messing with the HTML, as they are the ones most qualified to do it. I suspect you are using "web designer" as a synonym for "graphic designer", but they are really two separate roles.
A graphic designer should be responsible for how a website looks. He needs certain domain-specific knowledge, so that he doesn't do anything silly like assume that words take up a fixed amount of space, but he should be concerned with how things look and not touch code.
A web designer should then take that look and translate it into code. This involves writing both the CSS and the HTML, talking to the designer to get him to give him the graphics layered/sliced in particular ways, and so on. The web designer is responsible for the front-end, how the interface operates.
The web developer should then take the static pages that the web designer created, and "make them work". Turn them into templates, add business logic, pull data from the database, etc. The web developer is responsible for the back-end, how the application works.
I've worn all three hats from time to time, but the ideal situation is to have different people focusing on the different aspects. It's rare to get somebody qualified in more than one area, and when you let them into other areas, they tend to screw up. The bigger the business, the more people you add on the edges — further afield in the graphic designed direction is branding/marketing, and further afield in the web developer direction are DBAs and sysadmins. But dead centre is the web designer writing the code that makes an interface operate.
However, now you need narrower columns to maintain optimum readability (about 70 characters wide is how long an optimally readable column is).
The majority of the studies that say this were conducted with printed material, not with a screen. Of the couple of studies that were actually conducted with screens that I've seen, they assumed too much or measured the wrong thing (e.g. what makes you think that the number of characters matter, as opposed to the physical dimensions?).
If you have an adequate study for optimal line lengths for the web, I'd definitely be interested in reading it, but all the ones that seem to crop up in discussions like this aren't applicable or are flawed. I've been looking for a while, but I haven't found a sound basis for this "common knowledge".
It's basic page layout. I'm not just making this stuff up. It's the reason newspapers print in multiple columns.
I never said you were making anything up, I'm just pointing out that what is true for print is not necessarily true for the web.
There's a minority opinion in US circles that suggests that copying an executable, in order to use it, constitutes fair use.
It's not fair use, because copies of software that are made for the purpose of using it are not covered by copyright in the first place. The law is explicit about this:
Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:
(1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner
In short: It's not fair use (that's a different set of exemptions), but it is legal.
The XHTML specification includes input and output details
"Input and output details" is pretty vague.
so if something is received incorrectly within the scope of those details
The XHTML 1.1 specification doesn't include anything about content types at all. There's also a draft that mentions content types, but it says that text/html is suitable, so either way, according to the XHTML 1.1 specification, text/html is not wrong. It's wrong according to RFC 2854, but that isn't a question of validity.
it is not valid according to the specification.
No. "Valid" has a very precise meaning when you are talking about SGML or XML-based markup languages. It is not a synonym for "wrong", "buggy", "broken", or anything like that. An incorrect content type doesn't make something invalid.
Serving it up ROT13'd would also be considered invalid
Well of course it would — because it wouldn't be following the syntax requirements. That's what makes something invalid. I know it's tempting to slap the "invalid" condemnation on every type of error, but it's not true. There are different types of error.
Honestly, it supports XHMTL 1.1 about as well as it supports CSS 2.1. Are you really suggesting that they do something such as not support any of CSS 2.1 until they can support it all?
I don't see how you can think that is an analogous situation. CSS 2.1 doesn't have a different media type to older CSS specifications, so it's impossible to do content negotiation. Microsoft partially implementing CSS 2.1 doesn't lose you content negotation because it wasn't there in the first place.
Support for text/html was specifically removed from XHTML 1.1
No it wasn't. RFC 2854 was published before XHTML 1.1 was finished. Support wasn't intentionally removed, it just hasn't been added. Furthermore, as I mentioned above, it's in the process of being added.
While the linked document doesn't specifically state that using XHTML at all is a bad idea, I think it is implied
Do you agree that there's a world of difference between "implying" something and "insisting"?
I like this quote:
Assuming you are using XHTML 1.0 compliant to Appendix C (or have
otherwise checked that the XHTML 1.0 you send is compatible with Tag
Soup processors), then that's fine. All I am saying in this document
is that sending XHTML as text/html ONLY is harmful.
I think he intentionally, very clearly limited the scope of his argument to XHTML as text/html. He knows damn well that the merit of XHTML is a far more complex argument and that the only real answer is "it depends on your circumstances".
Furthermore, are you aware that the arguments in that document against XHTML 1.0/Appendix C being truly compatible with HTML 4.01 also apply to HTML 5, which is no longer an SGML application? Do you think that HTML 5 should get a new media type and that it shouldn't be labelled text/html?
However, I disagree with your assertion that text spilling over into a new column is not a good idea.
Well there are many reasons why designs suitable for print are unsuitable for the web, but there's a few very simple ones that apply in this case. Vertical space is infinite on the web. Horizontal space is unpredictable and almost always at a premium due to things like navigation bars and adverts also taking up horizontal space. As such, giving away horizontal space to gain vertical space, which is what multiple columns are for, is almost always exactly the opposite of what you want to do.
Of course, I'm speaking from a typically Western myopic attitude, I haven't worked with East-Asian languages, so what I say doesn't necessarily apply to languages with vertical writing systems.
It may not be often-requested, but how often would PRE or DFN or INS or SAMP be requested, yet they still exist in the HTML 4.01 and XHTML 1.0 standards?
They are mainly there through inertia. I'm certainly not arguing that having the facility for multiple columns would be a bad thing to have, just that it's not the anywhere near the priority critics make it out to be.
Also, CSS and HTML are not just for web design.
Sure, you're certainly right there. In fact, with CSS 3's multi-column facilities, it's possible to have a single column design for online viewing and multiple columns when it's printed out. As things like navigation bars can be hidden when printing out, this makes the limited horizontal space less of an issue.
The first that comes to mind is when you are using a small font size because you only want a certain number of characters of width per line, so a small font size requires lines with a shorter absolute width (in inches or cm, take your pick). Therefore, with a smaller font size, you will end up with many pages of text with lots of wasted paper--unless you add columns.
I don't follow you. You intentionally pick a small font size so that you get short line lengths, and then complain that the line lengths are too short for the page? Isn't that exactly what you intended to happen?
He said he wanted a 3-column liquid layout, which, IIRC, means a 3-column layout where you merely define the content, and the browser spills the overflow from column 1 into column 2.
No, liquid layouts are layouts that flow into variable-width viewports, rather than being fixed-width layouts that either leave gaps down the sides or force scrollbars depending on how wide the viewport is.
With JavaScript, you'd have to keep making DOM calls until it overflowed properly. You'd have to hand-code every page (since you don't know at what point content would fill up column 1 until you've calculated it yourself at this point.
Hand-coding each page would be a mistake. You can't calculate it yourself at that point, because you don't know what size font is being used, what size canvas is being used, etc. The only way to do it properly is to use your first idea, JavaScript.
Quite frankly, I think the idea of text spilling over between columns is just a poor excuse to bash web design. There's very little demand for it. Just because it's popular in print, it doesn't mean it makes sense for the web, people read differently on the web and it's subject to different constraints. Every website I've seen attempt it has just been annoying to read. I'm sure there are occasions where it makes sense, but they are few and far between. If this wasn't the case, then more people would be using the JavaScript trick you describe.
Right now, there are proprietary Mozilla tags that do this (-moz-column-count and -moz-column -width).
They aren't tags, they are properties. If you aren't sure what a tag is, then just avoid the word completely. 99% of the time, the word "tag" is the wrong word to use. It doesn't mean "bit of code somehow related to the web".
I've met many a web designer who would be stumped for a few seconds if I ever asked them "Is... W3C compliant?"
I'd be stumped too. The question makes no sense. The W3C is an organisation, not a specification. You can't "comply" with an organisation. The W3C produces many specifications, nothing on earth can comply with all of them because they address different areas. And while you might say "well that means is the HTML valid", in my experience, somebody asking about "W3C compliance" is under various misconceptions like the idea that CSS layouts require XHTML, or that <font> elements aren't valid, so guessing at what they might mean by "W3C compliance" is basically trying to figure out what weird ideas they have about "W3C compliance".
Well, with how XML works, a WYSIWYG HTML editor should be able to easily produce valid and semantic code
This is not true. Firstly, a WYSIWYG HTML editor by definition is focused on looks and not semantics. An editor that produces semantic code would be a WYSIWYMean editor. Secondly, it's got nothing whatsoever to do with "how XML works". Producing valid, semantic XHTML is identical to producing valid, semantic HTML. XML has nothing to do with "semantics", it's purely aimed at solving the syntax problem, and semantics is outside its scope.
Imagine if web browsers were anal retentive and refused to display anything with the slightest syntax error.
They already do this in many cases. When your browser downloads a corrupted JPEG image, it doesn't guess at what the picture should have looked like, it simply displays a "broken" icon, or displays the alt text, or displays an error message, or displays as much of the image that had been downloaded until the error occurred. This is equivalent to the XML error handling you are complaining about. In fact, broken documents silently being guessed at is pretty unique to HTML. Are there any other situations where people demand to be excused from their own mistakes and bugs and demand other people fix the problem for them?
It's senseless to make a website owner put their entire site on the line when they choose to embed content from comment authors, Google Analytics, Google Adwords, etc.
They already do that. The Google things that you mention are basically JavaScript provided by a third-party that executes in the security context of your own domain. They have the ability to totally rewrite and/or destroy your page, steal your visitors' cookies, or break things in any other kind of way. People rely on this not happening because if Google put out code that broke things for people, they would quickly lose their entire userbase, so it's in Google best interests to do everything possible to avoid this.
As for comments, if you are blindly outputting whatever code your commenters are submitting, then you've already got a broken website that's vulnerable to things like XSS attacks, worms or simple crapfloods. The only secure way of handling user-submitted content is to parse it, drop anything that isn't whitelisted, and serialise it again. That takes care of well-formedness too, so you aren't going to see XML fatal errors. Furthermore, if any software does have bugs of this nature, they will be immediately apparent showstoppers, so they will get fixed immediately.
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.
Actually, one of the reason many people have picked up on XHTML is because it's a lot "cleaner" than "good" ol' HTML 4, the strict rules are one of the reasons for this, in XHTML you're not allowed to do stupid shit like "<i>foo and <b>bar</i> are both words</b>".
You aren't allowed to do that in HTML either. The difference between HTML and XHTML is that XHTML defines mandatory error handling for this situation, while HTML leaves it undefined.
It's too hard to implement, because there is no default way it should look like. There is no default, standard stylesheet. What height is H1 supposed to look like by default?
I fail to see the difficulty. Headings aren't supposed to have a particular default height. What makes this difficult? Browser vendors can simply pick one themselves.
Also look how hard and painful it is to implement a 3 column liquid layout with just HTML and CSS.
It's trivial. It's a bit more complicated if you are talking about the subset of HTML and CSS that Internet Explorer supports, but there have been established techniques for years.
Fact is, HTML is based on a page/document model, whereas, nowadays, HTML "pages" are most of the time "screens", part of an application.
Part of Apple's philosophy is that applications should be based around the concept of documents, and they've been quite successful with it. A document model is not antithetical to applications.
most content in pure-ist HTML+CSS is basically a bunch of div's and span's.
This is not true. The idea is to use the most appropriate element type. <div> and <span> elements should only be used when there isn't something more suitable.
IMHO, if I were to redesign HTML today, it would look a lot like Xul, with XBL2 and microformats on top.
Please refer to the Rule of Least Power. It has all kinds of implications that make what you are suggesting a much worse idea than a document-based design.
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.
This is not true, text/html is not "the wrong MIME type" for XHTML. So long as it's XHTML 1.0 and it follows Appendix C of the XHTML 1.0 specification, it's perfectly acceptable to transmit an XHTML document as text/html. Refer to RFC 2854. I quote:
In addition, [XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html.
Now feel free to argue that it's not a good idea to do it, but it's got nothing to do with standards compliance.
This isn't anything to do with XML. HTML also required ampersands to be encoded in URLs. And it's a bit silly complaining that URLs had them first, seeing as the same guy invented URLs and HTML at the same time.
Slashdot Mirror
Actually, it's not plain-old HTML either. It's no longer based on SGML, HTML 5 defines its own parsing rules.
I wouldn't. Have you noticed that practically everybody using a custom page layout on MySpace uses a tool to do it? Jane Random Teen isn't writing HTML by hand. If any tool like that produced errors, people would simply use one that didn't.
Strictness isn't inconvenient for beginners, laxness is. The traditional laxness of HTML lets beginners twist their code further and further out of shape until when their code finally breaks, they've got so much to fix that they don't know where to begin. They just start hacking at it randomly hoping to change something that might have an effect. XML, on the other hand, has regular rules, and lets you know the second you screw up, so you don't get ahead of yourself, so you know which change it was that broke your page, so you have a chance of learning the rules.
Laxness has a reputation for being beginner-friendly because it enables beginners to speed ahead without really learning what it is they are doing. Thinking that's a good idea is short-sighted though, because as soon as they run into difficulty, they are already way out of their depth. Strictness is better in the long run.
Well if we are applying this reasoning equally, then fine. No version of HTML requires browser vendors to implement JPEG. No version of HTML requires browser vendors to implement GIF. And now, the new version of HTML won't require browser vendors to implement MP3. Fair, yes?
And they haven't done any such thing. They haven't banned the use of MP3, they just aren't requiring browser vendors to implement it. In all likelihood, every major browser vendor that implements <audio> will include MP3 support. But "it flat out isn't the place of a committee" to force browser vendors to infringe on patents.
This is a common misconception. The class attribute is intended for general purpose classification of elements, not merely as a style hook. The idea is that you classify your elements in a meaningful way (i.e. provide semantics), and then your stylesheets, scripts, etc, can use those semantics to manipulate the document in a useful way.
No, they wouldn't be parsed any differently, but they might be rendered differently.
It was unambiguous in SGML as well. The advantage XML had was that the tree was explicit in the document rather than being implied by a bunch of complex rules in the SGML standard and the external DTD subset.
I've seen a lot of people wrongly claim that forbidding things like <b><i>...</b></i> is an advantage of XHTML — are you making the same mistake? Such things are forbidden in HTML too, it's just people tend to get away with things like that with HTML because of its undefined error handling.
This is not true. The HTML 4.01 specification includes numerous explanations of what should be used instead of deprecated element types and attributes. I quote from the specification:
For example, in the part of the specification that describes font styles, examples are given to show you how to style text with CSS instead. If you haven't seen the explanations, then you just aren't looking.
You can remove support for things like <font> in your browser today.
We already have the irony mark.
That doesn't make Internet Explorer support XHTML. It makes it automatically convert XHTML to HTML, which it does support. This is not the same thing. For example, try document.getElementsByTagName("HTML") in JavaScript. When applied to an XHTML document, that should return no elements. When applied to an HTML document, it should return the root element. Or try styling <tbody> elements. Unless you put them in explicitly, there won't be any in an XHTML document. In an HTML document, they are automatically implied for every <table> element.
What you are doing with the XSLT approach is covering up Internet Explorer's inadequacy by automatically transcoding to HTML on the client. Internet Explorer isn't seeing XHTML though, so if you attempt to use anything XHTML-specific, then it won't work. And if you aren't attempting to use anything XHTML-specific, then it's not worth bothering with XHTML in the first place, you might as well just use HTML.
Microformats are a good solution where a problem is domain-specific. HTML is extensible with mechanisms like the class attribute so that HTML doesn't have to include lots of element types that aren't useful to most people.
But when something is applicable to a wide variety of situations, the right place for it is in the HTML specification, not as an ad-hoc extension. Otherwise, you could just make the argument for every element type under the sun being replaced with <div class="..."> or <span class="..."> . At that point, you're just using the class attribute as a bodge to avoid new element types, not because it's a good idea.
Yeah, sure, it's nice that browsers don't have to be updated for microformats to work. But that doesn't mean it's good design to try to stuff everything under the sun into the class attribute. Sometimes the right place for something is in the HTML specification.
On the contrary, web designers should be messing with the HTML, as they are the ones most qualified to do it. I suspect you are using "web designer" as a synonym for "graphic designer", but they are really two separate roles.
A graphic designer should be responsible for how a website looks. He needs certain domain-specific knowledge, so that he doesn't do anything silly like assume that words take up a fixed amount of space, but he should be concerned with how things look and not touch code.
A web designer should then take that look and translate it into code. This involves writing both the CSS and the HTML, talking to the designer to get him to give him the graphics layered/sliced in particular ways, and so on. The web designer is responsible for the front-end, how the interface operates.
The web developer should then take the static pages that the web designer created, and "make them work". Turn them into templates, add business logic, pull data from the database, etc. The web developer is responsible for the back-end, how the application works.
I've worn all three hats from time to time, but the ideal situation is to have different people focusing on the different aspects. It's rare to get somebody qualified in more than one area, and when you let them into other areas, they tend to screw up. The bigger the business, the more people you add on the edges — further afield in the graphic designed direction is branding/marketing, and further afield in the web developer direction are DBAs and sysadmins. But dead centre is the web designer writing the code that makes an interface operate.
The majority of the studies that say this were conducted with printed material, not with a screen. Of the couple of studies that were actually conducted with screens that I've seen, they assumed too much or measured the wrong thing (e.g. what makes you think that the number of characters matter, as opposed to the physical dimensions?).
If you have an adequate study for optimal line lengths for the web, I'd definitely be interested in reading it, but all the ones that seem to crop up in discussions like this aren't applicable or are flawed. I've been looking for a while, but I haven't found a sound basis for this "common knowledge".
I never said you were making anything up, I'm just pointing out that what is true for print is not necessarily true for the web.
It's not fair use, because copies of software that are made for the purpose of using it are not covered by copyright in the first place. The law is explicit about this:
In short: It's not fair use (that's a different set of exemptions), but it is legal.
"Input and output details" is pretty vague.
The XHTML 1.1 specification doesn't include anything about content types at all. There's also a draft that mentions content types, but it says that text/html is suitable, so either way, according to the XHTML 1.1 specification, text/html is not wrong. It's wrong according to RFC 2854, but that isn't a question of validity.
No. "Valid" has a very precise meaning when you are talking about SGML or XML-based markup languages. It is not a synonym for "wrong", "buggy", "broken", or anything like that. An incorrect content type doesn't make something invalid.
Well of course it would — because it wouldn't be following the syntax requirements. That's what makes something invalid. I know it's tempting to slap the "invalid" condemnation on every type of error, but it's not true. There are different types of error.
I don't see how you can think that is an analogous situation. CSS 2.1 doesn't have a different media type to older CSS specifications, so it's impossible to do content negotiation. Microsoft partially implementing CSS 2.1 doesn't lose you content negotation because it wasn't there in the first place.
No it wasn't. RFC 2854 was published before XHTML 1.1 was finished. Support wasn't intentionally removed, it just hasn't been added. Furthermore, as I mentioned above, it's in the process of being added.
Do you agree that there's a world of difference between "implying" something and "insisting"?
I like this quote:
I think he intentionally, very clearly limited the scope of his argument to XHTML as text/html. He knows damn well that the merit of XHTML is a far more complex argument and that the only real answer is "it depends on your circumstances".
Furthermore, are you aware that the arguments in that document against XHTML 1.0/Appendix C being truly compatible with HTML 4.01 also apply to HTML 5, which is no longer an SGML application? Do you think that HTML 5 should get a new media type and that it shouldn't be labelled text/html?
Well there are many reasons why designs suitable for print are unsuitable for the web, but there's a few very simple ones that apply in this case. Vertical space is infinite on the web. Horizontal space is unpredictable and almost always at a premium due to things like navigation bars and adverts also taking up horizontal space. As such, giving away horizontal space to gain vertical space, which is what multiple columns are for, is almost always exactly the opposite of what you want to do.
Of course, I'm speaking from a typically Western myopic attitude, I haven't worked with East-Asian languages, so what I say doesn't necessarily apply to languages with vertical writing systems.
They are mainly there through inertia. I'm certainly not arguing that having the facility for multiple columns would be a bad thing to have, just that it's not the anywhere near the priority critics make it out to be.
Sure, you're certainly right there. In fact, with CSS 3's multi-column facilities, it's possible to have a single column design for online viewing and multiple columns when it's printed out. As things like navigation bars can be hidden when printing out, this makes the limited horizontal space less of an issue.
I don't follow you. You intentionally pick a small font size so that you get short line lengths, and then complain that the line lengths are too short for the page? Isn't that exactly what you intended to happen?
No, liquid layouts are layouts that flow into variable-width viewports, rather than being fixed-width layouts that either leave gaps down the sides or force scrollbars depending on how wide the viewport is.
Hand-coding each page would be a mistake. You can't calculate it yourself at that point, because you don't know what size font is being used, what size canvas is being used, etc. The only way to do it properly is to use your first idea, JavaScript.
Quite frankly, I think the idea of text spilling over between columns is just a poor excuse to bash web design. There's very little demand for it. Just because it's popular in print, it doesn't mean it makes sense for the web, people read differently on the web and it's subject to different constraints. Every website I've seen attempt it has just been annoying to read. I'm sure there are occasions where it makes sense, but they are few and far between. If this wasn't the case, then more people would be using the JavaScript trick you describe.
They aren't tags, they are properties. If you aren't sure what a tag is, then just avoid the word completely. 99% of the time, the word "tag" is the wrong word to use. It doesn't mean "bit of code somehow related to the web".
I'd be stumped too. The question makes no sense. The W3C is an organisation, not a specification. You can't "comply" with an organisation. The W3C produces many specifications, nothing on earth can comply with all of them because they address different areas. And while you might say "well that means is the HTML valid", in my experience, somebody asking about "W3C compliance" is under various misconceptions like the idea that CSS layouts require XHTML, or that <font> elements aren't valid, so guessing at what they might mean by "W3C compliance" is basically trying to figure out what weird ideas they have about "W3C compliance".
This is not true. Firstly, a WYSIWYG HTML editor by definition is focused on looks and not semantics. An editor that produces semantic code would be a WYSIWYMean editor. Secondly, it's got nothing whatsoever to do with "how XML works". Producing valid, semantic XHTML is identical to producing valid, semantic HTML. XML has nothing to do with "semantics", it's purely aimed at solving the syntax problem, and semantics is outside its scope.
They already do this in many cases. When your browser downloads a corrupted JPEG image, it doesn't guess at what the picture should have looked like, it simply displays a "broken" icon, or displays the alt text, or displays an error message, or displays as much of the image that had been downloaded until the error occurred. This is equivalent to the XML error handling you are complaining about. In fact, broken documents silently being guessed at is pretty unique to HTML. Are there any other situations where people demand to be excused from their own mistakes and bugs and demand other people fix the problem for them?
They already do that. The Google things that you mention are basically JavaScript provided by a third-party that executes in the security context of your own domain. They have the ability to totally rewrite and/or destroy your page, steal your visitors' cookies, or break things in any other kind of way. People rely on this not happening because if Google put out code that broke things for people, they would quickly lose their entire userbase, so it's in Google best interests to do everything possible to avoid this.
As for comments, if you are blindly outputting whatever code your commenters are submitting, then you've already got a broken website that's vulnerable to things like XSS attacks, worms or simple crapfloods. The only secure way of handling user-submitted content is to parse it, drop anything that isn't whitelisted, and serialise it again. That takes care of well-formedness too, so you aren't going to see XML fatal errors. Furthermore, if any software does have bugs of this nature, they will be immediately apparent showstoppers, so they will get fixed immediately.
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.
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.
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.
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.
You aren't allowed to do that in HTML either. The difference between HTML and XHTML is that XHTML defines mandatory error handling for this situation, while HTML leaves it undefined.
I fail to see the difficulty. Headings aren't supposed to have a particular default height. What makes this difficult? Browser vendors can simply pick one themselves.
It's trivial. It's a bit more complicated if you are talking about the subset of HTML and CSS that Internet Explorer supports, but there have been established techniques for years.
Part of Apple's philosophy is that applications should be based around the concept of documents, and they've been quite successful with it. A document model is not antithetical to applications.
This is not true. The idea is to use the most appropriate element type. <div> and <span> elements should only be used when there isn't something more suitable.
Please refer to the Rule of Least Power. It has all kinds of implications that make what you are suggesting a much worse idea than a document-based design.
HTML has had a client-side include for a decade. It's called <object> . Inline frames are also popular.
This is not true, text/html is not "the wrong MIME type" for XHTML. So long as it's XHTML 1.0 and it follows Appendix C of the XHTML 1.0 specification, it's perfectly acceptable to transmit an XHTML document as text/html. Refer to RFC 2854. I quote:
Now feel free to argue that it's not a good idea to do it, but it's got nothing to do with standards compliance.
This isn't anything to do with XML. HTML also required ampersands to be encoded in URLs. And it's a bit silly complaining that URLs had them first, seeing as the same guy invented URLs and HTML at the same time.