Slashdot Mirror

Just wanted to point this out:

XHTML2 -- with navigation lists, links on any element, sections and headings -- is optimized for web documents.

HTML5, officially Web Applications 1.0 -- with canvas, a drag and drop API, and XMLHTTPRequest standardization -- is optimized for web applications.

CSS3 is going to be extremely cool.

Just wanted to point this out:

XHTML2 -- with navigation lists, links on any element, sections and headings -- is optimized for web documents.

HTML5, officially Web Applications 1.0 -- with canvas, a drag and drop API, and XMLHTTPRequest standardization -- is optimized for web applications.

CSS3 is going to be extremely cool.

Just wanted to point this out:

XHTML2 -- with navigation lists, links on any element, sections and headings -- is optimized for web documents.

HTML5, officially Web Applications 1.0 -- with canvas, a drag and drop API, and XMLHTTPRequest standardization -- is optimized for web applications.

CSS3 is going to be extremely cool.

Just wanted to point this out:

XHTML2 -- with navigation lists, links on any element, sections and headings -- is optimized for web documents.

HTML5, officially Web Applications 1.0 -- with canvas, a drag and drop API, and XMLHTTPRequest standardization -- is optimized for web applications.

CSS3 is going to be extremely cool.

"In general, the tone of the article seems to be that many people should not be allowed on the web because they can't follow standards"

And that would include, I think, the article's authors. Using DOCTYPE HTML is a non-standard DTD, they haven't specified any character encoding, and whilst they've cottoned on to the HTML entity for an opening right-angle bracket they haven't yet to the HTML entity for a closing bracket. This last isn't invalid I don't think, just stupid.

Also, check out the source for google.com for some awful, non-standards HTML:

http://validator.w3.org/check?verbose=1&uri=http:/ /www.google.co.uk/

This is the sort of markup muck that they generally spit out. So with respect to "I wonder how much HTML coding the authors do" I'd say slightly more than the google web devs.

Gecko fascism indeed, I mean what a bunch of bastard, using completely valid SVG files, oooh the nerve of them blokes...

In their list of the 19 most popular elements, the font tag was #16. This element was deprecated when, back in 2000 or so?

The <font> element type was deprecated in 1997.

That's actually the year before Google was incorporated. Just think, an entire multi-billion international corporation has been created and grown to dominate the search engine market in less time than it takes for one annoying element type to die.

I bet if Microsoft announced that the next version of Internet Explorer was going to disregard the <font> element type, it would be almost dead within six months. And it would be less code to maintain for Microsoft as well.

Most people (roughly 98%) include head, html, title and body elements. This is somewhat ironic, since three of those four elements are optional in HTML

Somewhat true. The HEAD tag is technically optional (per spec), but TITLE is required, and must be in the HEAD. Thus HEAD is required in practice.

From the HTML 4.01 spec:

Every HTML document must have a TITLE element in the HEAD section.

Though marked as "start tag optional"/"end tag optional", the BODY and HTML tags do provide useful symantec relevance.

SMIL is actually a W3C standard.

Text-shadow was deprecated in CSS 2.1 which fully supercedes CSS 2.0.

No it doesn't. CSS 2.1 has draft status. More accurately, text-shadow will be deprecated, for CSS level 2, once CSS 2.1 is finalised. And that only applies to CSS level 2 - CSS level 3 might put it back in again.

Reference
http://www.w3.org/TR/2004/WD-WCAG20-CSS-TECHS-2004 0730/#text-shadow

My point was that FireFox/Gecko is not the paragon of standards compliance, so dragging IE into the "you don't comply" mud is hypocritical. Indeed there are more important things to make work, but nevertheless, compliance is incomplete.

To that effect, since CSS2 came out in 1998, and CSS2.1 in 2005, I would have expected text-shadow (along with the other things you listed) to get fixed in that time frame. What have the FireFox devs been doing?

What's wrong with using HTML file uploads?

I'm not trolling. I know VML is not SVG. SVG is featuritis run amok. What the hell are the W3C thinking, adding audio, video and network request functionality to a vector image format?

SVG has been around since the year 2000, and yet browsers are only just starting to implement SVG Tiny (not even SVG Full). If the W3C continue to throw everything but the kitchen sink into SVG, browser support will never be finished.

As for compression, why should VML be concerned with that? SVG shouldn't be concerned with that either. HTTP already handles compression that is very effective for markup, there's no need to address it in every format that goes over the wire.

I'm not trolling. I know VML is not SVG. SVG is featuritis run amok. What the hell are the W3C thinking, adding audio, video and network request functionality to a vector image format?

SVG has been around since the year 2000, and yet browsers are only just starting to implement SVG Tiny (not even SVG Full). If the W3C continue to throw everything but the kitchen sink into SVG, browser support will never be finished.

As for compression, why should VML be concerned with that? SVG shouldn't be concerned with that either. HTTP already handles compression that is very effective for markup, there's no need to address it in every format that goes over the wire.

I'm not trolling. I know VML is not SVG. SVG is featuritis run amok. What the hell are the W3C thinking, adding audio, video and network request functionality to a vector image format?

SVG has been around since the year 2000, and yet browsers are only just starting to implement SVG Tiny (not even SVG Full). If the W3C continue to throw everything but the kitchen sink into SVG, browser support will never be finished.

As for compression, why should VML be concerned with that? SVG shouldn't be concerned with that either. HTTP already handles compression that is very effective for markup, there's no need to address it in every format that goes over the wire.

> are already well advanced with implementations of SVG, DOM, CSS, PNG, JPEG2000 and XForms.


Only Firefox/Mozilla has XForms; sadly Opera and Safari don't.

XForms, by the way, is the only stanrd to incorporate all the stuff that XMLTTHPRequest does, and it does so in a very easy way.

For example, if you want to load up your del.icio.us tags you just do this in the <head>:

  <instance src="http://del.icio.us/api/tags/get" />

Then you can list them like this in the HTML <body>:

  <repeat nodeset="/tags/tag">
      <output ref="." />
  </repeat>

using the XForms <submission> tag, you can also do asynchronous HTTP POST of XML, of any instance in the page, and direct the results to come back to any instance. When the instance comes back, the UI automatically recalculates itself, and any UI widgets or groups (i.e., entire <div>s) that were bound to non-existent nodes suddenly appear in the UI when the data updates and the nodes appear. You can even make submission happen automatically when fields are exited or when menu items are changed, so forms can be completely dynamic with absolutely no JavaScript; just plain markup.

As Rachel Ray says, "How cool is that?"

Lately I've been using FormFaces (an entire XForms implementation for IE, Safari, and FF/Mozilla in AJAX/JavaScript) and Chiba (a Tomcat-based back end that outputs either plain HTML with no JavaScript for no-brainer ADA compliance, or AJAX-enhanced HTML for dynamic forms). These implementations are running neck-and-neck with the Firefox/Mozilla native one, and are catching up to the very advanced IE plugin FormsPlayer.

If you want to see how to do the the dynamic XML features you get from HTTPXMLRequest but in a standards-compliant way and using simple markup, see XForms for HTML Authors.

P.S. Since I got bashed for not saying this before, I have to add that I was one of the editors of the XForms 1.0 recommendation. Since I post under my real name and list the info on my website (and at the top of the spec ;-) I hadn't realized I needed to point out explicitly that I helped. But I'm not involved in selling implementations, only in using them.

SVG: Microsoft implemented vector graphics in Internet Explorer years ago with VML, which they submitted to the W3C in 1998.

CSS: A partial list of fixes regarding CSS that will be in Internet Explorer 7 can be found on the IEBlog. They've fixed a lot.

PNG: Internet Explorer 7 will have support for the PNG alpha channel, bringing it up to the level of support that other browsers have.

JPEG2000: JPEG2000 is patent encumbered. Mozilla/Firefox doesn't support it.

XForms: XForms support is available through a plugin.

The only really valid complaint you have there is their lack of support for the DOM. In particular, it would be very nice if they implemented DOM 2 Events, but I don't think that's likely to happen for Internet Explorer 7.

FireFox doesn't even fully support CSS2. (http://www.w3.org/TR/REC-CSS2/text.html#text-shad ow-props) When will FireFox join the inevitable?

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

Note this bug was opened in 1999. Judging from the target milestone (mozilla1.9) and the FireFox roadmap, we will have full CSS2 support in FireFox 3.0 by 2007. Wow, eight years...

Yeah, but can you post or make a new account from links?

Seems to be a bit of confusion here. The document you pointed out was written in September of 1995, however, the HTML 3 standard, according to the same website, was adopted in March of 1995

http://www.w3.org/MarkUp/html3/

It looks like HTML3 is what added tables. That is strange, because I just ran across a website today where the guy was trying to update a table from HTML2 specifications to HTML4.

I KNOW Netscape 2 and the first version of IE supported tables. IE would have come out around Auguest of 95, as it was bundled with Windows 95. I was trying to google the specifications of these early browsers, but I cannot find anything, and archive.org for the netscape site only goes back to netscape 3. Did Netscape 2 and the first versions of IE actually support HTML3? It would not surprise me if they were fully HTML2 compatable and incorporated some HTML3 code before it was approved as a standard, that may be where I am confused.

For Flash and Java you can use the Object tag with an alternative if it can't be rendered. Read the standard: http://www.w3.org/TR/html4/struct/objects.html#ede f-OBJECT

For JavaScript you have the stuff to offer an alternative.

It does work ... if you want to.

b4n

Just program in HTML 2. Its what I do. Supports tables, most of the stuff you want to use (except maybe style sheets)

HTML 2 does not support tables. It does support stylesheets. Read the specification for yourself.

Why not simply keep it to accepted Web Accessibility Standards? NOTHING should be done explicitly to make webpages compatible with any version of Internet Explorer.

http://www.w3.org/TR/WAI-WEBCONTENT/

• Start with the HTML validator at W3C and use HTML 4.01 as your target for HTML. This will ensure that most browsers will be able to read your web pages.
• If you are REALLY paranoid you may go for HTML 3.2, but personally I think that it is to stretch it too far.
• Second stage is to check JavaScript version and make sure that you use the right version. E.g. <script language="javascript1.2" type="text/javascript"></script>.
• O'Reilly's book JavaScript: The Definitive Guide is really helpful. It contains examples of how to determine JavaScript version if you need to use features from a newer JavaScript in some cases.
• Whatever you do - DO NOT USE VBSCRIPT/JScript! (Except if you want to catch special quirks with IE).
• Firefox contains two good tools that are really helpful when doing Javascript, the JavaScript console and the DOM Inspector. Of course - you will still need to verify against the older browsers too, but you will get a good start.
• Use JavaScript to warn the user (in a nice manner) that there may be some problems with the browser used.
• Be careful with the use of CSS. It is useful, and can make your HTML more 'clean'. The backside is that not all browsers handles CSS the same way.
• When specifying sizes - always use specify the size unit.
  The following three alternatives produces different result, and it may also depend on your browser:

  <span style="font-size: 10px;">Hello</span><br>
  <span style="font-size: 10pt;">Hello</span><br>
  <span style="font-size: 10;">Hello (invalid - unit must be used)</span><br>
  

  Validate the CSS you are using through the CSS Validator

• Double-check for script errors in other browsers since there are differences in the handling even though two different browsers may support the same scripting. For example - IE does not allow JavaScript to focus a hidden field while Firefox does.
• Put almost all JavaScript source in an external file and don't embed it into the web page. This will make the page a lot cleaner! The same goes for CSS.
• When specifying a font in CSS, give a list of fonts and end the list with one of the following; "Proportional", "Serif", "Sans-serif" or "Monospace". This will ensure that the page is displayed with a look&feel that resembles your intent.
• ALWAYS specify the content type so that the correct character set is used! E.g.: <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">. W3C specifies that if it isn't given UTF-8 shall be used, but different browsers behaves differently here! Use ISO-8859-1 or UTF-8 even if your page is in plain US-ASCII, since both are supersets of US-ASCII and you may be using a symbol outside the US-ASCII range without realizing it!

• Start with the HTML validator at W3C and use HTML 4.01 as your target for HTML. This will ensure that most browsers will be able to read your web pages.
• If you are REALLY paranoid you may go for HTML 3.2, but personally I think that it is to stretch it too far.
• Second stage is to check JavaScript version and make sure that you use the right version. E.g. <script language="javascript1.2" type="text/javascript"></script>.
• O'Reilly's book JavaScript: The Definitive Guide is really helpful. It contains examples of how to determine JavaScript version if you need to use features from a newer JavaScript in some cases.
• Whatever you do - DO NOT USE VBSCRIPT/JScript! (Except if you want to catch special quirks with IE).
• Firefox contains two good tools that are really helpful when doing Javascript, the JavaScript console and the DOM Inspector. Of course - you will still need to verify against the older browsers too, but you will get a good start.
• Use JavaScript to warn the user (in a nice manner) that there may be some problems with the browser used.
• Be careful with the use of CSS. It is useful, and can make your HTML more 'clean'. The backside is that not all browsers handles CSS the same way.
• When specifying sizes - always use specify the size unit.
  The following three alternatives produces different result, and it may also depend on your browser:

  <span style="font-size: 10px;">Hello</span><br>
  <span style="font-size: 10pt;">Hello</span><br>
  <span style="font-size: 10;">Hello (invalid - unit must be used)</span><br>
  

  Validate the CSS you are using through the CSS Validator

• Double-check for script errors in other browsers since there are differences in the handling even though two different browsers may support the same scripting. For example - IE does not allow JavaScript to focus a hidden field while Firefox does.
• Put almost all JavaScript source in an external file and don't embed it into the web page. This will make the page a lot cleaner! The same goes for CSS.
• When specifying a font in CSS, give a list of fonts and end the list with one of the following; "Proportional", "Serif", "Sans-serif" or "Monospace". This will ensure that the page is displayed with a look&feel that resembles your intent.
• ALWAYS specify the content type so that the correct character set is used! E.g.: <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">. W3C specifies that if it isn't given UTF-8 shall be used, but different browsers behaves differently here! Use ISO-8859-1 or UTF-8 even if your page is in plain US-ASCII, since both are supersets of US-ASCII and you may be using a symbol outside the US-ASCII range without realizing it!

• Start with the HTML validator at W3C and use HTML 4.01 as your target for HTML. This will ensure that most browsers will be able to read your web pages.
• If you are REALLY paranoid you may go for HTML 3.2, but personally I think that it is to stretch it too far.
• Second stage is to check JavaScript version and make sure that you use the right version. E.g. <script language="javascript1.2" type="text/javascript"></script>.
• O'Reilly's book JavaScript: The Definitive Guide is really helpful. It contains examples of how to determine JavaScript version if you need to use features from a newer JavaScript in some cases.
• Whatever you do - DO NOT USE VBSCRIPT/JScript! (Except if you want to catch special quirks with IE).
• Firefox contains two good tools that are really helpful when doing Javascript, the JavaScript console and the DOM Inspector. Of course - you will still need to verify against the older browsers too, but you will get a good start.
• Use JavaScript to warn the user (in a nice manner) that there may be some problems with the browser used.
• Be careful with the use of CSS. It is useful, and can make your HTML more 'clean'. The backside is that not all browsers handles CSS the same way.
• When specifying sizes - always use specify the size unit.
  The following three alternatives produces different result, and it may also depend on your browser:

  <span style="font-size: 10px;">Hello</span><br>
  <span style="font-size: 10pt;">Hello</span><br>
  <span style="font-size: 10;">Hello (invalid - unit must be used)</span><br>
  

  Validate the CSS you are using through the CSS Validator

• Double-check for script errors in other browsers since there are differences in the handling even though two different browsers may support the same scripting. For example - IE does not allow JavaScript to focus a hidden field while Firefox does.
• Put almost all JavaScript source in an external file and don't embed it into the web page. This will make the page a lot cleaner! The same goes for CSS.
• When specifying a font in CSS, give a list of fonts and end the list with one of the following; "Proportional", "Serif", "Sans-serif" or "Monospace". This will ensure that the page is displayed with a look&feel that resembles your intent.
• ALWAYS specify the content type so that the correct character set is used! E.g.: <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">. W3C specifies that if it isn't given UTF-8 shall be used, but different browsers behaves differently here! Use ISO-8859-1 or UTF-8 even if your page is in plain US-ASCII, since both are supersets of US-ASCII and you may be using a symbol outside the US-ASCII range without realizing it!

• Start with the HTML validator at W3C and use HTML 4.01 as your target for HTML. This will ensure that most browsers will be able to read your web pages.
• If you are REALLY paranoid you may go for HTML 3.2, but personally I think that it is to stretch it too far.
• Second stage is to check JavaScript version and make sure that you use the right version. E.g. <script language="javascript1.2" type="text/javascript"></script>.
• O'Reilly's book JavaScript: The Definitive Guide is really helpful. It contains examples of how to determine JavaScript version if you need to use features from a newer JavaScript in some cases.
• Whatever you do - DO NOT USE VBSCRIPT/JScript! (Except if you want to catch special quirks with IE).
• Firefox contains two good tools that are really helpful when doing Javascript, the JavaScript console and the DOM Inspector. Of course - you will still need to verify against the older browsers too, but you will get a good start.
• Use JavaScript to warn the user (in a nice manner) that there may be some problems with the browser used.
• Be careful with the use of CSS. It is useful, and can make your HTML more 'clean'. The backside is that not all browsers handles CSS the same way.
• When specifying sizes - always use specify the size unit.
  The following three alternatives produces different result, and it may also depend on your browser:

  <span style="font-size: 10px;">Hello</span><br>
  <span style="font-size: 10pt;">Hello</span><br>
  <span style="font-size: 10;">Hello (invalid - unit must be used)</span><br>
  

  Validate the CSS you are using through the CSS Validator

• Double-check for script errors in other browsers since there are differences in the handling even though two different browsers may support the same scripting. For example - IE does not allow JavaScript to focus a hidden field while Firefox does.
• Put almost all JavaScript source in an external file and don't embed it into the web page. This will make the page a lot cleaner! The same goes for CSS.
• When specifying a font in CSS, give a list of fonts and end the list with one of the following; "Proportional", "Serif", "Sans-serif" or "Monospace". This will ensure that the page is displayed with a look&feel that resembles your intent.
• ALWAYS specify the content type so that the correct character set is used! E.g.: <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">. W3C specifies that if it isn't given UTF-8 shall be used, but different browsers behaves differently here! Use ISO-8859-1 or UTF-8 even if your page is in plain US-ASCII, since both are supersets of US-ASCII and you may be using a symbol outside the US-ASCII range without realizing it!

• Start with the HTML validator at W3C and use HTML 4.01 as your target for HTML. This will ensure that most browsers will be able to read your web pages.
• If you are REALLY paranoid you may go for HTML 3.2, but personally I think that it is to stretch it too far.
• Second stage is to check JavaScript version and make sure that you use the right version. E.g. <script language="javascript1.2" type="text/javascript"></script>.
• O'Reilly's book JavaScript: The Definitive Guide is really helpful. It contains examples of how to determine JavaScript version if you need to use features from a newer JavaScript in some cases.
• Whatever you do - DO NOT USE VBSCRIPT/JScript! (Except if you want to catch special quirks with IE).
• Firefox contains two good tools that are really helpful when doing Javascript, the JavaScript console and the DOM Inspector. Of course - you will still need to verify against the older browsers too, but you will get a good start.
• Use JavaScript to warn the user (in a nice manner) that there may be some problems with the browser used.
• Be careful with the use of CSS. It is useful, and can make your HTML more 'clean'. The backside is that not all browsers handles CSS the same way.
• When specifying sizes - always use specify the size unit.
  The following three alternatives produces different result, and it may also depend on your browser:

  <span style="font-size: 10px;">Hello</span><br>
  <span style="font-size: 10pt;">Hello</span><br>
  <span style="font-size: 10;">Hello (invalid - unit must be used)</span><br>
  

  Validate the CSS you are using through the CSS Validator

• Double-check for script errors in other browsers since there are differences in the handling even though two different browsers may support the same scripting. For example - IE does not allow JavaScript to focus a hidden field while Firefox does.
• Put almost all JavaScript source in an external file and don't embed it into the web page. This will make the page a lot cleaner! The same goes for CSS.
• When specifying a font in CSS, give a list of fonts and end the list with one of the following; "Proportional", "Serif", "Sans-serif" or "Monospace". This will ensure that the page is displayed with a look&feel that resembles your intent.
• ALWAYS specify the content type so that the correct character set is used! E.g.: <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">. W3C specifies that if it isn't given UTF-8 shall be used, but different browsers behaves differently here! Use ISO-8859-1 or UTF-8 even if your page is in plain US-ASCII, since both are supersets of US-ASCII and you may be using a symbol outside the US-ASCII range without realizing it!

Using an tag in HTML is invalid HTML; did apple do things wrong with quicktime? Obviously that is irrelevant, but why don't you take a look at this HTML validation:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .apple.com

or how about this one?
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .mac.com

or maybe even Microsoft?
http://validator.w3.org/check?uri=http%3A%2F%2Fmsd n.microsoft.com%2F

I think that these web standards are excellent, but the errors you pointed out are completely trivial. Now, if Apple were pulling a Microsoft and trying to add extra javascript variables that were Safari exclusive, we would have a huge problem.

Using an tag in HTML is invalid HTML; did apple do things wrong with quicktime? Obviously that is irrelevant, but why don't you take a look at this HTML validation:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .apple.com

or how about this one?
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .mac.com

or maybe even Microsoft?
http://validator.w3.org/check?uri=http%3A%2F%2Fmsd n.microsoft.com%2F

I think that these web standards are excellent, but the errors you pointed out are completely trivial. Now, if Apple were pulling a Microsoft and trying to add extra javascript variables that were Safari exclusive, we would have a huge problem.

Using an tag in HTML is invalid HTML; did apple do things wrong with quicktime? Obviously that is irrelevant, but why don't you take a look at this HTML validation:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .apple.com

or how about this one?
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .mac.com

or maybe even Microsoft?
http://validator.w3.org/check?uri=http%3A%2F%2Fmsd n.microsoft.com%2F

I think that these web standards are excellent, but the errors you pointed out are completely trivial. Now, if Apple were pulling a Microsoft and trying to add extra javascript variables that were Safari exclusive, we would have a huge problem.

Nothing magic about it, it's a link from the slashdot "links related to this story" box.

When you request that URL slashdot simply looks in their ad links database for the page with a corresponding ID and gives you a 302 Redirect with the new destination.

Where is the P3P going to play in all this?

Incorrect. User-defined styles are defaults, and are overriden by any server-specified style. User-defined styles actually have the lowest precedence (aside from user-agent default styles), unless you add !important, in which case they have the highest precedence. See the first 2 paragraphs of section 6.4.2 of the CSS2 spec. Section 6.4.1 is also helpful.

User style sheets are always to supercede site style sheets, according to the CSS specification.

This is not true, and isn't true in two different ways, depending on which specification you count as "the" CSS specification (there's more than one).

According to the CSS 1 specification, the author stylesheet will override the user stylesheet in most cases, and even if the user has !important rules, the author stylesheet can override them with !important. Quote:

This strategy gives author's style sheets considerably higher weight than those of the reader.

According to the CSS 2 specification, the author stylesheet will override the user stylesheet in most cases, but the user can override author rules, even !important ones, by using !important themself. Quote:

Apart from the "!important" setting on individual declarations, this strategy gives author's style sheets higher weight than those of the reader.

CSS 2.1 and 3.0 drafts work in the same way as CSS 2, giving the author stylesheet precendence unless the user uses !important.

booch was correct in saying that !important is necessary in a user stylesheet if you want to be sure that the author stylesheets can't override them.

User style sheets are always to supercede site style sheets, according to the CSS specification.

This is not true, and isn't true in two different ways, depending on which specification you count as "the" CSS specification (there's more than one).

According to the CSS 1 specification, the author stylesheet will override the user stylesheet in most cases, and even if the user has !important rules, the author stylesheet can override them with !important. Quote:

This strategy gives author's style sheets considerably higher weight than those of the reader.

According to the CSS 2 specification, the author stylesheet will override the user stylesheet in most cases, but the user can override author rules, even !important ones, by using !important themself. Quote:

Apart from the "!important" setting on individual declarations, this strategy gives author's style sheets higher weight than those of the reader.

CSS 2.1 and 3.0 drafts work in the same way as CSS 2, giving the author stylesheet precendence unless the user uses !important.

booch was correct in saying that !important is necessary in a user stylesheet if you want to be sure that the author stylesheets can't override them.

User style sheets are always to supercede site style sheets, according to the CSS specification. The "!important" modifier shouldn't be necessary. I don't know if Mozilla implements that aspect of CSS correctly though, so it couldn't hurt to put it in there anyway.

Not quite, an author rule at normal precedence will over-ride a user rule at normal precedence (assuming same specificity) however a user !important rule will over-ride an author !important rule.
(see CSS 2.1 Section 6.4.2)

One thing to bear in mind is accessibility. From WCAG 1.0:

Link text should be meaningful enough to make sense when read out of context -- either on its own or as part of a sequence of links. Link text should also be terse.

For example, in HTML, write "Information about version 4.3" instead of "click here". In addition to clear link text, content developers may further clarify the target of a link with an informative link title (e.g., in HTML, the "title" attribute).

I completely agree. The W3C has a tip about properly hyperlinking, and most of it actually makes sense.

Which XHTML specification are you talking about?

XHTML 1.0 is the direct equivalent of HTML 4.01, so you won't find any attributes described in it, as they all take their semantics from the HTML 4.01 specification. If you read the DTD, you will see that, yes, it's part of XHTML 1.0.

If you are talking about XHTML 1.1, then it's in there too.

If you are talking about the unfinished XHTML 2.0 drafts, then it's in there too.

Which XHTML specification are you talking about?

XHTML 1.0 is the direct equivalent of HTML 4.01, so you won't find any attributes described in it, as they all take their semantics from the HTML 4.01 specification. If you read the DTD, you will see that, yes, it's part of XHTML 1.0.

If you are talking about XHTML 1.1, then it's in there too.

If you are talking about the unfinished XHTML 2.0 drafts, then it's in there too.

Which XHTML specification are you talking about?

XHTML 1.0 is the direct equivalent of HTML 4.01, so you won't find any attributes described in it, as they all take their semantics from the HTML 4.01 specification. If you read the DTD, you will see that, yes, it's part of XHTML 1.0.

If you are talking about XHTML 1.1, then it's in there too.

If you are talking about the unfinished XHTML 2.0 drafts, then it's in there too.

Also, I should have added this.

The REL attribute has a set list of link types to be associated with it.

"nofollow" is not one of them. Google shoehorned a non standard compliant value into a standard field for their own purposes. That is not being W3C compliant.

I didn't hear anyone bitching when Google decided to use "rel=nofollow" attributes in links so their spiders wouldn't follow them. Yeah, that's W3C all right.

Yes, the rel attribute is part of HTML 4.01, for precisely the purpose of conveying the relationship between the current document and the linked document.

XHR has been around since IE4, and is firmly entrenched in all the Gecko-browsers and Safari, as well as Opera, iCab and all the other niche browsers.

XMLHttpRequest hasn't been around since Internet Explorer 4, it was introduced in Internet Explorer 5.0.

Even if it's implemented in a browser, that doesn't mean you can rely on it to be there. It's quite sensible to switch off ActiveX if you absolutely must use Internet Explorer, and yet if you do that, XMLHttpRequest is no longer available. And if you are using something like JAWS, it's often much less problematic to switch Javascript off altogether than to hope it manages to reliably report all the different ways in which Javascript can alter a page.

And no, XMLHttpRequest doesn't work in "all the other niche browsers". Not all the other niche browsers even implement client-side scripting at all, let alone XMLHttpRequest.

Even if you are willing to ignore things like this, you might not be able; many countries have accessibility legislation that requires web developers to write accessible code. From a web developer's perspective, the most reliable way to avoid a lawsuit is to follow WCAG, which specifically warns against relying on client-side scripting.

I completely agree with the grandparent, XMLHttpRequest is in no way a base to build upon, and I'd strongly recommend reading the document he's linking to, because it's quite clear you haven't done so yet.

Thank god the W3C deprecated the blink tag

Proper HTML based slashdot?

I agree with you that xhtml is of little advantage over html. You are also correct that good alt content can compensate, to some extent, for the ill considered overuse of graphical text. Still basic syntax checking is easy, and it's a hallmark of quality for those enlightened enough to look for it. Yes, one can find well designed commercial sites that are not valid. One cannot, however, find valid commercial sites that are not well designed! The results for SCR Online are poor, but quite typical for an ISP.

Okay, Mister Sarcasmpants. Screw Google. Which search engine actually serves valid HTML pages to me?

(Give up? It's MSN! MSN's search page, search.msn.com, is valid HTML! The results pages are too. Time for you to switch.)

Okay, Mister Sarcasmpants. Screw Google. Which search engine actually serves valid HTML pages to me?

(Give up? It's MSN! MSN's search page, search.msn.com, is valid HTML! The results pages are too. Time for you to switch.)