Slashdot Mirror

The w3 has been talking about this for years. The Web Accessibility Initiative is their site dedicated to exactly this issue, and is rich in information and resources for implementation. See particularly the guidelines, checklists, and techniques sections.

You do have a lot of work ahead of you. It's much easier to start with accesibility in mind than to retro-fit everything. You might be able to script some of it, as others are suggesting, but your first step should be to thorougly familiarize yourself with the information at the WAI.

TomatoMan

I suppose the old HTML of the early 90's could have been used, but HTML 4 is for people with eyes.

You apparently don't know what HTML 4 is. HTML 4 Transitional and HTML 4 Frameset may cater to people with working eyes, but HTML 4 Strict does not.

I use HTML 4 Strict on all new pages that I write, and eyes are not required.

Web sites don't rely on one sense over another unless they've been written poorly. A well-written Web site will adapt seamlessly to any display device, whether it's your 21" monitor, your PalmPilot, or your speech browser.

Of course most Web sites are written poorly, so now you have to fix the mess. Good luck.

Have a look at the W3C's Web Accessibility Initiative for some guidelines and techniques.

Web sites don't rely on one sense over another unless they've been written poorly. A well-written Web site will adapt seamlessly to any display device, whether it's your 21" monitor, your PalmPilot, or your speech browser.

Of course most Web sites are written poorly, so now you have to fix the mess. Good luck.

Have a look at the W3C's Web Accessibility Initiative for some guidelines and techniques.

http://validator.w3.org/check?uri=http://validator .w3.org/check?uri=http://validator.w3.org/check?ur i=http://validator.w3.org/check?uri=http://validat or.w3.org/check?uri=www.slashdot.org

Wow, it works! ;)

--

hahahahahahahahahahahahaha....

slashdot

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!!!!!! !!!!!

slashdot just keeps getting blacker and blacker and... ps i promise it isn't goatse.cx or what ever that god awful site is...

HTTP 1.1 already has transfer encoding as an optional parameter that can be negotiated between the client and server. I'll bet we can all guess which side of the communication is lacking support for it.

Which specs are those? Can you point to an official reference?

http://www.w3.org/TR/REC-html32#table

Is that "official" enough, moron?

Michael

Some people write pages that stick to the HTML standards, though for the most part they are simpler in design because that's the easiest way to stick to the standard. But quite frankly, it's also usually (not always) less interesting.

The browsers will still render the same page differently because that's what the standard allowed them to do - it didn't dictate the exact appearance and left it to the browser implementors.

Besides, they create the Amaya browser, which is supposed to render correctly, and you will see it looks pretty different from everyone else's browser. Maybe we should all just use Amaya?

"This user violated our Acceptable Use Policy and has had their account terminated. The page you are looking for is gone for good."

In that case, the proper status code would probably be 410 Gone

This would be a biting and insightful comment if Internet Explorer didn't have the most comprehensive support for W3C standards of any browser in existence.

What do you think point 3.2 is referring to? As far as I know, IE is the only browser that departs from the HTTP standard by ignoring text/plain as a content type. I don't consider a browser that thinks "Sure, the server says it's text/plain, but I know better" to have "comprehensive support for W3C standards".

switch abck to Linux.
Localization in Linux is improving, but how close is total Linux support for languages like Japanese and Hebrew that are difficult to fit into your normal, left-to-right, single byte character infrastructure?

So why the Linux adjenda? The origianl author went out of his/her way to NOT mention Linux.

FreeBSD's ports collection supports 400+ Japanese localizations, 70+ Chinese, 20+ Russian, 9+ Vietamese, 2 French and 2 Hebrew. There is a reason for $10 million in investments from Japan in FreeBSD in the past few months. Combined with the 15-20% of the Open Source OS market FreeBSD has, FreeBSD is making fine progress in internationalization, thank you very much.

The people who *WRITE* code need to think a far bigger picture than the closed-world Linux only mind-think of Cliff and dvk. Show that you are a 'think big' kinda coder. Read up on unicode, usage of I18N/L18N or even the physically impaired. Such is not done by most code authors.

WinterKnight, the computer is a tool for communication. So you have a choice: Use the tools you have, *OR* (re)write tools to do what you want to do. Contact Mozilla, and see who has expressed an interest in making hooks for hebrew. Pick the tools you need, then make ports happen to unicode. And, try to get authors of code to design for Unicode/physically hampered and to write portable software. Having a 2nd machine and using VNC so you have one display, a switchbox to the 2nd machine (one display, one keyboard), or using a product like VMware and running Windows as a virtual machine are other options besides multiboot. These solutions avoid the time multibooting takes.

switch abck to Linux.
Localization in Linux is improving, but how close is total Linux support for languages like Japanese and Hebrew that are difficult to fit into your normal, left-to-right, single byte character infrastructure?

So why the Linux adjenda? The origianl author went out of his/her way to NOT mention Linux.

FreeBSD's ports collection supports 400+ Japanese localizations, 70+ Chinese, 20+ Russian, 9+ Vietamese, 2 French and 2 Hebrew. There is a reason for $10 million in investments from Japan in FreeBSD in the past few months. Combined with the 15-20% of the Open Source OS market FreeBSD has, FreeBSD is making fine progress in internationalization, thank you very much.

The people who *WRITE* code need to think a far bigger picture than the closed-world Linux only mind-think of Cliff and dvk. Show that you are a 'think big' kinda coder. Read up on unicode, usage of I18N/L18N or even the physically impaired. Such is not done by most code authors.

WinterKnight, the computer is a tool for communication. So you have a choice: Use the tools you have, *OR* (re)write tools to do what you want to do. Contact Mozilla, and see who has expressed an interest in making hooks for hebrew. Pick the tools you need, then make ports happen to unicode. And, try to get authors of code to design for Unicode/physically hampered and to write portable software. Having a 2nd machine and using VNC so you have one display, a switchbox to the 2nd machine (one display, one keyboard), or using a product like VMware and running Windows as a virtual machine are other options besides multiboot. These solutions avoid the time multibooting takes.

• 09 May 1997

.NET isn't just a response to Java. Think back to the findings of fact in the anti-trust trial. The thing that scares Microsoft even more than free software is "the middleware threat".

Microsoft's core asset is it's ubiquity, and any cross-platform middleware layer is a threat to that. They've been beating out brushfires on that front since at least "the browser wars" (Browser war is hell, by the way. Pray you never have to send your sons off to serve on the front lines. I lost my best buddy to a stray MIME type. One minute he was standing right next to me, the next minute all the helper apps in the world couldn't save him.)

MS has decided it can't afford to go after each new entrant into this territory, so it's going to have to colonise it. So we'll get a binary-only stripped-down windows emulator that runs on only those platforms MS feels it needs to support. My guess is this will be exactly the same platforms they've ported IE to, with promises to port to others once certain technical issues (related to the OS - FUD) have been addressed.

As for Microsoft's claims that .NET will be standards-based: anybody using ECMAScript? Isn't it great? Now nobody needs to be scared to use JavaScript anymore. Both Microsoft and Netscape worked on the spec, so obviously all browsers from them since have stuck to it, right? And doesn't CSS work like a dream in all the browsers that trumpet their support of this open standard? Microsoft (and Netscape, and Sun, and...) have been playing this game of "Kick the ball, Charlie Brown" with us for years. That's one reason why you should stick to free software.

MS can't leverage their monopoly if anybody can get their hands on the lever. If they are counting on the death of the desktop, and essentially giving their next platform away for free, you can be certain they've got a strategy for turning their dominance into a revenue stream. Whatever the strategy is, it's going to be bad news. Learn the lesson. Microsoft don't play nice, so don't play with them.

If Microsoft can deliver on a *cross-platform* solution.

.NET relies on standard Windows APIs. Only a "compact" version is designed to be portable.

If .NET handles the 30 odd languages they claim to support, with easy extendability for more.

See Microsoft's use of future tense and this list of JVM languages.

If they make .NET a standard, ... What motivation does MS have to lose control of their market? I don't have links readily available, but all I have heard is of MS planning to take the C# specification to ISO, which has nothing to do with standardizing their whole platform. Even if they did, any takers on rewriting Win32? Ask the WINE people how easy it is.

If they can make sure .NET really is vendor neutral, so shipping the .NET foundation is not like shipping the JVM which is little more than a commercial Sun product.

And .NET won't be a commercial MS product. I have not seen MS even try to claim that anything they produce for .NET won't be owned by them. Read carefully.

Then HECK YEAH, I'll take an open, free, extendible, cross-platform platform any day, especially if it ships with millions of Windows machines...

Aha. Windows machines. That's right. .NET is supported on Windows machines. It should make doing Windows network development nicer, with a compact version in various devices acting like embedded Java. MS supports Windows. They make Windows. What motive do they have for changing that? When did they say they were changing that?

I think from a technical perspective the .NET platform...

Try reading the technical documents. Here's one on SOAP. Read it. It's not that exciting. It specifies that you can use normal XML Schemas with a few extra rules and an envelope that mimics HTTP functionality.

You can do little new with SOAP and .NET from a non-Windows computer that you couldn't do with normal HTTP and CGI. SOAP provides almost nothing on top of standard XML. There's nothing new under the sun.

If you want open and exciting, try Linux or FreeBSD. If you want cross-platform software, try something open like C, Perl, Python, PHP, Ruby, or anything else on the list. They also interoperate just fine. Unix had cross-language interoperation working in the 70s. It's called pipes, and it's at least faster than SOAP.

- Tom

Form encoding is specified in the html specs. No where in the specs is this called CGI.

Granted, a stated policy can still be a bad policy.

OTOH, without a statement of the policy, then we have nothing. It's not enough, on a privacy issue, to simply live in a country where most sites are well behaved. It's not the multitude of good sites that are the problem, it's the minority of privacy abusers. Without stated policies, we can't detect these and avoid them.

Secondly, we need automatic policy publication through systems like P3P. Even that much isn't yet a solution, as we also need the next step; protocols like APPEL that allow us to express our own preferences for an acceptable policy. We're not even home yet, as we then need browsers to start supporting it. Actually we need IE, the mass-market choice, to do it so as to give a critical mass.

Privacy can be so much better than it is at present, and there are already demonstrations of these W3C-derived standards in action. They're a good fix ! Damn near complete user satisfaction, just by getting well-integrated browser negotiation of your preparedness to disclose.

Underlying it all though, is a stated policy on the site. Without that, you have nothing.

Granted, a stated policy can still be a bad policy.

OTOH, without a statement of the policy, then we have nothing. It's not enough, on a privacy issue, to simply live in a country where most sites are well behaved. It's not the multitude of good sites that are the problem, it's the minority of privacy abusers. Without stated policies, we can't detect these and avoid them.

Secondly, we need automatic policy publication through systems like P3P. Even that much isn't yet a solution, as we also need the next step; protocols like APPEL that allow us to express our own preferences for an acceptable policy. We're not even home yet, as we then need browsers to start supporting it. Actually we need IE, the mass-market choice, to do it so as to give a critical mass.

Privacy can be so much better than it is at present, and there are already demonstrations of these W3C-derived standards in action. They're a good fix ! Damn near complete user satisfaction, just by getting well-integrated browser negotiation of your preparedness to disclose.

Underlying it all though, is a stated policy on the site. Without that, you have nothing.

> ...if all sites could agree on a common (e.g. XML-based) content exchange format and conventions/protocols for agents to visit from remote sites and swap/glean content.

I think you need to learn about RDF, which is indeed XML based. Specifically the Netscape RDF format is already an established form of this.

So infrastructure isn't a problem, it's resources - to maintain, develop and host such a site - and this needs money. That will be your problem - you will have trouble finding money beause Open Source is based on giving things away. Perhaps you should start an Open Source charity. I'm sure if you went round the campus towns of America ratting a tin you'd get plenty of donations.

> ...if all sites could agree on a common (e.g. XML-based) content exchange format and conventions/protocols for agents to visit from remote sites and swap/glean content.

I think you need to learn about RDF, which is indeed XML based. Specifically the Netscape RDF format is already an established form of this.

So infrastructure isn't a problem, it's resources - to maintain, develop and host such a site - and this needs money. That will be your problem - you will have trouble finding money beause Open Source is based on giving things away. Perhaps you should start an Open Source charity. I'm sure if you went round the campus towns of America ratting a tin you'd get plenty of donations.

According to the W3C Validator even the ./ main page is full of HTML errors... If Taco can't/doesn't check his code why do you complain about other developers?

Fixes 90% of the stupid errors.

-- kwashiorkor --
Leaps in Logic
should not be confused with

Actually XSLT is a subset of XSL. XSLT deals with transformations of documents. XSL, while not a standard like XSLT, was designed to encompass ALL issues of style, not just transformation from one document type to another. You are right on the important part though. Microsoft is implementing XSLT. (I'm just being nitt-picky about the semantics, no offense :) Xaositec

Actually XSLT is a subset of XSL. XSLT deals with transformations of documents. XSL, while not a standard like XSLT, was designed to encompass ALL issues of style, not just transformation from one document type to another. You are right on the important part though. Microsoft is implementing XSLT. (I'm just being nitt-picky about the semantics, no offense :) Xaositec

Now you may not be aware of this, but in many countries, sites must be accessible.

• In the US, the Americans with Disabilities Act means that all federal services (and many state ones) must be accessible.
• In the UK, any site which offers a public service (nb this includes all online stores) must be accessible, thanks to the 1995 Disability Discrimination Act.
• In Australia, the Sydney Olympic Games Organising Committee were successfully sued for being inaccessible to the blind

With this going on, an IE-only web is going to get further away, not closer. The only way to be accessible is to ensure that basic HTML standards-compliant pages will allow users to access the basic functionality of their sites.

More info:

• Accessibility - more than the right thing to do
• Accessibility, the politics of design
• W3C's Web Accessibility Initiative
• Joe Clark (Web Accessibility advocate)'s blog
• UK government's position on web accessibility

...with some decent diagnostics (i.e. "'}' expected on line 554" or something like that)

Try the W3C's HTML Validator.

...some random user agent (read: browser) can handle bad code in any number of unexpected ways.

Right, and that's why it's really important that the code be valid. Otherwise, the results are, as they say, "undefined" -- you may very well end up shutting out all but a few browsers and never even know it (unless people send you death threats or something ^_^).

It's kinda nice to have a 'strict' browser around. I've seen a lot of web designers make bad errors that don't show up in IE (which is about the most permissive browser out there).

Permissive browsers are good for users, but really bad for designers.

Probably better to use the validator anyway though.

Big thing, though, is that Netscape (<= v4) isn't exactly strict ... it's just downright broken. I make a reasonable effort (write valid & strongly semantic markup, make some minor adjustments) so that broken browsers can at least display the content (regardless of how it looks), but at the end of the day if it's just simply a matter of browser bugs, screw that browser.

For my personal projects (where I just go for rigorous standards-compliance) this usually means:

• Mozilla - fine
• Mac IE 5 - fine
• Netscape 3 - fine, no CSS
• lynx - fine, no CSS
• Windows IE 5 - fine (minor layout issues, little CSS2)
• Opera - fine (minor layout/formatting issues, occasional weird CSS1/CSS2)
• Windows IE 4 - fine, everything's readable although e.g. "float" can occasionally be bizzare.
• Netscape 4 - you can read the page ... most of the time. always new "surprises"
• Mac IE 4 - parses HTML in a non-upwardly compatible (and incorrect) way, so XHTML displays as source. too bad.

Oh. HTML Tidy is nice for fixing HTML so you don't have to by hand.

...with some decent diagnostics (i.e. "'}' expected on line 554" or something like that)

Try the W3C's HTML Validator.

...some random user agent (read: browser) can handle bad code in any number of unexpected ways.

Right, and that's why it's really important that the code be valid. Otherwise, the results are, as they say, "undefined" -- you may very well end up shutting out all but a few browsers and never even know it (unless people send you death threats or something ^_^).

It's kinda nice to have a 'strict' browser around. I've seen a lot of web designers make bad errors that don't show up in IE (which is about the most permissive browser out there).

Permissive browsers are good for users, but really bad for designers.

Probably better to use the validator anyway though.

Big thing, though, is that Netscape (<= v4) isn't exactly strict ... it's just downright broken. I make a reasonable effort (write valid & strongly semantic markup, make some minor adjustments) so that broken browsers can at least display the content (regardless of how it looks), but at the end of the day if it's just simply a matter of browser bugs, screw that browser.

For my personal projects (where I just go for rigorous standards-compliance) this usually means:

• Mozilla - fine
• Mac IE 5 - fine
• Netscape 3 - fine, no CSS
• lynx - fine, no CSS
• Windows IE 5 - fine (minor layout issues, little CSS2)
• Opera - fine (minor layout/formatting issues, occasional weird CSS1/CSS2)
• Windows IE 4 - fine, everything's readable although e.g. "float" can occasionally be bizzare.
• Netscape 4 - you can read the page ... most of the time. always new "surprises"
• Mac IE 4 - parses HTML in a non-upwardly compatible (and incorrect) way, so XHTML displays as source. too bad.

Oh. HTML Tidy is nice for fixing HTML so you don't have to by hand.

no-one can afford to support every possible platform and configuration.

If you stick to the published specifications, you automatically support every conforming browser out there and it costs much less. This is obvious, really, to everyone except Web designers

Netscape (and Mozilla) are the most standards-compliant browsers out there.

Doesn't Amaya hold that crown?

the standards-compliant Web, as we know it, will die.

Last time I checked most sites (and browsers) do NOT comply to standards. ie. Slashdot

As far as I know the "Standards-Compliant Web" has never existed...

Though I agree that Javascript should be avoided and if scripting is really needed something defined in standard should be used. However, CSS should be used exclusively because when done right it allows page to render correctly in browsers which support CSS and it should be still highly readable in browsers that doesn't support it. Remember though that Netscape Navigator is broken enough to mess pages with CSS completely.

Why do I think CSS should be used? Because ppl want their web pages to look nice and the only other way to do it is to use tables. I hope you agree that tables aren't the right way to do this. I'm still formatting my pages with tables instead of CSS because I have to support NS4.x. If I needed to support only CSS compliant browsers there would be much less tables in my HTML source.

Saying that CSS is IE specific is like saying that TCP/IP is UNIX specific. In both cases it may be first platform to have support but in no way it's the only platform to support it.
_________________________

Though I agree that Javascript should be avoided and if scripting is really needed something defined in standard should be used. However, CSS should be used exclusively because when done right it allows page to render correctly in browsers which support CSS and it should be still highly readable in browsers that doesn't support it. Remember though that Netscape Navigator is broken enough to mess pages with CSS completely.

Why do I think CSS should be used? Because ppl want their web pages to look nice and the only other way to do it is to use tables. I hope you agree that tables aren't the right way to do this. I'm still formatting my pages with tables instead of CSS because I have to support NS4.x. If I needed to support only CSS compliant browsers there would be much less tables in my HTML source.

Saying that CSS is IE specific is like saying that TCP/IP is UNIX specific. In both cases it may be first platform to have support but in no way it's the only platform to support it.
_________________________

Another super-sweet feature: XPointer. What modern encyclopedia is going to be of any use if you can easily find related information?

Let's take a look at this page:

http://www.w3.org/Consortium/Prospectus/Joining

Hmm, looks like joining W3C costs 50 grand a year for a company, nearly ten times the amount proposed by this security group. Non-profit/educational access costs $5k annually, the same price as this security group. How come nobody accuses W3C of being an "information cartel"? Simple... it's not, and neither is this group. $5k per year is nothing for a company that is interested in security issues, even a small company.

I see your point, but semantics are never enforceable anyway.

Who cares ? If you're publishing the latest fat stock prices, then it's in the user's interests to get it right. Semantic publishing needs a reliable means of making them available to those who want them, it doesn't need to follow them up and enforce getting it right.

you haven't told me how RDF gets around this

Take a look at RDF Schema.

Of course, semantics aren't enough on their own. It's not too useful to know where the "creator" value is in two schemas, if you can't distinguish between one's "author" and the other's "translator". This is where an ontological understanding is needed, and there's a couple of projects out there working on that too; DAML & OIL.

For that purpose, I agree with a previous poster about packing 2 nucleotides per byte. It's an optimization that must be accepted as a standard before we can start doing on-demand heavy processing of genetic results.

There being four possible nucleotides (unless you're looking at something real exotic) surely you can get 4 per byte? Sticking to a base64 ascii encoding you can still get 3 nucleotides, so a single codon, per character, which is possibly a more elegant optimization.

Anyway, this shouldn't be necessary and goes against the XML philosophy. Although humans on the whole aren't meant to read XML directly, computers should be doing that, it should always remain *possibly* to do so, and I think this would muddy the human-eye view somewhat. It is accepted (by the people setting the standards) that this results in a larger raw stream, but that the correct way of dealing with that is to layer XML over storage-level and transport-level compression schemes to recover some of the entropy wastage. See REC-xml, section 1.1, and points 3 and 5 of XML in 10 points.

Heavy processing won't be done directly on markup - it'll be done on the in-memory representation after the markup is loaded, which can be assumed to be more compact than the markup if required (or less compact if there is a neat time/space tradeoff in the processing.)

For that purpose, I agree with a previous poster about packing 2 nucleotides per byte. It's an optimization that must be accepted as a standard before we can start doing on-demand heavy processing of genetic results.

There being four possible nucleotides (unless you're looking at something real exotic) surely you can get 4 per byte? Sticking to a base64 ascii encoding you can still get 3 nucleotides, so a single codon, per character, which is possibly a more elegant optimization.

Anyway, this shouldn't be necessary and goes against the XML philosophy. Although humans on the whole aren't meant to read XML directly, computers should be doing that, it should always remain *possibly* to do so, and I think this would muddy the human-eye view somewhat. It is accepted (by the people setting the standards) that this results in a larger raw stream, but that the correct way of dealing with that is to layer XML over storage-level and transport-level compression schemes to recover some of the entropy wastage. See REC-xml, section 1.1, and points 3 and 5 of XML in 10 points.

Heavy processing won't be done directly on markup - it'll be done on the in-memory representation after the markup is loaded, which can be assumed to be more compact than the markup if required (or less compact if there is a neat time/space tradeoff in the processing.)

Since a superior alien race would definately have an HTML complaint browser, their browser almost definately won't display the HTML with the extra character on the end. And ^M^J was the standard long before UNIX came around and shortened it to just ^J. (Originally, on teletypes, the ^M would slowly start the carriage back to the beginning, hence "carriage return" and the ^J would then move the paper up a line, hence "new line." This becomes pointless on these fancy monitor thingies, so most modern OSes use just one character.)

The standard proposes to do lots, including:

Facilitate conversion to and from other mathematical formats, both presentational and semantic. Output formats should include

• graphical displays
• speech synthesizers
• input for computer algebra systems other mathematics typesetting languages, such as TEX
• plain text displays, e.g. VT100 emulators
• print media, including braille

Anything which will allow input and output into Mathematica and TeX both (let alone the others) is going to not be something that you can not type directly by hand, so for this standard it would be unfair to expect that. Instead, it is important to make sure that the standard includes the important mathematical notions that will port from TeX and computer algebra systems. (to me, that means all of TeX and LaTeX except the page-layout specific features, and most of Mathematica, Maple, and Matlab...)

It may be that the standard is trying to do too much or that it would only be useful to the mathematical elite, but given the ambitious role it is clear that the standard will need to be complicated and presumably not suitable for unaided digestion or production.

See the standards page here, for the 12 line code for the expression for (a+b)^2.

I'm glad you read the spec before starting to rant. The language is trying to create mathematical prettiness *AND* content. It appears to me that if you restrict yourself solely to the content tags, you can safely ignore how notation is displayed on the page.

• Facilitate conversion to and from other mathematical formats, both presentational and semantic. Output formats should include... other mathematics typesetting languages, such as TeX.

• ...because of the many legacy documents in TeX, and because of the large authoring community versed in TeX, a priority in the design of MathML was the ability to convert TEX mathematics input into MathML format.

Of course, as per the linked document, MathML isn't supposed to replace TeX any more than PostScript is - it's meant to be machine-generated from easier-to-input forms such as TeX.

Take a look at W3C's WebCGM and SVG recomendations.

Take a look at W3C's WebCGM and SVG recomendations.

You mean SVG? The non-proprietary W3C developed vector graphics format that I can view (admittedly only a limited subset of) in my browser today?

Stuart.

Not Quite

It is getting close though, and with plugins and authoring support already coming from the major graphics application vendors, promises to have a chance of being used in the mainstream.

Combine SVG with a DOM and scripting support (the obvious being Java^H^H^H^HECMAScript) and you have the beginning of an open standard Flash killer.

MathML markup is not primarily intended for direct use by authors. While MathML is human-readable, which helps a lot in debugging it, in all but the simplest cases it is too verbose and error-prone for hand generation. Instead, it is anticipated that authors will use equation editors, conversion programs, and other specialized software tools to generate MathML.

--

Web bugs are more evil than your average URL link because you have to click on the link, whereas a web bug (and the potential attached evil code) gets loaded automatically if you have an HTML-enabled mail viewer. Stuff like this is why I have intentionally avoided HTML-enabled mail clients. Automatically executing code from a remote, untrusted source is bad, kids.

HTML email gets a bad wrap. The thing people forget about HTML is that it is, at its core, a semantic markup language. HTML provides meaning to otherwise flat text. Flat text forces the author of an email to use how an email will look to get across meaning. On the other hand, HTML clients, done properly, allow the reader to decide how something will look.

My dream is to have an HTML-aware client that accepts everything that is in the XHTML-Basic specification. XHTML-Basic allows basic semantic markup, disallowing presentational elements such as <font>, and uses CSS to provide presentation. However, the client can choose to ignore the CSS, if the user wants, leaving all presentational items up to the reader.

In summary, plain, flat text for mail is one of the worst things we are plagued with. It mixes meaning with presentation. The author is forced to decide presentation, which is one of the biggest evils of communication. Presentation should be decided on the reader's end, with the message only containing semantic meaning; HTML allows this.