Slashdot Mirror

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

wget www.ssdlfkjsdf.com
--04:51:57-- http://www.ssdlfkjsdf.com/
=> `index.html'
Resolving www.ssdlfkjsdf.com... done.
Connecting to www.ssdlfkjsdf.com[64.94.110.11]:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://sitefinder.verisign.com/lpc?url=www.ssdlfkj sdf.com&host=www.ssdlfkjsdf.com [following]

I think I want to cry... a tear in my beer in cheer! Hurrah! Do you think anyone is upset that the letter doesn't validate? ;-) I guess it's difficult to follow every every standard when your in a rush to publish.

My most used search will probably be: "I want this-and-that for dinner tonight, what do I need?" The UA would first contact my fridge to see what is in there, then look up recipes for the food I want, then query nearby stores to see what they have on offer and at what prize, and then report back to me where I should be going to get what I need at the best prize. Really, I don't think this should be that far into the future...

That would be the "alt" attribute.

to hear Google's take on how to get there. I assume he/they imagine the web evolving to something like Tim Berners-Lee's idea of the Semantic Web where meaning is embedded. I think we have a long way to go...

And I screwed up my link there - w3.org

and makes pages load faster for MSIE users

To expand on that statement a little bit, when a web page is fully compliant with the HTML 4.0 or XHTML standards, the browser will operate in "standards-compliant mode" (aka "strict mode", "full standards mode" or just "standards mode"). If not standards compliant, the browser will operate in "compatibility mode" (aka "Traditional mode", "Loose mode" or "quirks mode"). The standards-compliant mode will render the page much faster than the compatibility mode. That is true for both IE and Mozilla. The mode is selected by examining the DOCTYPE declaration. Also, the way that the page is rendered could vary depending on the mode the browser had decided to operate in.

Unfortunately, very few sites out there that work in all browsers correctly are compliant.

Mine (Overcaffeinated) is. And it displays the same in everything from Firebird to Explorer to Safari to Konqueror to PDA browsers (no 4.x browsers supported).

It's not about avoiding Explorer, just its glitches. You can do wonders with CSS, and tweak it to work well with most browsers without using hacks. It takes some more time, but it's doable. and in the long run, it pays to have compliant code. Much easier to modify.

The other way is to learn the hacks (there are lots) that hide content from non-IE browsers or target specific versions. Take a look at Zeldman's css and you'll see quite a few of those. That ensures his site looks the same if you look at it with practically anything. I don't find that to be so maintainable, though (when you update your CSS you have to consider all repeated content that is there to be shown for specific browsers) so I go another way: Code your site around glitches. If a layout method produces iffy results in two browsers, don't use it. Try to be as specific as possible in your div alignment (without resorting to absolute positioning). Always specify all margins of an object. So on. It's quite fun, really =)

By the way, my site design was influenced by Zeldman's. I love his work.

What you get on the older browsers is a very poor presentation. For example, if you define the look of your page in cascading stylesheets, when viewed on a browser with no support for CSS, you get crap.

If you do your css correctly, what you get in browsers that don't support css at all is a page that looks like it was coded in plain vanilla html. Oh no! Big H1s! Purple vlinks! And no carefully crafted marketing widgets! But at the very least, the MESSAGE contained within the html is still available and legible.

As for browsers with partial css support, this is where an understanding of the shortcomings of different browsers and, more importantly, testing comes into play. (You do test your sites, don't you?) Regardless of whether you are going to make a nested-table, font-tag infested site or a css-complaint site, or anything in between, any web designer worth his or her salt is going to a) know the methods for effectively rendering the content in most browsers and b) test the hell out of those designs to make sure his or her assumptions are correct.

The designs you cited as displaying poorly had as much -- if not more -- to do with poor testing as it did with CSS support/non-support. You even note as much in your aside about the Texas site:

"But no, they don't actually care (I talked to these people, and they really don't care)"

The construction of the page itself is sloppy. The author uses nested table hell to construct the page, and even with the sloppy-friendly doctype of html transitional, it STILL doesn't validate as valid html 4.01. You cannot put that page's problems all at the feet of CSS.

You note that "Mixing standards can cause problems as well." True enough...but that's even more reason to pick one standard and use it!

Ironically, the pages that you cite as two that "look fine" in older browsers simply don't validate as well. That's great for the users who use Netscape 4. It's also great for whatever designer ever gets to redesign those sites...because they're so full of nested tables and inline half-assed styles that they'll easily be able to charge those States for 3 or 4 or 10 times what a css-centered update would cost.

This is not to say that designers only use CSS because it is easier for them to reprogram, but if you accept the basic premise of css -- that html is for structural markup and css is for presentation -- the ease of redesign is a happy side effect. If done correctly, the content (which, many would argue, is the most important part of the page) is not dependant on the whims of styling that may or may not display on a given user's browser.

In fact your concern that "many in that audience will be using older computers which have smaller drive space, smaller RAM space, slower CPUs, and can only run older versions of operating systems and browser software" is actually helped by a page that depends on properly coded html/css. Because, after all, those older browsers on older systems will ignore the css sheet and display the raw HTML, delivering just the content. This means less time spent rendering unnecessary display tables, less time futzing with every font styled inline, less time loading the widgets the user doesn't need.

Done properly, html/css really does help reach a larger audience. It may not look exactly like the marketing manager wants it to, but it is still better than nothing.

(And really, if your boss doesn't mind you coding separate pages for every possible os/browser combo, more power to you. Your job is probably more secure than mine. ;-)

The original idea behind the web was that it was a simple distributed application for sharing information at places like CERN. They didn't worry about look-and-feel issues because they didn't think there would be any. If you're just using the web to share your informal notes on your latest particle physics experiment, you don't care exactly what your document elements look like, as long as the overall organization is clear to the reader. Thus the very first HTML specification says things like:

A list is a sequence of paragraphs, each of which is preceded by a special mark or sequence number.... The representation of the list is not defined here, but a bulleted list for unordered lists, and a sequence of numbered paragraphs for an ordered list would be quite appropriate.

HTML was also designed to make web pages easy to author. Which meant that web browsers had to be tolerant of small mistakes. Both these principles forced browser implementers to make a lot of choices about presentation without any guidance from the standards.

What the web's inventors didn't anticipate is that the web would become a mass medium. (So much so that most web users don't even grasp that the web and the internet are not the same thing.) When they saw this happening, they starting thinking about presentation issues and inventing style-sheet languages. But it took them years to thrash out new HTML and CSS specifications that dealt with these issues. But at the same time (1995 and thereabouts) Netscape was gearing up to deliver commerical web software. (Microsoft was still in denial about the Internet, and had launched MSN using proprietary client-server protocols.) Netscape wasn't willing to wait even a few months for W3C to deliver preliminary specifications: they saw their window of opportunity closing. So they invented their own. They took a lot of flack for this from people who pointed out that Netscape HTML violated all the rules of good markup. But Netscape wasn't interested in those issues -- they just wanted to deliver a browser that could display pretty web sites.

And of course when Microsoft joined the fray, they had the same attitude, only more so. So all the thousands of newly-minted web designers were indoctrinated to think in terms of tweaking proprietary HTML until it displayed correctly on one or two "preferred" browsers.

It's going to take a long time to reverse this mindset, and I doubt if it will ever disappear completely. It certainly doesn't help that no browser properly supports all the features of CSS2, which is the most important tool of the standard-complying web designer.

The original idea behind the web was that it was a simple distributed application for sharing information at places like CERN. They didn't worry about look-and-feel issues because they didn't think there would be any. If you're just using the web to share your informal notes on your latest particle physics experiment, you don't care exactly what your document elements look like, as long as the overall organization is clear to the reader. Thus the very first HTML specification says things like:

A list is a sequence of paragraphs, each of which is preceded by a special mark or sequence number.... The representation of the list is not defined here, but a bulleted list for unordered lists, and a sequence of numbered paragraphs for an ordered list would be quite appropriate.

HTML was also designed to make web pages easy to author. Which meant that web browsers had to be tolerant of small mistakes. Both these principles forced browser implementers to make a lot of choices about presentation without any guidance from the standards.

What the web's inventors didn't anticipate is that the web would become a mass medium. (So much so that most web users don't even grasp that the web and the internet are not the same thing.) When they saw this happening, they starting thinking about presentation issues and inventing style-sheet languages. But it took them years to thrash out new HTML and CSS specifications that dealt with these issues. But at the same time (1995 and thereabouts) Netscape was gearing up to deliver commerical web software. (Microsoft was still in denial about the Internet, and had launched MSN using proprietary client-server protocols.) Netscape wasn't willing to wait even a few months for W3C to deliver preliminary specifications: they saw their window of opportunity closing. So they invented their own. They took a lot of flack for this from people who pointed out that Netscape HTML violated all the rules of good markup. But Netscape wasn't interested in those issues -- they just wanted to deliver a browser that could display pretty web sites.

And of course when Microsoft joined the fray, they had the same attitude, only more so. So all the thousands of newly-minted web designers were indoctrinated to think in terms of tweaking proprietary HTML until it displayed correctly on one or two "preferred" browsers.

It's going to take a long time to reverse this mindset, and I doubt if it will ever disappear completely. It certainly doesn't help that no browser properly supports all the features of CSS2, which is the most important tool of the standard-complying web designer.

*cough*

• CSS level 1: Not full support despite MS claiming so. E.g.background-attatchment: fixed; works only on the <body element.
• CSS level 2: Quite a mess, lots of things are broken, e.g. the infamous issues with the box model, and lots of things are not implemented, e.g. position: fixed;
• XML support is flaky at best, it tends to complain about DTDs even though they are valid.
• Other nasty quirks such as when having a <?xml ... ?> declaration, then it ignores the doctype and reverts to quirks mode with all the broken box models and such.
• Violation of the HTTP specification by ignoring the media type received from the server. Internet Explorer will most of the time second-guess the media type instead.
  
  http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.h tml#sec7.2.1

  If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource.

The W3C MarkUp Validation Service will validate to different standards (choose from the "Type" selection list), so I can validate to HTML 3.2 or even HTML 2.0 if I wish.

... someone could spring and buy a copy for our hosts?

Granted, some parts of the W3 standards are worth breaking (wrap attributes in textrea inputs, for instance), but c'mon.

J

Quick, without peeking at the answer, what's the difference between a URI, a URL, and a URN? OK, now that we are all on the same page :-), what is "info:"? you'd expect it to be a URN. It isn't (from the RFC):

7.2 Why Not Use a URN Namespace ID for Identifiers from Public Namespaces?

RFC 2396 [RFC2396] states that a "URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier". An "info" URI on the other hand does not assert persistence of resource names or of the resource itself, but rather declares namespaces of identifiers managed according to the policies and business models of the Namespace Authorities. Some of these namespaces will not have persistence of identifiers as a primary purpose, while others will have locator semantics as well as name semantics. It would therefore be inappropriate to employ a URN Namespace ID for such namespaces.

Which I read to mean that an info: URI may, or may not, be a URL (i.e., useful for actually accessing the resource); may, or may not, be a URN (i.e., provides some semblence of a chance that it means the same thing today as it did yesterday). Oh, did I mention that it may, or may not, be case sensitive, and may or may not be subject to scheme-specific normalization rules?

It seems that someone (say "Perfection") got fed up holding the fort agains a hoard of requests for top-level URI schemes - or someone (say "Kludge") got fed up with the demand that these schemes actually have some well defined semantics. Or both. Either way, they had this brilliant notion... why don't we have a junk^H^H^H^Hinfo: URI scheme with as little control over semantics as we can get away with? If some top-level URI scheme sucks, we'll just put it there. We'll spin off a company to be the registrar so "Perfection" will be able to pretend not to see it, and "Kludge" will be able to register all the junk^H^H^H^Hinformation URIs he wants!

I guess it does make some sort of twisted sense... In the meanwhile, proposals like the taguri proposal languish. Here's a years-old proposal that attempts to define coherent semantics for time-persistant identifiers, without requiring a (new) registration agency. We can't have that, can we?

Sigh. Insert mandatory "I for one welcome the arrival of our new info:disposable:gjyr4784ghf89yf4h URI masters" post here...

I bet the RDF advocates (here's a primer) are going to love this, because RDF already uses URIs to refer to objects, although the URIs are often used just as a namespace themselves. In other words, just because you see a URLI in a RDF fragments doesn't mean it actually exists, it's just a name for something. This is not unlike XML namespace use of URIs. If you could refer to more kinds of objects with URLs that could be resolved, that would make RDF more useful.

The big virtue of XHTML is the big virtue of all XML document types: it's open. You can do anything with an XML document. I suppose that's also true of say TeX or RTF. Except these formats are very messy, and it's hard to extract the content from them. A good XML document type is well-structured, and thus relatively easy to access and manipulate.

If all you want to do with a document is display it as a single web page, that's not a big deal. But suppose you want to add it to some well-structured document management system? Or make it a chapter in a book? Or deliver it to a cell phone browser that uses WML or some other simplified markup language? Then all you have to do is write a filter that transforms your XHTML into the necessary XML document type. The possibilities are endless, and all of them are enabled by the simple openness of XML.

There are pitfalls, of course. A good XML application is carefully structured, and thoroughly separates presentation (layout, fonts, etc.) from content. That's why XHTML deprecates the use of formatting tags, like <center> and <font>, which act as if they designate content, but actually designate presentation. But there's nothing to prevent XHTML users from using deprecated features, or designers of other XML applications from structuring their documenting carelessly. So even after you run your document through HTML Tidy, you still might have to jump through a few hoops to transform it into a more sophisticated XML document type, such as DocBook. But the openness of XML makes just hoop-jumping a lot easier.

Anybody who's interesting in playing the XML transformation game needs to learn to program in the #1 XML transformation language, XSLT. This person has written some good introductory material, both online and in book form. Plus her web site neatly demonstrates the flexibility of the technology she teaches and advocates.

That's because that's invalid markup. When it gets tidied, where would you put the form? inside or outside the table?

Well, from the W3C page on HTML 4.01

The FORM element acts as a container for controls. It specifies:
* The layout of the form (given by the contents of the element).
* The program that will handle the completed and submitted form (the action attribute). The receiving program must be able to parse name/value pairs in order to make use of them.
* The method by which user data will be sent to the server (the method attribute).
* A character encoding that must be accepted by the server in order to handle this form (the accept-charset attribute). User agents may advise the user of the value of the accept-charset attribute and/or restrict the user's ability to enter unrecognized characters.

A form can contain text and markup (paragraphs, lists, etc.) in addition to form controls.

Given that information, I would put the form outside the table element, since the table controls the layout of the form. Besides, shouldn't that be part of tidying up code?

HTML Tidy has been our for years.

Check out the Tidy Homepage or the project on SourceForge.

Basically, LBX is crap at reducing round-trip operations. About the only real value in LBX is the compression, which is something you could also get from an SSH tunnel (and indeed SSH tunnel's can /beat/ LBX). However the real killer to X performance is latency, even if you have plenty of bandwidth, X will react very poorly in the face of high-latencies (internet range latency, 50ms+), as its quite "chatty". LBX does very little to improve latency by eliminating round-trip operations - it has "smarts" for only a very very few simple X operations (3 AIUI). In essence, LBX works for bandwidth constrained links (as does SSH), but does little for latency-challenged links - and latency is what hurts X the most, and latency is what most people do not have on internet links. (And on bandwidth constrained links, you end up with latency problems too, as you have to wait for pixmaps and other large X objects to transfer.).

IOW, LBX is pretty useless. Latency is probably where this new NX protocol has made the biggest gains.

For the problems on LBX, read it straight from the horses mouth in this paper by Keith Packard and Jim Gettys on X Window System Network Performance", LBX is discussed specifically towards the end. (Guess where I got the info for my first paragraph? :) )

Forrester's site doesn't validate either. Neither does Slashdot. Guess you'd better get off the Internet.

Forrester's site doesn't validate either. Neither does Slashdot. Guess you'd better get off the Internet.

Following your example we begin having something concrete... like a pic, let's say a nice artistic nude of a fiery redhead.
Then the metadata is telling me that what I am displaying is a 16.000.000 colours jpg.
Now, following your example is confusing, because you say that RDF is the structure of the structure of my message. RDF instead, as I understood it (see http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ ) serves to tell a machine that the pic is a jpg having a very nice, nude, redhaired woman depicted artistically. So RDF jumps from layer 3, to layer directly 1.
Am I wrong?

Why 4 layers? Because everyone gets tired after 3--you don't need more than pointer to pointer to void in C: **mydata. Data plus two levels of abstraction is enough--you reach closure since a pointer to a pointer is still a pointer.

I fail to see the problem in having the RDF Schema around. The RDF Schema is here only to say "RDF must have this syntax". If RDF was going to have a looser structure, then it would have been impossible to fix it down and oblige the writers of RDF-compliant software to stick to a single specification. So interoperability was going away.

Also, why should we loose java? :)

Why couldn't I just make an FOAF schema that pulls in the element types from the appropriate "component" schemas, qualifying the types with the correct namespaces?

It still strikes me that RDF is simply an alternative to XSD, and it's not clear to me why it is a better one.

Actually, a 404 is file not found. Or to quote the W3C: "The server has not found anything matching the URI given."

You don't get a 404 if there is no server present. Normally, the browser/proxy provides the error message, not some badly implemented, english only web server.

This may not be the biggest problem, but it certainly is one.

Actually, a 404 is file not found. Or to quote the W3C: "The server has not found anything matching the URI given."

You don't get a 404 if there is no server present. Normally, the browser/proxy provides the error message, not some badly implemented, english only web server.

This may not be the biggest problem, but it certainly is one.

But Java HAS been around since 1985: http://java.sun.com/features/1998/05/birthday.html

As for the web... well, hypertext at least has been around since the 1960s... *shrug*
http://www.w3.org/History.html

We've only had the Internet since 1969 and the World Wide Web since 1993. Together, they are still fledgling technologies.
Imagine what the Internet could be used for in the future. The Semantic Web or something like it is set to revolutionalize the Internet of the future. Imagine being able to organise and sort information based on the qualaties - instead of quantaties - of the information (See Microsoft's qualatative search). The position the Internet is in today is that most of the information contained in it is quantative in nature, it is stored in a manner that reflects machine organization of information. Qualative information on the other hand is much more useful for performing searches and organizing information, it allows the retrieval of information to be based on attributes rather than specific-word-matches. Going back to the Microsoft search link, using qualatative information as the criteria of the search you could search for a base attribute of "cars" and refine the search using arbitrary attributes such as "sleek form", and "red". In this example, a web page that held information about "Ferrari's" would be included in the "car's" search results even if it did not explicitly contain the word "car" as part of it's web page text - in the semantic web XML markup, "car" would be one of it's attributes.

I obviously can't speak for them, but I can provide some background on what they do. OCLC is a nonprofit org providing services for approx 45,000 libraries around the world. If you are a librarian and need to figure out how to catalog a new book in your collection, you go to OCLC to see how others have done it. Ever needed an item that wasn't in your library? OCLC handles the system for arranging inter-library loans. They do a fair amount of original research for libraries and they even open source some of the results. PURL is another OCLC project that some of you may be familiar with. The Dublin Core MetaData Initiative was co-founded by a researcher who got his start at OCLC and is now running the W3C's Symantic Web Initiaitve. OCLC is very well known and respected in the library community.

Library budgets the world over are under attack given the current economic situation. This leaves less and less money available for building the kind of common infrastructure that will help libraries continue to provide new and relevant services for their patrons as more and more of the content becomes digital. OCLC certainly has both the right and the need to defend the Dewey Decimal Trademarks from infringers.

No need to reinvent the wheel. Since the use of physical cards, paper, or books is obviously an obsolete method of cataloging in the electronic era, the following are likely what future cataloging systems will look like (based on XML, of course):

Some free help with your ad:

"Welcome to Convea, the revolutionary web-based business application platform."

You did that website? Looks absolutely marvellous - but Dreamweaver isn't going to help you post a link here. So learn some HTML. Useful, isn't it? Unless your "revolutionary web-based business application" can live without it.

And for the record, your ad in this context comfortably fits my definition of spam, whatever you say.

Hrmph.

[Definition:] The attribute's value, a URI reference, is the namespace name identifying the namespace. The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). An example of a syntax that is designed with these goals in mind is that for Uniform Resource Names [RFC2141]. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals.

Ummm, no, my logic is based on the XML spec, here read up. To summarize the important bits:

XML Schemas ... provide a means for defining the structure, content and semantics of XML documents.

Only one thing is actually a standard, and Abi's the only one using it, XSL-FO.

Microsoft's xml office will be a binarified version of that with a few proprietary extensions and block -layout object requests for desktop-publishing-like capabilities.

OASIS is just as good a variation of as Microsoft's own, except it's not in binary form (but they do have a compressor in OOo).

Go standardisation!

Mod parent down! I don't see anything about protocols

Mod parent down! I don't see anything about protocols

While not the original interpretation, I prefer to think of the WWW as a giant state engine with all possible pages (including possible dynamically-generated content) as already created and available. Then as you navigate from one page to another, i.e., are transferred from page to page, you are changing from one state to another.

This way of envisioning the WWW is called Representational State Transfer(REST) and is documented by Roy Fielding, one of the WWW's architects, in his doctoral dissertation.

This is not the original interpretation, however, and in both HTTP 1.0 - RFC 1945 and HTTP /1.1 - RFC 2068 the term "transfer" is used in the original sense of transferring data.

While not the original interpretation, I prefer to think of the WWW as a giant state engine with all possible pages (including possible dynamically-generated content) as already created and available. Then as you navigate from one page to another, i.e., are transferred from page to page, you are changing from one state to another.

This way of envisioning the WWW is called Representational State Transfer(REST) and is documented by Roy Fielding, one of the WWW's architects, in his doctoral dissertation.

This is not the original interpretation, however, and in both HTTP 1.0 - RFC 1945 and HTTP /1.1 - RFC 2068 the term "transfer" is used in the original sense of transferring data.

The RFC 2616 - IETF Draft Standard (June 1999) is available in a number of formats at W3C, including pdf.

It's a useful reference and I keep a copy on my desk. If you think you're a web developer and you aren't familiar with http you're sadly deluded.

Dave

The RFC 2616 - IETF Draft Standard (June 1999) is available in a number of formats at W3C, including pdf.

It's a useful reference and I keep a copy on my desk. If you think you're a web developer and you aren't familiar with http you're sadly deluded.

Dave

This book could be a good help. HTTP Developer's Handbook from SAMS gives you a great deal of information about the protocol

You can buy the book

OR

You can read the documentation of RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 and save some money.

You can also read: HTTP/1.1 Specifications

Easy to understand and best of all FREE!!

Not just using POST for changing state server side and GET for other stuff is a mistake that is often made...

The REST stuff is good on this...

Also the W3C document on URIs, Addressability, and the use of HTTP GET and POST, a document being debated on the W3C Technical Architecture Group (TAG) list is debating at the moment [ thread 1 | thread 2 ] also well worth reading...

I wonder if REST is covered in this book?

Not just using POST for changing state server side and GET for other stuff is a mistake that is often made...

The REST stuff is good on this...

Also the W3C document on URIs, Addressability, and the use of HTTP GET and POST, a document being debated on the W3C Technical Architecture Group (TAG) list is debating at the moment [ thread 1 | thread 2 ] also well worth reading...

I wonder if REST is covered in this book?

Not just using POST for changing state server side and GET for other stuff is a mistake that is often made...

The REST stuff is good on this...

Also the W3C document on URIs, Addressability, and the use of HTTP GET and POST, a document being debated on the W3C Technical Architecture Group (TAG) list is debating at the moment [ thread 1 | thread 2 ] also well worth reading...

I wonder if REST is covered in this book?

Not just using POST for changing state server side and GET for other stuff is a mistake that is often made...

The REST stuff is good on this...

Also the W3C document on URIs, Addressability, and the use of HTTP GET and POST, a document being debated on the W3C Technical Architecture Group (TAG) list is debating at the moment [ thread 1 | thread 2 ] also well worth reading...

I wonder if REST is covered in this book?

Wow it's even worse than Slashdot.

One thing I really hate is how people can just put shit code out there on the internet that my browser has to choke on. It seems like respectable sites like Slashdot and News.com.com should try to get these things right.

But I actually know how to write Valid XHTML strict, unlike the bozos at cnet.

Validation

It looks like ass in konqueror.

Don't get me started on Dreamweaver. It produces lousy code. For a start, it has "trendy" lower case tags. Caps are there for a reason

Capitals are not there for a reason, and they go against the xhtml1.0 standard. Use uppercase tags and you are breaking the standards that so many people on slashdot want you to adhere to.

1. 
   
   always the first place one should start
   
   Samples#1
   
   samples#2
   
   examples#3 (part of a SVG webring)
   
   examples#4 (it also answers the question. Who uses this?)
   
   ditto#2
   
   Adobe plugin (shoots down the "hasn't been updated in years" argument)
   
   Too imature for you?
   
   Oh yeah! Immature, and it has a browser plugin too