Slashdot Mirror

Better yet, get a copy of HTML-Kit which implements HTML-Tidy.

Google, Yahoo and Slashdot use pretty simple HTML!? Ya, right. Its not even HTML. Try running any of these sites through an HTML validator.

Another thing most web designer seam to dislike is to write correct HTML code.

I suggest you all go to the W3 validator and test you web pages so that they conform to a HTML standard. Surpricingly many webpages ar invalid:

http://validator.w3.org/

Working html is much more usable

with the w3

also, bobby seems a bit bothered

[N]ote that HTTP has one feature over FTP that I forgot about until now. Content-type!

Yeah, this is a weakness in the FTP protocol - though, in it's favor, I don't think HTTP allows for LOCAL typing/interpretation. You're right, Content-Type alleviates type confusion here.

What? You've never tried to go to a page and been presented with a pop-up box asking you for user and password for such-and-such an authentication domain?

HTTP defines the "Auth-Type" header, with the two commonly supported methods "Basic" and "Digest" (the latter does not send cleartext passwords).

You originally mentioned a strength of HTTP being other means of authorization outside of plaintext. I've never seen a common working implementation of Digest Authorization.

Yes, I'm familiar with these concepts and yes, I've encountered and used Basic Authorization before.

Cookie and URL-based authorization are still plaintext transmission, by and large, and prone to their own issues. And I still think that use of SSL raises its own headaches.

Several command-line http clients implement "reget" functionality using the "Range" or "Byte-Range" (whatever it's called) HTTP header, which I think (but am not sure) even /1.0 supports.

No, Byte-Range/Range are 1.1 functionality, afaik. Things like wget are appropriate here, but are really tailored to snarfing websites, though I suppose one could tailor these implementations to a broader range of needs.

I'll leave the remainder of your post alone. You've convinced me that you can apply things as appropriate, raised a number of valid points, and similarly agree that there might not be a good, interactive HTTP client to replace FTP just yet. WebDAV developments, mentioned elsewhere, might hold promise. Who knows?

Not to mention that 'JIF' sounds too much like JFIF (obsolete but technically correct term for JPEG files).

HTML is based on SGML = Standardized General Markup Language.

w3.org

OVERDONE WEB PAGES:
I agree with your point. I always advocate simplistic, standards-compliant web pages (after all HTML is about content, not appearance!). To see how dependent recent web pages are on plugins, one only needs to spend a few minutes browsing with a vanilla Mozilla build. :-(

NETSCAPE ON IRIX:
Have you tried Mozilla for IRIX? Mozilla itself is somewhat bloated IMHO, but it is becoming quite stable and should easily run on the Indigo box you mention. Have a look at SGI Freeware for an inst package.

A DECENT BROWSER ON IRIX:
Maybe it's worth seeing whether Galeon will build on IRIX. (I expect this will require some work, as recent GNOME libraries don't seem to be readily available on IRIX.)

How about Amaya?

Surely this kind of issue is what Tim Berners-Lee and the W3C is trying to address with the Semantic Web.

The problem with content on the web today is that while it is perfectly readable by humans, it is incomprenesible to machines. If Tim and Co get their way, and I for one would love to see the Semantic Web catch on, then we can get rid of kluges like the Anti-Thesaurus, HTML meta keywords and the like.

Marking up pages with information about the meaning of the terms on them is the main thrust of the work on semantic web - see http://www.daml.org/ (for DAML - the DARPA Agent Markup Language), http://www.semanticweb.org/ (One of the main information sources) and finally the new W3C activity on the subject: http://www.w3.org/2001/sw/.

How far, how fast it will go is another matter but there's certainly a lot of interest in creating a more "machine readable" web.

And remain ignorant... From it's inception .NET by its definition is an open architecture... it is designed to be cross platform on the server and client side

Have we forgotten Mono by Ximian ?

ASP.NET is designed to function within any browser from Netscape 3.0 upwards... The core artchitecture of .NET is based on XML... which is about as open a standard as you will ever find.

So.... please tell me how is it someone developing on .NET may find themselves locked into a Gatesian world ?

As for waiting for a standards body.... the core architecture .NET platform is based on open standards much of which is administered by the W3C organisation.

As for the the moderator scoring these comments.... I guess your scoring method is based on 99% anti-MS sentiment, 0.5% for its intelligence and another 0.5% for how informed it is.

I don't think XML by itself carries enough metadata to understand much beyond whether a document is valid or not. I think RDF and RDFS have a big role to play in getting XML database ready.

Perhaps hopping on the XML database bandwagon before RDF technologies mature could be a mistake. Forget the semantic web, I want to see the sematic database.

W3 RDF

A Good RDF resource

XML has, of course, a hierarchical structure

Just because XML is a hierarchical markup language does not mean that it can only be used for hierarchical things. Perhaps you should look at RDF which can use many to many mappings through resources and groupings (sequences, bags, and alternates). (A resource in one grouping can refer to another grouping i.e. many to many.)

RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 is a good read. It illustrates that, contrary to popular belief, HTTP is not a protocol defined solely for "web page requests". It is actually a general-purpose protocol for reading and writing data, creating and deleting resources, proxying, etc. No wonder SOAP (amongst other things) builds on top of it. It is a very flexible network transport layer. The danger really comes from how HTTP/SOAP are implemented. In other words, how secure is the server? Recent issues with IIS allowing full write access to FAT-based web directories shows how poor security design in software can lead to all kinds of unintended consequences.

PNG was supposed to replace GIF because (Unisys?) was going to uphold patents on GIF

Also because PNG is Turbo Studly standard and supposedly unencumbered.

Has anyone even seen a PNG file online? I think I ran across a grand total of 1. Of course there could have been inline graphics that I didn't notice, but really?

Yeah, inline graphics are pretty rare on the web. Plus, some sites are designed to give you PNG if your browser supports OBJECT PNG, and GIF otherwise.

From my mozilla cache:
file * | grep PNG | wc -l = 20
file * | grep GIF | wc -l = 546

Of course, I do spend a lot of time on http://pnggygirls.com.

From Altavista:
image:bmp (348,527 results)
image:png (1,726,036 results)
image:jpg (204,606,124 results)
image:gif (452,012,967 results)

Looks like PNG is kicking BMPs butt!

XML wouldn't be a good alternative for CLM2, but it's squarely in scope for RDF and the Semantic Web.

XML wouldn't be a good alternative for CLM2, but it's squarely in scope for RDF and the Semantic Web.

Ah crap, (I cant believe how retarded slashdot is, I did it to fast and it said the "slow down cowboy" BS, when I backed up my text was gone, so I repasted but forget to correct it, grrrr)

http://lists.w3.org/Archives/Public/www-patentpoli cy-comment/2001Sep/0734.html

Shit man, click links people. I clicked on the link to the W3 page (http://www.w3.org/2001/07/SVG10-IPR-statements.ht ml) and right there at the top clearly stated:

Update: Adobe have updated their license to clarify that it is, indeed, Royalty-Free.

Talk about quick overreaction. Maybe check out the links and info before posting a story next time?

http://www.w3.org/Graphics/PNG/ is the page on the W3C's site on the subject.

A quick check of the HTML indicates that CSS positioning was used; Nutscrape...doesn't know how to implement CSS positioning. Internet Explorer works properly; Mozilla and Opera should work too

So, you're in agreement: It was a braindead web design. "Use my browser or don't view my webpage" is braindead web design. Period.

It's worth noting that a properly-designed page should render reasonably well in any browser, to the limit of the browser's capabilities. Try calling up the page given here in Lynx, for instance; I wouldn't be surprised if it renders properly in Lynx (sans images, of course).

If your browser doesn't render pages properly, you might want to consider upgrading to a better browser, one that properly implements the published standards.

A quick check of the HTML indicates that CSS positioning was used; Nutscrape...doesn't know how to implement CSS positioning. Internet Explorer works properly; Mozilla and Opera should work too

So, you're in agreement: It was a braindead web design. "Use my browser or don't view my webpage" is braindead web design. Period.

It's worth noting that a properly-designed page should render reasonably well in any browser, to the limit of the browser's capabilities. Try calling up the page given here in Lynx, for instance; I wouldn't be surprised if it renders properly in Lynx (sans images, of course).

If your browser doesn't render pages properly, you might want to consider upgrading to a better browser, one that properly implements the published standards.

Have you read this linked page? Have you read any statements made by Apple that they are using this patent to prevent you from using the PNG format?

If you look at that page, you will see that Apple does offer a license for the patent as part of the SVG 1.0 patent which is being put together. It looks like they are just being cautious in order to keep their rights to the patent intact, but still allow it to be used for PNG and SVG.There are plenty of greedy corporations out there and Apple may in fact be one, but don't assume they are without looking at all the facts. Take a look at the sites listed in this article, write to Apple and ask questions, express your thoughts to Apple. If you are not then satisfied with what you see then you can make as much noise about it as you want. Making a big deal about this just because someone has implied wrongdoing on Apple's part is just being a follower.

Well, since the subject was Netscape's failure to properly render CSS positioning, and since CSS wasn't in the HTML standards of "many years ago," you basically support my position. By the way, did you follow the link I gave [anybrowser.org]?

CSS1 has been a standard since December 1996, CSS2 since May 1998. Don't give any crap about NS4 being older than the spec because it isn't really true. CSS didn't spring forth from the head of Berners-Lee, NS and MS both helped design the standard. At the time Netscape was pushing their proprietary HTML tags and CSS implementation and didn't bother to implement the standards. NS4 is intentionally broken.

I do blame Netscape for failing to implement the standards that they helped to create. It's very, very sad that browser implementations are 5 years behind their own standards, keeping web design in the dark ages. Blinking purple text on a blinking starfield background (with flames!!) here I come !!

Well, since the subject was Netscape's failure to properly render CSS positioning, and since CSS wasn't in the HTML standards of "many years ago," you basically support my position. By the way, did you follow the link I gave [anybrowser.org]?

CSS1 has been a standard since December 1996, CSS2 since May 1998. Don't give any crap about NS4 being older than the spec because it isn't really true. CSS didn't spring forth from the head of Berners-Lee, NS and MS both helped design the standard. At the time Netscape was pushing their proprietary HTML tags and CSS implementation and didn't bother to implement the standards. NS4 is intentionally broken.

I do blame Netscape for failing to implement the standards that they helped to create. It's very, very sad that browser implementations are 5 years behind their own standards, keeping web design in the dark ages. Blinking purple text on a blinking starfield background (with flames!!) here I come !!

"This document is a submission to the World Wide Web Consortium (see Submission Request, W3C Staff Comment) to propose the formation of a working group in the area of XML-based protocols. Comments are welcome to the authors but you are encouraged to share your views on the W3C's public mailing list (see archives)."

No, XML is just a family of languages. You might however want to have a look at SVG (Scalable Vector Graphics), a XML-based format for (surprinsigly) vector graphics. See also here

Drawing tools are beginning to be able to save also in SVG format. We may soon see open source tool that natively save data in SVG format...

• W3C Web Accessibility Initiative
• HWG AWARE Center
• International Center for Disability Resources on the Internet

I've compared the same site with and without mod_gzip over a modem, and mod_gzip is definately faster. http://www.w3.org/Protocols/HTTP/Performance/Compr ession/PPP.html agrees - fewer packets because of smaller data = faster performance on a modem. In addition, V.42bis checks to see if its own compression would be beneficial or not, and if not, it switches over to transparent mode. V.44 does the same thing, and compresses better. At http://www.digit-life.com/articles/compressv44vsv4 2bis/, if you look at table3, you'll see that pkzip compresses everything [that's not already compressed] about twice as much as either modem standard.

So, mod_gzip *does* in fact help out modem users, as it compresses data much more than any modem does, reducing the total amount of data to be sent by a greater amount while simultaneously reducing the number of packets sent.

I use mod_gzip, and everyone else should too. :)

For those interested, http://www.w3.org/TR/SVG/, is the specification to SVG 1.0.

Nautilus, the GNOME filemanager and graphical shell uses SVG
(actually librsvg) for drawing vector icons and rendering anti-aliased fonts.

Such a device will be very handy for people that have visual impairments. Instead of the current bulky and expensive kits, this will be an improvement, especially for VI users out-and-about.

What can you do? Make your web pages accessible for a start.

The Patent Policy Working Group makes decisions by consensus. Invited experts are considered equally with W3C Members in assessing consensus. Note (not particularly in response to your question) that consensus means broad agreement, not unanimity. Under W3C process, those who dissent from consensus decisions have a right to file minority reports, what we call a formal object.

W3C's initial response to public comments on RAND could be construed as
an attempt to control the debate via a "good bill/bad bill" strategy.
That is, the current status quo is for the Web to be based on open,
non-proprietary standards. A proposal is mooted to implement a RAND (or
UFO) policy for new Web standards. Critics of this policy are then told
that they must "be constructive" in their criticism of the UFO policy,
as the choice is between a very onerous UFO policy and one which, having
been "constructively criticized", is only slightly less onerous. The
choice of retaining or strengthening the status quo (no patented
technology in Web standards) is taken off the table before the debate
begins.

sPh

Once they can create static content, let them play with server side includes first. It's a good introduction to dynamic content and it's pretty simple. It's also standard on most web platforms (Netscape, sorry, iPlanet, Apache, IIS).

You're not going to be able to instruct them on real dynamic content without teaching them databases as well, which is a problem. 90% of dynamic content on the web has a DB backend, whether it be Oracle, mySQL, PostreSQL or SQL server. To design that side correctly, you need to understand how to delegate responsibilities to the DB (i.e. foreign keys, referential databases etc). However, if you can get that side done, ASP has some advantages:

1. It has a large market share and is probably more employable than PHP/perl
2. You can get personal web server (at least under win9x) to play around on home machines
3. as it's VB based, it's pretty simple.
4. I'd imagine it works well with Frontpage if that's what you want to use as a tool (and let's face it, for new computer users, it's not a bad idea)

Good luck!

You can subscribe to it by sending a message to:

www-patentpolicy-comment-request@w3.org

with subject 'subscribe' and body:

subscribe <your email address>

Archives are here.

You'll do a lot more good by subscribing to, and posting to the patentpolicy-comment list than by posting here. Oh, you don't have to be subscribed to the list to email to it, but it's well worth making the extra effort.

More comments to the public comment archive would certainly be welcome. There will be another public Last Call draft released before we make any final decision. Comments on this next draft would be particularly useful. We've heard a fair amount about the current draft already.

sPh

sPh

Furthermore, Safesurf's web site violates Safesurf's proposed law creating (and mixing up) civil and criminal penalties and tort liability for mislabeling or failing to label web sites. Their original proposal was more aggressive than their current one, but it still doesn't require any actual harm to any actual child, as long as there are graphic images on the site (logos and decorations may not be harmful, but they're graphics, so we're covered there.) Plaintiffs can sue if the site doesn't provide appropriate ratings labels on material severe enough to be potentially harmful to children. Certainly, any proposal to throw people in jail for what they write on the net is pretty severe, and could cause harm to children who write things without labeling them if such a law were passed, and telling kids that people want to do that kind of harm to them just for what they write, even if there's no law passed, can also be pretty scary. www.safesurf.com's label says

"CONTENT='(PICS-1.1 "http://www.classify.org/safesurf/" l r (SS~~000 1))'"

which if you look it up on the explanatory web site doesn't have any indication of what the rating means. It does point to a site that tells you how to download a ".rat" file into your browser, and if you open up that file with a text editor instead of installing it, the file indicates something about "all ages", but doesn't indicate whether it's appropriate or inappropriate for all ages, so that a web browser could be set to do the appropriate thing with it, though it clearly implies that the really scary material complained about above should be appropriate for all ages....

"http://www.w3.org/TR/REC-PICS-services" has more PICS explanations.

Update - their web page indicates that MAPS has now unblocked them.

The HTML 4.01 spec does not define buttons as generic containers; in fact, it refers explictly to their extra rendering requirements.

Note: In CSS1 & CSS2 the form elements of HTML were also counted as replaced elements, because they were considered to be replaced by buttons, text fields, etc. that were proprietary to the platform. In CSS3 these elements are normal, non-replaced elements. CSS3 has explicit properties that can make them look like they did in CSS1 and CSS2 (or make them look completely different).

Native widgets on both Windows and Mac have transparent backgrounds and draw in a z-ordered way.

The HTML 4.01 spec does not define buttons as generic containers; in fact, it refers explictly to their extra rendering requirements.

Note: In CSS1 & CSS2 the form elements of HTML were also counted as replaced elements, because they were considered to be replaced by buttons, text fields, etc. that were proprietary to the platform. In CSS3 these elements are normal, non-replaced elements. CSS3 has explicit properties that can make them look like they did in CSS1 and CSS2 (or make them look completely different).

Native widgets on both Windows and Mac have transparent backgrounds and draw in a z-ordered way.

No offense, but that's just not true. An interactive element is not an empty DIV. It has a content area. That content area contains a button.

The goal there is to be able to use system default appearances, not to get away from system default appearances.

Again, for those who have trouble reading spec language, that says that CSS3 is meant to use default system widget appearances, and that Mozilla is not going to be able to support CSS3 because it uses its own non-standard widget appearances.

No offense, but that's just not true. An interactive element is not an empty DIV. It has a content area. That content area contains a button.

The goal there is to be able to use system default appearances, not to get away from system default appearances.

Again, for those who have trouble reading spec language, that says that CSS3 is meant to use default system widget appearances, and that Mozilla is not going to be able to support CSS3 because it uses its own non-standard widget appearances.

I agree that the CSS spec certainly does not require that any form widgets be stylable. The CSS2 model is not sufficient to describe the rendering of even the simplest form widgets (mainly due to the weakness of its anonymous content generation and lack of some concepts in the box model). Therefore the CSS spec doesn't define how form widgets should respond to CSS styles. I think (although some others disagree) that this implies that a user-agent that applies any CSS styles to form controls is extending CSS.

Proposals such as XBL would add to CSS a model that is sufficient to describe the behavior of form controls. With that or a similar proposal one could have styling of form controls within the CSS spec.

Even then, I doubt the CSS spec would ever require that user-agents avoid native form controls in favor of stylable ones. (It is possible that user agents with native form controls would not be able to implement all modules of CSS since they would not be able to implement the module describing the styling of form controls.) After all, native form controls give the user a more consistent and usually better user interface.

-David

I agree that the CSS spec certainly does not require that any form widgets be stylable. The CSS2 model is not sufficient to describe the rendering of even the simplest form widgets (mainly due to the weakness of its anonymous content generation and lack of some concepts in the box model). Therefore the CSS spec doesn't define how form widgets should respond to CSS styles. I think (although some others disagree) that this implies that a user-agent that applies any CSS styles to form controls is extending CSS.

Proposals such as XBL would add to CSS a model that is sufficient to describe the behavior of form controls. With that or a similar proposal one could have styling of form controls within the CSS spec.

Even then, I doubt the CSS spec would ever require that user-agents avoid native form controls in favor of stylable ones. (It is possible that user agents with native form controls would not be able to implement all modules of CSS since they would not be able to implement the module describing the styling of form controls.) After all, native form controls give the user a more consistent and usually better user interface.

-David

I agree that the CSS spec certainly does not require that any form widgets be stylable. The CSS2 model is not sufficient to describe the rendering of even the simplest form widgets (mainly due to the weakness of its anonymous content generation and lack of some concepts in the box model). Therefore the CSS spec doesn't define how form widgets should respond to CSS styles. I think (although some others disagree) that this implies that a user-agent that applies any CSS styles to form controls is extending CSS.

Proposals such as XBL would add to CSS a model that is sufficient to describe the behavior of form controls. With that or a similar proposal one could have styling of form controls within the CSS spec.

Even then, I doubt the CSS spec would ever require that user-agents avoid native form controls in favor of stylable ones. (It is possible that user agents with native form controls would not be able to implement all modules of CSS since they would not be able to implement the module describing the styling of form controls.) After all, native form controls give the user a more consistent and usually better user interface.

-David

I agree that the CSS spec certainly does not require that any form widgets be stylable. The CSS2 model is not sufficient to describe the rendering of even the simplest form widgets (mainly due to the weakness of its anonymous content generation and lack of some concepts in the box model). Therefore the CSS spec doesn't define how form widgets should respond to CSS styles. I think (although some others disagree) that this implies that a user-agent that applies any CSS styles to form controls is extending CSS.

Proposals such as XBL would add to CSS a model that is sufficient to describe the behavior of form controls. With that or a similar proposal one could have styling of form controls within the CSS spec.

Even then, I doubt the CSS spec would ever require that user-agents avoid native form controls in favor of stylable ones. (It is possible that user agents with native form controls would not be able to implement all modules of CSS since they would not be able to implement the module describing the styling of form controls.) After all, native form controls give the user a more consistent and usually better user interface.

-David

I agree that the CSS spec certainly does not require that any form widgets be stylable. The CSS2 model is not sufficient to describe the rendering of even the simplest form widgets (mainly due to the weakness of its anonymous content generation and lack of some concepts in the box model). Therefore the CSS spec doesn't define how form widgets should respond to CSS styles. I think (although some others disagree) that this implies that a user-agent that applies any CSS styles to form controls is extending CSS.

Proposals such as XBL would add to CSS a model that is sufficient to describe the behavior of form controls. With that or a similar proposal one could have styling of form controls within the CSS spec.

Even then, I doubt the CSS spec would ever require that user-agents avoid native form controls in favor of stylable ones. (It is possible that user agents with native form controls would not be able to implement all modules of CSS since they would not be able to implement the module describing the styling of form controls.) After all, native form controls give the user a more consistent and usually better user interface.

-David

There is no difference to CSS whether I have: <button>hello</button> or <div>hello</div>

No offense, but that's just not true. An interactive element is not an empty DIV. It has a content area. That content area contains a button.

Also please note that the CSS2 spec explicitly says that backgrounds should not be set for HTML items: The background of the box generated by the root element covers the entire canvas. For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. User agents should observe the following precedence rules to fill in the background: if the value of the 'background' property for the HTML element is different from 'transparent' then use it, else use the value of the 'background' property for the BODY element.

For those of you with trouble reading spec-ese, this means a couple of things. First, the allegedly required functionality (widget background setting) is actually recommended against in the specification.

Second, the Mozilla implementation misinterprets the spec. Having a button on a BODY that has a background image or background color would create the same visual effect within the button's bounding box as setting the button's own background image or background color -- which is to say, a surround effect, not a fill effect.

The supposedly required functionality is not required, and Mozilla is interpreting the functionality in a clearly incorrect way.

Having said all that, current CSS recomendations may not be able to adequatly describe the visual rendering of all form elements but that is where we are heading [w3.org]. Ultimatly while form elements may normally look like they've been rendered with this style sheet [w3.org] there's nothing to stop the web author or end user modifying those attributes as they can any other attributes on any other element.

Nope, sorry, you're reading that wrong too. The goal there is to be able to use system default appearances, not to get away from system default appearances. Search for the string "system standard rendering" -- it appears many times -- and note statements like:

Section 2.1 of CSS1 and Chapter 18 of CSS2 introduced several user interface related pseudo-classes, properties and values. This proposal extends them to provide the ability, through CSS, to style elements based upon their various user interface related states, and to make an arbitrary structural element take on the dynamic presentation, or system default look and feel, of various standard user interface widgets.

The exact rendering of check and diamond depends on the user agent, but it is suggested that the same glyph which is used on the platform to render a "checked" menu item be used for "check", and similarly for those platforms which support rendering of a "diamond" next to a menu item. Conformant user agents may render 'diamond' the same as 'check'. The radio- and checkbox- values are rendered as they are by default on the platform.

Again, for those who have trouble reading spec language, that says that CSS3 is meant to use default system widget appearances, and that Mozilla is not going to be able to support CSS3 because it uses its own non-standard widget appearances.

Tim

There is no difference to CSS whether I have: <button>hello</button> or <div>hello</div>

No offense, but that's just not true. An interactive element is not an empty DIV. It has a content area. That content area contains a button.

Also please note that the CSS2 spec explicitly says that backgrounds should not be set for HTML items: The background of the box generated by the root element covers the entire canvas. For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. User agents should observe the following precedence rules to fill in the background: if the value of the 'background' property for the HTML element is different from 'transparent' then use it, else use the value of the 'background' property for the BODY element.

For those of you with trouble reading spec-ese, this means a couple of things. First, the allegedly required functionality (widget background setting) is actually recommended against in the specification.

Second, the Mozilla implementation misinterprets the spec. Having a button on a BODY that has a background image or background color would create the same visual effect within the button's bounding box as setting the button's own background image or background color -- which is to say, a surround effect, not a fill effect.

The supposedly required functionality is not required, and Mozilla is interpreting the functionality in a clearly incorrect way.

Having said all that, current CSS recomendations may not be able to adequatly describe the visual rendering of all form elements but that is where we are heading [w3.org]. Ultimatly while form elements may normally look like they've been rendered with this style sheet [w3.org] there's nothing to stop the web author or end user modifying those attributes as they can any other attributes on any other element.

Nope, sorry, you're reading that wrong too. The goal there is to be able to use system default appearances, not to get away from system default appearances. Search for the string "system standard rendering" -- it appears many times -- and note statements like:

Section 2.1 of CSS1 and Chapter 18 of CSS2 introduced several user interface related pseudo-classes, properties and values. This proposal extends them to provide the ability, through CSS, to style elements based upon their various user interface related states, and to make an arbitrary structural element take on the dynamic presentation, or system default look and feel, of various standard user interface widgets.

The exact rendering of check and diamond depends on the user agent, but it is suggested that the same glyph which is used on the platform to render a "checked" menu item be used for "check", and similarly for those platforms which support rendering of a "diamond" next to a menu item. Conformant user agents may render 'diamond' the same as 'check'. The radio- and checkbox- values are rendered as they are by default on the platform.

Again, for those who have trouble reading spec language, that says that CSS3 is meant to use default system widget appearances, and that Mozilla is not going to be able to support CSS3 because it uses its own non-standard widget appearances.

Tim