Slashdot Mirror

For those with limited vision (or blindness), screen readers can (and usually do) use metatags to aid in navigation and content descriptions.

For anyone who's interested, check out the W3C site on Web Accessibility Guidelines at:

W3C Web Accessbility Guidelines

Here

Does anyone (except porn sites) actually use them anymore ?

Does anyone (except porn sites) actually use them anymore ?

yes
The Guy that invented the internet

We need a mozilla-esque frontpage replacement.

What, like Amaya?

"HTML is about the display of content, XML is about creating, sharing and processing information."

Would you like to know more?

I just mirrored a snapshot of the slashdot frontpage, and ran it through the w3c validator with interesting results.

To reiterate, bad slashdot!

Try finding anything in any RFC declaring or describing the term "Deep Link"!

and
. It's not a replacement for DHTML menus (boo! hiss!) or anything like that; effects like that would still be handled via (ECMA|Java)script or CSS.

For another, backwards compability has not been "dropped" in the sense that it's gone completely, total split with the past, et cetera. It's just no longer a priority. You can likely expect <br> and maybe the <hN> elements to dissapear entirely as things evolve (many are in favor of that last; many aren't) in addition to those that have already gone byebye. There's also debate about the sematic value of <strong> and either <abbr> or <acronym> (I can never remember which one folks want to get rid of) and whether or not they should stay.

There's also quite a bit of talk about how to handle titles for other elements. Some folks question why <name> is being used instead of <h> in the new navigation lists, for example.

And they're right about XLink, by the way. There's a new reccomendation being put together to try to address these issues, called HLink. You can find it at http://www.w3.org/TR/hlink/.

And just so I can put out these totally unsolicited opinion: XFrames absolutely rocks. Love it. Nurture it. And I've been waiting way too long for <img> to die; now let's just all hope that Microsoft fixes up all of their horrifyingly large bugs with <object> in time for this... :)

(Ah, one more note. Slashcode doesn't appear to allow the <code> element in comments. Indeed, the only semantic markup allowed in /. comments is <a>, <p>, <blockquote>, <em> and <strong> (and like I said earlier, that last is being challenged). This is, quite frankly, really, REALLY sad. Why hasn't /. gotten rid of all their legacy crap yet?)

The other very important problem of LDAP is that it's for hierarchies/ However, the real world information in the best case of scenaria is DAG.

Besides, LDAP is way too slow and its query language is way too primitive.

I believe that another database paradigm should be used to roam user's personal information. And I am more convienced that RDF is a solution when non-tree info doesn't go to "raw" XML, neither to LDAP.

I agree that Jabber is a good idea to start. What's good in Jabber? SOAP. That's it. Well, today XML is a key. As I mentioned, PIM requires not a "raw" XML - but rather its RDF dialect. Perhaps some RDF database with RDF-oriented query language and web/SOAP interfaces will serve well if user profile info is defined well in RDF ontologies.

Here are some links I found about RDF:

• rdfDB : An RDF Database
• Redland RDF Database Demo
• Redfoot is an extensible RDF server written in Python for building a Semantic Web of P2P nodes.
• RDF SQL HOWTO, a part of installing a W3C-Perllib Annotation server
• RDF Query Languages: A state-of-the-art
• RDF Query and Inference, a part of 4Suite Server
• RDF Query Specification (old)
• DAML: The DARPA Agent Markup Language (very related to RDF and Ontologies)
• you can also find lots of links to RDF wrapping of calendars, bookmarks and addressbooks.

The other very important problem of LDAP is that it's for hierarchies/ However, the real world information in the best case of scenaria is DAG.

Besides, LDAP is way too slow and its query language is way too primitive.

I believe that another database paradigm should be used to roam user's personal information. And I am more convienced that RDF is a solution when non-tree info doesn't go to "raw" XML, neither to LDAP.

I agree that Jabber is a good idea to start. What's good in Jabber? SOAP. That's it. Well, today XML is a key. As I mentioned, PIM requires not a "raw" XML - but rather its RDF dialect. Perhaps some RDF database with RDF-oriented query language and web/SOAP interfaces will serve well if user profile info is defined well in RDF ontologies.

Here are some links I found about RDF:

• rdfDB : An RDF Database
• Redland RDF Database Demo
• Redfoot is an extensible RDF server written in Python for building a Semantic Web of P2P nodes.
• RDF SQL HOWTO, a part of installing a W3C-Perllib Annotation server
• RDF Query Languages: A state-of-the-art
• RDF Query and Inference, a part of 4Suite Server
• RDF Query Specification (old)
• DAML: The DARPA Agent Markup Language (very related to RDF and Ontologies)
• you can also find lots of links to RDF wrapping of calendars, bookmarks and addressbooks.

Take a look. This is the first of open standards to control information about yourself.

The point of HTML preprocessors isn't to make it easier to write HTML, it's to make it easier (possible) to write dynamic HTML on the server end.

Not to mention, the use of mod_perl, PHP, and so on, is often not necessarily to preprocess HTML, but rather to generate it in the first place, sometimes from pieces.

Either way, maybe a new HTML would be nice. I guess we'll see.

--Dan

Okay, then let's try this one out for size.

Awk!!! Slashdot is evile!

try and have a look for yourself

linux.com validate

I mean if your going to run advert's about it being new and all at least you could update it to put a freaking charset in

regards

John Jones

I think DRM in free software is a good idea. For example, one might implement a header in OGG that said "no streaming allowed" because the Copyright holder does not want their song to be streamed w/o payment. If players respect this header, this benefits the author and the user (in my case, I tend to respect other people's property and pay up where payment is due). If users want to steal, they'll try (and probably succeed) to so do no matter what sort DRM is exposed.

Proprietary DRM often misleads Copyright holders into thinking that they can control their content on un-trusted computers, when what they really need is a standard, electronic way of expressing their permissions on software.

I'd expect that a Free Software DRM would be a bit more sophisticated then the above example. It would be cool if it implemented a standard document type (along the lines of P3P) with options to accommodate a variety of licenses; from GPL to donation-ware to media-type licenses to draconian licenses. There would be quite a lot of problems to solve (where to store the licensing data, an API to expose such a licensing interface, how to handle source redistribution etc.) Handling licensing exceptions would be another interesting issue, going back to the OGG example, if they copyright holder wanted to allow people to pay to get permission to stream w/o making the purchaser download a different version of the file or having to circumvent the protection. Any implementation would ultimately leave final word in the hands of the user (no number of permission bits will prevent someone from modifying the software (proprietary or not) or pointing a camera to the monitor.

Of course free DRM would preferably encourage people to use it for enforcing free-type licenses!

• Validate www.softwarechoice.org
• Validate sincerechoice.com

If you'd like to know more about how to use validators to make your websites interoperable, read my article Use Validators and Load Generators to Test Your Web Applications.

Thank you for your attention.

• Validate www.softwarechoice.org
• Validate sincerechoice.com

If you'd like to know more about how to use validators to make your websites interoperable, read my article Use Validators and Load Generators to Test Your Web Applications.

Thank you for your attention.

• Validate www.softwarechoice.org
• Validate sincerechoice.com

If you'd like to know more about how to use validators to make your websites interoperable, read my article Use Validators and Load Generators to Test Your Web Applications.

Thank you for your attention.

webcal links are not a feature, they are a bug to work around another bug.

webcal links are not a feature, they are a bug to work around another bug.

I've worked with JUnit and HTTPUnit and putting HTTPUnit tests that run over a wide variety of circumstances. Using HTTPUnit with JUnit makes for easy automation of testing (JUnit comes with an application that allows you to run the various test suites that you create--HTTPUnit is simply an extension of JUnit, so you can run HTTPUnit test suites in JUnit)

Of course, you still have to deal with browser issues. Just make sure those pages validate! (Not that it makes that much difference anyway.)

This may be a little off the mark, but no matter how you test the actual transaction processing PLEASE make sure the output conforms to W3C specifications. I'm on a big standards kick (have been a Mozilla User since it could be distributed on a floppy), and I have seen too many dynamic web apps which totally break HTML and XHTML rules. One site I visit regularly actually declares itself to be written in XHTML STRICT 1.0 in the DOCTYPE when it is clearly not (looks more like HTML 4.01, but broken).

Yeah, I know "Web Standards" are like "Nobel Laurate-Supermodels". Still, I dream of a better tomorrow where I can use a standards-compliant browser without pages breaking, and have my cancer cured by someone who invented instantaneous travel while looking FAAAAABULOUS.

Check out the W3C HTML Validation Service to test your code for standards compliance. I love seeing those little "W3C: HTML 4.01" images all over the place!

</ENDRANT>

This is a subject that I am very interested in.
As a testing team lead for Web applications, I often have the debate as to why we don't automate more of our testing.
Automated testing is good for Regression testing ONLY!
Once your site is stable enough to use automated testing tool, you don't have to worry about it because you are out of a job.
While you are developing the site you should use validation tools.
There are many that are readily available, such as: Bobby for accessability testing; W3C for validation of HTML, CSS, XML...; Coast for link checking; Webglimpse for change control.
Log in to a site such QAForums for various opinion and reccomendations.
Do not rely on automation totally. Only a human with all their failings and experiences will be able to do what no automated tool can, the "stupid user stuff".

I'm the only one on the design team that works almost exclusively in CSS. The current design on the site wasn't made by me, the old one wasn't either.

Then I would suggest that it was a pretty poor example to use, or rely upon, to demonstrate a real-world challenge to Zeldman's case.

You can get a better idea of my CSS style by going to a css layout version of our current design or my not close to being done SVG site. Which has a very clean body.

It's unfortunate that the layout version isn't close to valid HTML or that the CSS isn't much better. The markup for the SVG site is a bit better, though the validator doesn't catch the odd inclusion of XHTML style BR elements in a document clearly marked as HTML 4.01 Transitional. I'll leave a check of its CSS to you, I'm getting timeouts on multiple requests to your server. You may want to investigate its cache status, too. But I assume both are incomplete projects, and everyone makes mistakes (though why they would post them to /. is beyond me).

The change was to pretty basic CSS and worked fine in all browsers. Although it still wasn't *exactly* what the old version looked like (text a couple points off here and there).

I suspect that the search for pixel- and proportion-perfect design is a root issue. Thinking in those terms when implementing on the Web is troubling and could even be labeled by some as naive or impossible beyond the narrowest of visitor communities. I begin to understand the excessive use of DIV elements in your markup.

[A]s I pointed out 3-4% is only 40megs. We pay $10 for 10 gigs of transfer and the account on the machine. So 40 megs is less than 5 cents. Hardly anything compared to the 400% difference of having gzip turned off.

Bandwidth is a resource, and like any resouce, it ought to be conserved where possible. Read my original post where I anticipate (and do not contest) a return to the issue of transfer compression. You don't have sufficient traffic to worry about cutting even small chunks from your costs, fine. Don't indict the practice for everyone else then ("I can assure you [bandwidth savings] are negligible.") or just send me the five cents you will sav every day, I'll put it to good use. :p

The point is this: you still seem to be glossing over my earlier observation that your ~4% savings could have been even greater had you actually understood the holistic approach Zeldman offers. It troubles me to think that you still don't "get it", even though you offer a couple new example sites that would seem to suggest that you do, in part.

If I were on dial-up (which thankfully, I'm not at the moment), I would certainly be appreciative as a user for the additional savings in time and bytes. Yes, there are still people on metered plans out there in the world. How much bandwidth a document or a site needs is not only a cost for the supplier, but also for the consumer, in money and time.

No one is contesting the utility of transfer compression. Stop complaining about the lack of gzip encoding, switch to a better host if it bothers you so much. [It's odd, your servers identify as "Apache/1.3.26 (Unix) PHP/4.2.2 mod_gzip/1.3.19.1a" -- mod_gzip is there but your host isn't permitting usage?]

Feel free to email me at monkeyman at oswd.org if you want to discuss it more.

Look, it may seem like I'm coming down on you like a ton of bricks. That's because I am.

It frustrates me to encounter Slashbots who insist on posting with the +1 bonus (even deep in a now off-topic thread), forcing an escalation to my own bonus. It frustrates me to read about how everyone should be beholden to one person's experience, when that person argues in the same thread that individual experiences don't matter much in the face of aggregate counts. And when that person needlessly crows about search engine placement. And especially when he attempts to push a public discussion off to email when someone takes the time to respond in kind.

Best of luck in your quest to regain mod_gzip.

I'm the only one on the design team that works almost exclusively in CSS. The current design on the site wasn't made by me, the old one wasn't either.

Then I would suggest that it was a pretty poor example to use, or rely upon, to demonstrate a real-world challenge to Zeldman's case.

You can get a better idea of my CSS style by going to a css layout version of our current design or my not close to being done SVG site. Which has a very clean body.

It's unfortunate that the layout version isn't close to valid HTML or that the CSS isn't much better. The markup for the SVG site is a bit better, though the validator doesn't catch the odd inclusion of XHTML style BR elements in a document clearly marked as HTML 4.01 Transitional. I'll leave a check of its CSS to you, I'm getting timeouts on multiple requests to your server. You may want to investigate its cache status, too. But I assume both are incomplete projects, and everyone makes mistakes (though why they would post them to /. is beyond me).

The change was to pretty basic CSS and worked fine in all browsers. Although it still wasn't *exactly* what the old version looked like (text a couple points off here and there).

I suspect that the search for pixel- and proportion-perfect design is a root issue. Thinking in those terms when implementing on the Web is troubling and could even be labeled by some as naive or impossible beyond the narrowest of visitor communities. I begin to understand the excessive use of DIV elements in your markup.

[A]s I pointed out 3-4% is only 40megs. We pay $10 for 10 gigs of transfer and the account on the machine. So 40 megs is less than 5 cents. Hardly anything compared to the 400% difference of having gzip turned off.

Bandwidth is a resource, and like any resouce, it ought to be conserved where possible. Read my original post where I anticipate (and do not contest) a return to the issue of transfer compression. You don't have sufficient traffic to worry about cutting even small chunks from your costs, fine. Don't indict the practice for everyone else then ("I can assure you [bandwidth savings] are negligible.") or just send me the five cents you will sav every day, I'll put it to good use. :p

The point is this: you still seem to be glossing over my earlier observation that your ~4% savings could have been even greater had you actually understood the holistic approach Zeldman offers. It troubles me to think that you still don't "get it", even though you offer a couple new example sites that would seem to suggest that you do, in part.

If I were on dial-up (which thankfully, I'm not at the moment), I would certainly be appreciative as a user for the additional savings in time and bytes. Yes, there are still people on metered plans out there in the world. How much bandwidth a document or a site needs is not only a cost for the supplier, but also for the consumer, in money and time.

No one is contesting the utility of transfer compression. Stop complaining about the lack of gzip encoding, switch to a better host if it bothers you so much. [It's odd, your servers identify as "Apache/1.3.26 (Unix) PHP/4.2.2 mod_gzip/1.3.19.1a" -- mod_gzip is there but your host isn't permitting usage?]

Feel free to email me at monkeyman at oswd.org if you want to discuss it more.

Look, it may seem like I'm coming down on you like a ton of bricks. That's because I am.

It frustrates me to encounter Slashbots who insist on posting with the +1 bonus (even deep in a now off-topic thread), forcing an escalation to my own bonus. It frustrates me to read about how everyone should be beholden to one person's experience, when that person argues in the same thread that individual experiences don't matter much in the face of aggregate counts. And when that person needlessly crows about search engine placement. And especially when he attempts to push a public discussion off to email when someone takes the time to respond in kind.

Best of luck in your quest to regain mod_gzip.

I'm the only one on the design team that works almost exclusively in CSS. The current design on the site wasn't made by me, the old one wasn't either.

Then I would suggest that it was a pretty poor example to use, or rely upon, to demonstrate a real-world challenge to Zeldman's case.

You can get a better idea of my CSS style by going to a css layout version of our current design or my not close to being done SVG site. Which has a very clean body.

It's unfortunate that the layout version isn't close to valid HTML or that the CSS isn't much better. The markup for the SVG site is a bit better, though the validator doesn't catch the odd inclusion of XHTML style BR elements in a document clearly marked as HTML 4.01 Transitional. I'll leave a check of its CSS to you, I'm getting timeouts on multiple requests to your server. You may want to investigate its cache status, too. But I assume both are incomplete projects, and everyone makes mistakes (though why they would post them to /. is beyond me).

The change was to pretty basic CSS and worked fine in all browsers. Although it still wasn't *exactly* what the old version looked like (text a couple points off here and there).

I suspect that the search for pixel- and proportion-perfect design is a root issue. Thinking in those terms when implementing on the Web is troubling and could even be labeled by some as naive or impossible beyond the narrowest of visitor communities. I begin to understand the excessive use of DIV elements in your markup.

[A]s I pointed out 3-4% is only 40megs. We pay $10 for 10 gigs of transfer and the account on the machine. So 40 megs is less than 5 cents. Hardly anything compared to the 400% difference of having gzip turned off.

Bandwidth is a resource, and like any resouce, it ought to be conserved where possible. Read my original post where I anticipate (and do not contest) a return to the issue of transfer compression. You don't have sufficient traffic to worry about cutting even small chunks from your costs, fine. Don't indict the practice for everyone else then ("I can assure you [bandwidth savings] are negligible.") or just send me the five cents you will sav every day, I'll put it to good use. :p

The point is this: you still seem to be glossing over my earlier observation that your ~4% savings could have been even greater had you actually understood the holistic approach Zeldman offers. It troubles me to think that you still don't "get it", even though you offer a couple new example sites that would seem to suggest that you do, in part.

If I were on dial-up (which thankfully, I'm not at the moment), I would certainly be appreciative as a user for the additional savings in time and bytes. Yes, there are still people on metered plans out there in the world. How much bandwidth a document or a site needs is not only a cost for the supplier, but also for the consumer, in money and time.

No one is contesting the utility of transfer compression. Stop complaining about the lack of gzip encoding, switch to a better host if it bothers you so much. [It's odd, your servers identify as "Apache/1.3.26 (Unix) PHP/4.2.2 mod_gzip/1.3.19.1a" -- mod_gzip is there but your host isn't permitting usage?]

Feel free to email me at monkeyman at oswd.org if you want to discuss it more.

Look, it may seem like I'm coming down on you like a ton of bricks. That's because I am.

It frustrates me to encounter Slashbots who insist on posting with the +1 bonus (even deep in a now off-topic thread), forcing an escalation to my own bonus. It frustrates me to read about how everyone should be beholden to one person's experience, when that person argues in the same thread that individual experiences don't matter much in the face of aggregate counts. And when that person needlessly crows about search engine placement. And especially when he attempts to push a public discussion off to email when someone takes the time to respond in kind.

Best of luck in your quest to regain mod_gzip.

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

Secondly, part of the point of XHTML is to keep backwards compatibility. So the ?xml declaration is kept as option since it does break certain browsers. However you're keeping the rest of the document compliant with XML. It would be trivial, if working with an XHTML document outside of an HTTP agent, to prepend the proper ?xml declaration or build it right into the application. In fact that's what most user-agents already do!

So stick with XHTML.

The websites I design contain links to the W3C HTML and CSS validators. The links might look something like this

XHTML 1.0 CSS

and I put them in the site template, so they appear on every page. These are referer links, which mean that they check the page you are linking from. When I finish making changes to a page, I click those links in sequence, and if my page doesn't pass, I fix the XHTML or CSS that's causing the problem.

Depending on the type of page, I might make them bold and obvious, with the checkmark graphics that W3C offers, or I might hook them to a bullet or a period so they're obscure and don't become a design element.

I use absolute positioning to do layout that people often do with tables, and my sites look fine in anything from IE to lynx to Mozilla.

Ellen

The websites I design contain links to the W3C HTML and CSS validators. The links might look something like this

XHTML 1.0 CSS

and I put them in the site template, so they appear on every page. These are referer links, which mean that they check the page you are linking from. When I finish making changes to a page, I click those links in sequence, and if my page doesn't pass, I fix the XHTML or CSS that's causing the problem.

Depending on the type of page, I might make them bold and obvious, with the checkmark graphics that W3C offers, or I might hook them to a bullet or a period so they're obscure and don't become a design element.

I use absolute positioning to do layout that people often do with tables, and my sites look fine in anything from IE to lynx to Mozilla.

Ellen

I'd say using the W3C's Specification for HTML would be the best way to solve sloppiness problems. They state exactly and in very clear phrasing what is required and what is not for a tag to work and what is to be expected of client agents (browsers). All my beginning HTML/CSS work has been done via that page. No stupid tutorials that some other guy who wasn't a part of the consortium wrote, because he probably has bad habits, just as all of us do.
That said, I like programming Perl using the Texinfo page, Windows coding with the API Docs right next to me, and so on. Basically, information that's unadulterated is the best, in my eyes, for writing efficient/correct code. I read a book a while back called LaFores Windows Programming Made Easy. It had many good examples, but as I learned more about how to code for windows, I realized that many of the examples in the book were "dumbed down" significantly, and they had left out many things that are essential to writing effective and efficient code for windows.
Shortcuts usually end up being long-cuts. Like the Simpson's quote while heading for Itchy and Scratchy Land: "Let's never speak of the short-cut again...". I feel similarly, that short-cuts will, in time, become festering problems.

They're called standards for a reason.
Well, no, they're not called standards, and for a reason. From the w3c home page:

The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential.

No mention of standards.

Take a look at the HTML specification page:

W3C produces what are known as "Recommendations". These are specifications, developed by W3C working groups, and then reviewed by Members of the Consortium. A W3C Recommendation indicates that consensus has been reached among the Consortium Members that a specification is appropriate for widespread use.

Again, no mention of standards.

The W3C is a vendor consortium, primarily a group of big players who are trying to reduce their cost of busness by hammering out some common formats. The W3C is not a standards body, and they do not produce standards. While there are smart, possibly altuistic people on W3C working groups, by and large the W3C as a whole is intersted in promoting the welfare of its member companies, not that of the general developer community. Typically, though, these interests overlap, but that doesn;t change the purpose of the W3C.

Netscape 4.7 does not require quotes around 'field' tags like width or height.
Netscape 6.0 can do unusual things if they are not there.

Well, HTML doesn't require the quotes around simple attribute values, so if what you're describing is true then Netscape 6.0 is broken. On the other hand, XHTML does require the quotes.

I am inclined, however, to believe that you may have other problems with your HTML, and the problem you're describing doesn't isn't the real problem you're encountering. Use a validator before making a bug report.

I run a fairly sucessful website.
Like many businesses money is tight so guess where I'm goign to spend it when it comes to testing, certainly not on Sparc/Solaris9 combination.

So far from 350,000 hits this month I've had the following Browsers :

MS Internet Explorer (Versions) 94.9 %
(MSIE/3.xx 0 % MSIE/4.xx 1.9 % MSIE/5.xx 56.6 % MSIE/6.xx 41.3%)
Netscape (Versions)No 2.7 %
(Mozilla/3.xx 1.1 % Mozilla/4.xx 55 % Mozilla/5.xx 43.7 %)
Unknown 1.9 %
Opera 0.3 %
Konqueror 0 %
ANT Fresco 0 %
iCab 0 %
WebCollage (PDA/Phone browser) 0 %
LibWWW 0 %
Microsoft Mobile Explorer (PDA/Phone browser) 0 %
Lynx 0%

Using the following OSs

Windows 37.4 %
Windows 2000 17.3 %
Windows XP 17.1 %
Windows Me 10.9 %
Windows 9.4 %
Windows 4.9 %
Mac OS 1.2 %
Unknown 1.1 %
Linux 0.2 %
Sun Solaris 0.1 %
HP Unix 0 %
Warp OS/2 0 %
Windows 3.xx 0 %
OSF Unix 0 %
Irix 0%
RISC_OS_4.03 0%

Thats at least 15 browers on 17 OSs.

How am I supposed to test my pages for all those expectations?

My HTML passes 4.01 Validation but I can't be sure it displays on those browsers.

I know it displays in Lynx okay so that's about the best I can offer.

I've had one email in the past year saying 'your site doesn't display properly' and that was IE on NT4. A product I can't buy and test with even if I wanted to. (except through warez of course). HP Unix presents a better challenge.

What would you suggest is my *obvious* solution?

From his perspective, the software companies should make sure that their software does not make unnecessary deviations from standard, thus breaking older sites. You think that the designers should predict change and design their sites to take this into account.

I do not think designers should predict change. I think designers should simply use recent standards and ensure that they adhere to these standards by using validators such as the W3C HTML validator. Absolutely no predicition is necessary!

Please re-read the article, as it is very clear on these points.

Last time I checked lynx wasn't going to show images anytime soon

Lynx handles images by using an external program - essentially like a plugin. Plus, for maximum accessibility you should be providing textual alternatives to rich media types anyway - thats a priority 1 checkpoint of WCAG.

So lets all just use HTML 0.1 with only <br> tags and <a> tags. Whine whine whine...!

No. Well structured HTML (as in _this_ is a heading, _this_ is a paragraph, _this_ is a quote), and using CSS to style the presentation (whatever the output destination: screen, printer, aural devices, holograms).

The article just points out that many web sites have mark-up errors in them. Big deal. To go from that to saying that 99.9% of sites are obsolete is just dumb.

What percentage of websites pass cleanly through an html validator such as W3? Surely those sites that do not validate are because there are errors in the HTML markup?

Zeldman probably believes that 0.01% of sites validate correctly, so his figure of 99.9% obsolete isn't mathematically that far off.

99.9% of web sites are obslete, and every computer for sale is obsolete by the time it hits the store.

What's the difference?

Everyone who I have ever worked with has generated invalid HTML that has made even current browsers crash or behave erratically in different browsers. When I realized that I was also making these mistakes, I finally learned my lesson and started using the W3C validator to make sure my web pages are valid HTML. Since then, I have not had any problem with my pages not working in any browser. This is exactly what Zeldman is asking web developers to do.

I want to do a nice little page, and do it in XHTML because it's The Way Of The Future (or I want to display a little math, which only XHTML+MathML allows without resorting to ugly inline images). The tag soup itself isn't a problem, I just close all my tags and make sure the doctype declaration says XHTML instead of HTML, as prescribed by the standard.

However, is this enough? The document is now XML, and therefore should have a <?xml declaration, if only to specify its encoding. Except that said XHTML standard says it is optional if the encoding is UTF-8 or UTF-16, or has been otherwise determined (think HTTP headers), which contradicts the XML standard, sec. 4.3.3, the last two paragraphs, one which says that no declaration and no other information means mandatory UTF-8, and the next one "It is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16."

So I need a declaration no matter what. But according to this page about the different layout modes in current browsers, MSIE will react to an XML declaration by switching to "quirks" mode, which is precisely what I wants to avoid by sticking to the standards... And I wouldn't want to lock out 85% of WWW users, wouldn't I?

But wait, this is only if the page was served with a text/html content-type. The right answer would then be to use the standard content-type for XML/XHTML... which should be application/xhtml+xml! Yes, "application"! Now if I use that content-type, all browsers I have at my disposal except Mozilla (MSIE5, Konqueror, Links, Lynx...) either consider the page an application and offer to save it to disk, or display it as-is! Same with the second-best, text/xml.

Okay, am I the only one experiencing this? Any point in not using good-ol' HTML4 and avoid doing (yet another kind of) horrible bugware?

I want to do a nice little page, and do it in XHTML because it's The Way Of The Future (or I want to display a little math, which only XHTML+MathML allows without resorting to ugly inline images). The tag soup itself isn't a problem, I just close all my tags and make sure the doctype declaration says XHTML instead of HTML, as prescribed by the standard.

However, is this enough? The document is now XML, and therefore should have a <?xml declaration, if only to specify its encoding. Except that said XHTML standard says it is optional if the encoding is UTF-8 or UTF-16, or has been otherwise determined (think HTTP headers), which contradicts the XML standard, sec. 4.3.3, the last two paragraphs, one which says that no declaration and no other information means mandatory UTF-8, and the next one "It is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16."

So I need a declaration no matter what. But according to this page about the different layout modes in current browsers, MSIE will react to an XML declaration by switching to "quirks" mode, which is precisely what I wants to avoid by sticking to the standards... And I wouldn't want to lock out 85% of WWW users, wouldn't I?

But wait, this is only if the page was served with a text/html content-type. The right answer would then be to use the standard content-type for XML/XHTML... which should be application/xhtml+xml! Yes, "application"! Now if I use that content-type, all browsers I have at my disposal except Mozilla (MSIE5, Konqueror, Links, Lynx...) either consider the page an application and offer to save it to disk, or display it as-is! Same with the second-best, text/xml.

Okay, am I the only one experiencing this? Any point in not using good-ol' HTML4 and avoid doing (yet another kind of) horrible bugware?

I want to do a nice little page, and do it in XHTML because it's The Way Of The Future (or I want to display a little math, which only XHTML+MathML allows without resorting to ugly inline images). The tag soup itself isn't a problem, I just close all my tags and make sure the doctype declaration says XHTML instead of HTML, as prescribed by the standard.

However, is this enough? The document is now XML, and therefore should have a <?xml declaration, if only to specify its encoding. Except that said XHTML standard says it is optional if the encoding is UTF-8 or UTF-16, or has been otherwise determined (think HTTP headers), which contradicts the XML standard, sec. 4.3.3, the last two paragraphs, one which says that no declaration and no other information means mandatory UTF-8, and the next one "It is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16."

So I need a declaration no matter what. But according to this page about the different layout modes in current browsers, MSIE will react to an XML declaration by switching to "quirks" mode, which is precisely what I wants to avoid by sticking to the standards... And I wouldn't want to lock out 85% of WWW users, wouldn't I?

But wait, this is only if the page was served with a text/html content-type. The right answer would then be to use the standard content-type for XML/XHTML... which should be application/xhtml+xml! Yes, "application"! Now if I use that content-type, all browsers I have at my disposal except Mozilla (MSIE5, Konqueror, Links, Lynx...) either consider the page an application and offer to save it to disk, or display it as-is! Same with the second-best, text/xml.

Okay, am I the only one experiencing this? Any point in not using good-ol' HTML4 and avoid doing (yet another kind of) horrible bugware?

You know, adding a DTD, defining character encoding and validating your HTML would probably help quite a bit.

They're called standards for a reason.

.02

cLive ;-)

It seems so altough w3 offer a validator for free.

Maybe learning html in a weekend or in faster don't help keeping the quality of code at high level ; )

It seems so altough w3 offer a validator for free.

Maybe learning html in a weekend or in faster don't help keeping the quality of code at high level ; )

Mozilla still doesn't seem to have the incremental layout capabilities of Netscape 0.9

"incremental layout" depends a lot on the HTML complexity and the HTML author. you need to define the sizes of layout objects before you can lay out things past them. the IMG WIDTH and HEIGHT tags introduced by netscape helped this a lot, where you can say "hey, I'm blocked on getting this image, but I know what size it will be, so let me render the stuff after it and I'll worry about putting the image in later". Tables and CSS add to the complexity of determining sizes. You never really know the size of a table until after you read the trailing TABLE tag and you may even need to know the sizes of multiple elements inside the table until you load them, so you essentially have to grabthe whole table before you can show anything inside. The state of HTML at the time of Netscape .9 was nothing like it is now, probably at least an order of magnitude simpler. Compare the First early specs of HTML with HTML 4 and that doesn't even include CSS. HTML 2 (which your comparison browser couldn't even render because it was too complex) is a 77 page spec, HTML 4.0 (linked above) is close to 286 pages.

making as many connections as you wanted (later capped at 20)
It still does this, defaulted at 4. You can change this in user.js, it's just not a pref you can see in the UI anymore because folks abused it too much, and there definitely is a diminishing returns thing, and mostly - you just don't need to change it. HTTP 1.1 also lessens the need for this, drastically reducing the overhead for small objects, where socket start and teardown time is a much more significant part of the overall time.

These days the thing will freeze as it loads some plugin or other, maybe this is somehow harder than images
This is harder, and the memory requirements are huge. You're loadoing a bunch of new code, having to dynamically link stuff all over the palce, establish communication links, allocate memory, a nuch of stuff. The image library is already loaded, and showing an image takes a lot less memory than say, showing a 10 meg shockwave game.

It's hard to make comparisons now, since our browsers are required to do so much more. I tried to look at some old browsers just for the hell of it, and I couldn't even get NCSA Mosaic to run, just blew up on me.

Mozilla still doesn't seem to have the incremental layout capabilities of Netscape 0.9

"incremental layout" depends a lot on the HTML complexity and the HTML author. you need to define the sizes of layout objects before you can lay out things past them. the IMG WIDTH and HEIGHT tags introduced by netscape helped this a lot, where you can say "hey, I'm blocked on getting this image, but I know what size it will be, so let me render the stuff after it and I'll worry about putting the image in later". Tables and CSS add to the complexity of determining sizes. You never really know the size of a table until after you read the trailing TABLE tag and you may even need to know the sizes of multiple elements inside the table until you load them, so you essentially have to grabthe whole table before you can show anything inside. The state of HTML at the time of Netscape .9 was nothing like it is now, probably at least an order of magnitude simpler. Compare the First early specs of HTML with HTML 4 and that doesn't even include CSS. HTML 2 (which your comparison browser couldn't even render because it was too complex) is a 77 page spec, HTML 4.0 (linked above) is close to 286 pages.

making as many connections as you wanted (later capped at 20)
It still does this, defaulted at 4. You can change this in user.js, it's just not a pref you can see in the UI anymore because folks abused it too much, and there definitely is a diminishing returns thing, and mostly - you just don't need to change it. HTTP 1.1 also lessens the need for this, drastically reducing the overhead for small objects, where socket start and teardown time is a much more significant part of the overall time.

These days the thing will freeze as it loads some plugin or other, maybe this is somehow harder than images
This is harder, and the memory requirements are huge. You're loadoing a bunch of new code, having to dynamically link stuff all over the palce, establish communication links, allocate memory, a nuch of stuff. The image library is already loaded, and showing an image takes a lot less memory than say, showing a 10 meg shockwave game.

It's hard to make comparisons now, since our browsers are required to do so much more. I tried to look at some old browsers just for the hell of it, and I couldn't even get NCSA Mosaic to run, just blew up on me.

the vertical scroll bar even appears on the left side of my window in IE.

IE switches the scroll bar to the left when the direction attribute on the body element is set to right-to-left:

More information about right-to-left languages and HTML can be found in the specification.

Close, but no cigar!

well, at least m$'s website has less errors than kernel.org