Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Fear of a XHTML World

By mdxi in Internet
Wed Dec 13, 2000 at 08:41:54 AM EST
Tags: Internet (all tags)
Internet

I'm very happy with the direction the W3C is taking the HTML standard, moving towards simplification and divorce of layout from content, but many people I have spoken with over the past few days are either confused, afraid or just plain angry over the changes taking place.

This, then, is a combination crash-course in how HTML works and rant on why standards are good and why we should support them.


Introduction

First, let's start off with an overview of the changes involved in the last 3 versions of (X)HTML. The last major revision of the HTML standard was HTML4 in 1997. Version 4 was a quantum leap over HTML3.2, with the single largest and most important change being the introduction of Cascading Style Sheets (CSS).

CSS In 500 Words or Less

What CSS did was allow us to divorce layout from content by replacing the formatting tags of HTML (like FONT) and attributes of the BODY tag (like bgcolor and background). This lets you write far cleaner HTML, because it isn't full of tons of tags which have no purpose other than specifying how tihngs look. In addition, you can either have your stylesheets appear inline or they can be in separate files, included in the HEAD section of the document, which makes it trivial to change the look of a huge collection of HTML documents.

Furthermore, CSS contains formatting elements that give you far more control over the presentation of your document than HTML ever did. Things which once required lots of TABLE or nbsp tricks (like drop caps, paragraph indents, double-spacing) become easy to accomplish. If you're just using CSS to set your background color, you're missing the point.

Finally, CSS stands for Cascading Style Sheets, and the Cascading bit means that the styles have inheiritance, which lets you do things like:

TD { background-color: white; vertical-align: top;
font-family: times,fixed; color: black; padding-left: 0.5em; }

TD.header { padding-left: 0em; padding-top: 0em; }

TD.side { background-color: #cccccc; font-family: helvetica, sans-serif;
font-size: small; border: 2px solid black; color: black;
width: 40%; padding: 0.5em; }

This is a bit from the stylesheet of one of my pages. It defines three sets of behaviours for TD tags. if a table cell is created with a bare <TD> tag, it will receive the style from the first statement. If I use <TD class="header"> then the TD.header style is applied in addition to the style inheirited from the TD style. In this case, the padding-left property is overridden from 0.5em to 0em and the padding-top property (which wasn't previously set) is set to 0em, and all the other properties are set as in the TD style. Any cell with 'style="side"' will have a totally different appearance, as all the properties of the TD style are overridden, so it actually doesn't inheirit anything.

At first glance, this may all seem confusing and over-engineered, but once you begin to use it you quickly see many powerful things that were out of your reach before. I highly recommend that anyone who actually writes HTML read the entire HTML4 and CSS2 specifications. I'll wrap up this whole section with this maxim: CSS GOOD, FONT TAG BAD.

Enter XML

Now, after HTML4 comes XHTML1.0 (actually, HTML4.01 is next but it's just minor tweaking). XHTML1 is simply a re-implementation of the HTML4 syntax in XML rather than SGML.

The benefits of this move are primarily to the authors of HTML User-agents (browsers), as it lets them use XML parsers instead of SGML parsers. This is a good thing because XML (and thus) XHTML must be well formed, which makes parsing it much easier, which makes search engines more accurate (possibly) and browsers faster (almost surely).

Well formed means this:

  • Container tags must be properly terminated (meaning that P and LI tags must be closed, for instance)
  • Container tags must be properly nested (meaning that <B><I>this</B></I> is not valid but <B><I>this</I></B> would be, except that...)
  • All tags must be lowercase, as XML is case-sensitive.
  • All parameters of tags must be delineated by quotes, even if the argument is numeric.
  • Non-container tags, like <br> are now self-terminated with a trailing slash (so <br> isn't valid in XHTML, but <br/> is.

These changes are really quite minor, provided that you were already coding to the HTML4 spec and not relying on the browser to DWIM, and show the importance of coding to spec if you want keeping up with the spec to be non-traumatic. But that's getting ahead of myself so we'll come back to that in a moment...

After XHTML1.0 (which is the current HTML specification) comes XHTML1.1. The only real change between XHTML1.0 and 1.1 is that all the tags deprecated in the HTML4 spec have finally been thrown out. Yes, thrown out. Gone.

FONT? Gone. CENTER? Gone. S and U and STRIKE? Gone. BLINK? Not even mentioned!Lots of others too, and many remaining tags have had attributes removed to further streamline the job of the user agent. See this document for a full listing.

The Human Element

Now we come to the problem. While removing these dead (bad, even. FONT Considered Harmful, anyone?) tags makes me very happy, every non-hardcore-technical person I have mentioned it to has been nervous at best, angry at worst. They don't see their work being made easier, they see their hard-won knowledge being made useless. They see their pages being broken overnight by some standards organization they've never even heard of. They see themselves no longer being literate in the language of the web. Let's address these concerns as best we can.

You and your little CENTER tag, too

First off, the elimination of tags like CENTER and the FRAMESET tags may seem rather extreme. How will you ever be able to write webpages without basic tags like that? The answer is simple: CSS. When I first read the HTML4 spec, I had a thorough knowledge of HTML3.2 and was completely mystified as a result. It's like Yoda says: You must unlearn what you have learned.

I was envisioning a future of webpages which looked like they did in 1995 until I read the CSS spec, and lo, there were all the missing features plus a boatload of new ones that I had never known before. And that's the situation we have here: the W3C is modularizing HTML and paring down the core language to make easy things easier and hard things possible.

Continuing the CENTER example, anything that you might need to center on a page should be enclosed in a <p> or <div> container in the first place, so making that container centered through CSS's text-align property is trivial. As for concern that HTML os being over-engineered, notice that the most common formatting tags, <b> and <i> are still in XHTML1.1 as it would just be a pain in the ass to use <span> tags (the HTML4 and up mechanism for arbitrary application of styles) for everything you might want to bold or italicize. But underlining? Strikethrough? Centering, superscript, 1-word color or font changes? Those are no more inconvenient when done through inline CSS than when you use dedicated tags for them. The overall complexity of the language has been reduced and at little or no usability cost to the author.

Your Pages Will Not Break

The second thing that people seemed to fear was that these new standards would somehow break all the pages they had created already. People who I thought were far too intelligent to make such statements actually said things like "Well, it sure was nice of them to break several million webpages" and "Too bad these people have never heard of backwards compatability".

In my opinion, the W3C is not a group of academics in an ivory tower, dictating arbitrary standards to the rest of the world. They are clearly a group of concerned professionals who work very hard to make tomorrow's web a better place than it is today. So let's say this once, and say it clearly:

The defining of new HTML standards does not break documents written in older versions.
The advent of HTML4 did not cause documents written in HTML3.2 to stop rendering, and likewise XHTML will not break your HTML4 or HTML3.2 documents. Rendering of HTML is determined by the browser, not the standard. As long as your browser knows how to interpret older versions of HTML (and chances are that it will for a VERY long time), your documents will look just fine.

That said, there is no reason not to start using the new specification to ensure that you stay current, but again that's getting into my next topic...back to the issue at hand.

How a browser handles a document is determined by something called DTD, or Document Type Declaration. A DTD tells the browser what version of HTML you are using. Most documents on the web don't even use a DTD, but things still look okay because browser authors have made the browsers very smart about rendering just about anything you can throw at them. A DTD gives a browser hints, though and can make things easier on the browser. DTDs look like this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

and they go at the very beginning of a HTML document, even before the <html> tag. That DTD is for HTML4.0, as you may have guessed. Including a DTD in your documents is a good thing to do, and in the future it will likely become more important.

The W3C Is Not Disenfranchising You

Right after people worried about their existing pages breaking, they started worrying about not being able to create new ones. This is at once, an understandable and unfounded fear.

People guard jealously knowledge about things they are unfamiliar or uncomfortable with. Someone intimately familiar with HTML could take the listing of changes to the language in this document in stride, and probably see applications for the changes almost immediately. But for someone with a passing (or no) familiarity, these changes are tearing away their tenuous hold on the core technology of the web.

There is nothing to fear. The heart of HTML has actually gotten simpler than ever, making it easier than ever to learn how to create simple documents. Creating complex documents has actually gotten easier as well, no longer requiring many arcane formatting tricks and hacks on the rendering techniques of individual browsers. Instead you just need to get a good grip on CSS, which is pretty large, but very few elements depend on each other so it's very easy to pick up piecemeal (I'd still recommend reading the entire spec if you're inclined towards that sort of thing).

Relatively few people actually write HTML anyway. This means that producers of HTML authoring tools simply need to start using XHTML and CSS to make most people's pages compliant from here on out.

*Insert bitter laugh here*

Yes, XHTML and CSS have the promise to make life easier and rendering faster for browsers, but the sad truth is that (contrary to most people's worries), the web will continue to be annoyingly backwards compatible. Already tools like FrontPage produce an unholy amalgam of CSS and HTML3.2 tags to try and ensure that a page renders cleanly on any (Microsoft) browser.

Conclusion!

And that is why standards are a good thing, and that is why we must use them and pressure others to do so as well. If not for groups like the W3C, HTML probably wouldn't even exist anymore; we'd have IEML and NSML and never the twain should meet. How do we apply this pressure? I'm not sure, but my first impulse is through gentle, one-on-one education. We've seen that groups like the Web Standards Project are ineffective, and have degenerated to the point of issuing bullying press releases to try and affect product design and releaase schedules (e.g. the Mozilla project).

Perhaps if everyone who is comfortable with HTML and its emerging facets could take the time to patiently explain how it all really works together to one other person, the net effect would start to grow. I've tried to make the opening sections of this document a template for that sort of thing. It probably won't have any real effect in the larger scheme of things, but it might make your local part of the world a more web-literate place (and that might take a load off your shoulders :).

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o HTML4
o Cascading Style Sheets
o XHTML1.0
o DWIM
o this document
o Also by mdxi


Display: Sort:
Fear of a XHTML World | 100 comments (92 topical, 8 editorial, 0 hidden)
XHTML = bad news for kuro5hin? (2.11 / 9) (#5)
by streetlawyer on Wed Dec 13, 2000 at 05:05:30 AM EST

All this stuff sounds fine and funky if you're in charge of your own site, but surely this trend to push everything into the CSS is bad news for reader-contributed sites like k5? Randy doesn't actually allow the center tag, but if he did, XHTML would leave anyone who used it in articles high and dry. In general, the assumption seems to be that anyone who's contributing material to a site is in a position to muck around with the CSS; this is not always the case, and I can see this being a problem for lots of intranet uses too.

--
Just because things have been nonergodic so far, doesn't mean that they'll be nonergodic forever
not really a problem (4.00 / 4) (#9)
by gregholmes on Wed Dec 13, 2000 at 05:50:41 AM EST

If you are contributing pages to a site, you can use a stylesheet in the <head> section of the page. If you are contributing fragments that get embedded, you can use inline style attributes.

And for a site like k5 where you only get to use a limited subset of HTML anyway, well, you can use whatever limited subset you are allowed.



[ Parent ]
Styles (none / 0) (#68)
by Qtmstr on Wed Dec 13, 2000 at 06:00:54 PM EST

K5 does not allow inlines style attributes, and writing a parser to filter them would be non-trivial.

test

<p style="textcolor: blue">Test

This comment was posted with "HTML formatted" on


Kuro5hin delenda est!
[ Parent ]
didn't say it would be easy (none / 0) (#73)
by gregholmes on Wed Dec 13, 2000 at 07:11:02 PM EST

From what I can see, k5 doesn't give you any other way to make blue text either. As I said, it has a limited subset of tags.

What does that have to do with the merits of XHTML?



[ Parent ]
CSS, Cascading style sheets. (3.00 / 3) (#14)
by Holloway on Wed Dec 13, 2000 at 06:35:49 AM EST

CSS stands for cascading style sheets. The cascading bit means that when formating a page the browser takes..
  1. CSS file
  2. <style> definition in the <head> of the document
  3. style="" attributes in the tag

The last in the list gets the final say for formating - and this overrides any previously set CSS definitions. Similarly, the <style> tag in the header gets preference over the CSS file.

Anyway, that's what they mean by 'cascading'.

Another question, though, is since XHTML has to be well-formed how do sites deal with forums where people tend to occasionally screw up their tags? (of course it doesn't actually have to be well-formed, no browser maker wants to deny rendering a page or not do the best with what they've been given - however broken).


== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

[ Parent ]

Well-Formedness (3.00 / 3) (#18)
by Ranger Rick on Wed Dec 13, 2000 at 08:52:36 AM EST

Actually, requiring well-formedness makes the "user input" problem MUCH easier. All you have to do is run new posts through an XML validator.

:wq!


[ Parent ]
Sort of (1.50 / 2) (#47)
by CAIMLAS on Wed Dec 13, 2000 at 01:38:34 PM EST

I'm not familiar with CSS, but couldn't things like the bold tag be aliased to perform similar functions inside the CSS? Just ramblings...
--

Socialism and communism better explained by a psychologist than a political theorist.
[ Parent ]

It is, but... (2.00 / 2) (#54)
by mdxi on Wed Dec 13, 2000 at 02:48:01 PM EST

That effect has always been part of CSS. My point was that the and tags were left in because forcing people to use:

<span style="font-weight: bold;">

would have been over-engineering the purity of the spec and would likely have caused (even more) backlash against the changes.

--
SYN SYN NAK
[ Parent ]

*sigh* (2.00 / 2) (#55)
by mdxi on Wed Dec 13, 2000 at 02:55:39 PM EST

I love how K5 eats your LTs and GTs when you post after previewing.

Sorry about that mess.

The second sentence should read:

"My point was that the B and I tags..."


--
SYN SYN NAK
[ Parent ]
There are other tags... (none / 0) (#95)
by magney on Fri Dec 15, 2000 at 12:47:41 AM EST

What's wrong with <strong> and <em>?

Do I look like I speak for my employer?
[ Parent ]

Poor, abused BLINK (3.61 / 13) (#8)
by TuxNugget on Wed Dec 13, 2000 at 05:40:22 AM EST

The main problem I had with blink is that everything on the site blinked very slowly, all on and off at the same time. How unimaginative.

Clearly, the tag needed to be <BLINK frequency=f></BLINK>, or maybe <BLINK bitmap=#ff007eff65a></BLINK> to set an on-off bitmap relative to other blinking stuff.

Similarly, with the commercialism on the net, I am suprised there is no one-time blink, like <SUBLIMINAL frames=3><font size=+5>Buy it now!</font></SUBLIMINAL> would be shown for 3 frames on your monitor, and then disappear. Your eye would barely notice.

Eek (2.66 / 6) (#22)
by flieghund on Wed Dec 13, 2000 at 10:02:47 AM EST

Clearly, the tag needed to be <BLINK frequency=f></BLINK>...

While this may seem like a good idea in theory, consider the following very realistic scenario:

<BLINK FREQUENCY="3">some text</BLINK>
<BLINK FREQUENCY="19">some other text</BLINK>
<BLINK FREQUENCY="37">yet more text</BLINK>
...and so on...

To me, the only thing that prevented <BLINK> from being the basis for homicidal rage was the fact that everything on the page blinked at the same, slow rate. (But trust me, it was only by the slimmest of margins.) You can rest assured that if given the opportunity, some people would have twenty different things blinking on each page, all at different rates.

Now, if we could only convince people that those damnable scrolling marquees in the window.status area are bad, we'd be getting somewhere...


Using a Macintosh is like picking your nose: everyone likes to do it, but no one will admit to it.
[ Parent ]
Web pages that suck (1.75 / 4) (#26)
by TuxNugget on Wed Dec 13, 2000 at 10:33:06 AM EST

Yes, blink is evil, but I think people should have the right to write Web Pages that Suck.

Now if you thought <BLINK frequency=f> was bad, how about <BLINK frequency=f color++>. Or hell, why not play with the fonts, or other CSS style elements too :-)

[ Parent ]

That's called DHTML (2.00 / 3) (#33)
by pin0cchio on Wed Dec 13, 2000 at 12:19:17 PM EST

Now if you thought <BLINK frequency=f> was bad, how about <BLINK frequency=f color++>. Or hell, why not play with the fonts, or other CSS style elements too :-)

By this time, you might as well be using EcmaScript (the language formerly known as JavaScript until Sun cracked down on misuse of the Java trademark) to control the CSS DOM. A term has been coined for this: DHTML. Like all Web presentation technologies, DHTML can be abused.


lj65
[ Parent ]
evil BLINK... (2.00 / 2) (#92)
by Moghedien on Thu Dec 14, 2000 at 04:08:04 PM EST

blinking text lives on... it's in CSS2!

But according to the specification, "[c]onforming user agents are [luckily!] not required to support this value."

Why not just let blinking text die... or better yet: donate it to people in need. :P


---
[57 68 6F 20 63 61 72 65 73 2E]


[ Parent ]
<BLINK> Misconception (4.00 / 1) (#100)
by ewhac on Tue Dec 19, 2000 at 06:04:15 AM EST

My personal theory is that <BLINK> was born when Netscape spoke to (or hired) a bunch of idiots who had the only "real" prior experience with on-line marketing. These failures in "consumerizing" the on-line experience all used NAPLPS (North American Presentation-Level Protocol Standard); Prodigy and Viewtron being the most conspicuous examples. NAPLPS has a provision for drawing blinking graphics; it was how the marketroids drew attention to the "BUY NOW!" graphic. Doubtless some marketing moron thought this was a good idea; thus was born <BLINK>.

But that's not what I wanted to rant about. Specifying blinking text is a presentation issue, not a content issue. It can be argued that blinking -- or color-cycling, or scrolling, or whatever -- is a form of emphasis. Thus, <BLINK> should have more properly been defined as an attribute of <EM>. Indeed, I would argue that <STRONG> should also have been a sub-class of <EM>.

Schwab
---
Editor, A1-AAA AmeriCaptions. Priest, Internet Oracle.
[ Parent ]

One issue (3.57 / 7) (#10)
by evvk on Wed Dec 13, 2000 at 05:54:15 AM EST

There's one issue, although most people probably couldn't care about it, although I do: older browsers. I prefer netscape3 for many reasons. Many new media infested pages are barely browsable in it but I can stand that; I just want the information. How will XHTML pages break in old browsers? No one seems to be creating a new browser (for *nix) that I would want to change to (bloated, slow, etc.). Well, one could create a proxy, I use junkbuster anyway... just something to think of.




It decomposes just fine (4.50 / 8) (#12)
by mdxi on Wed Dec 13, 2000 at 06:09:55 AM EST

Though I didn't mention it, one of the design features of CSS is that it degrades gracefully.

If you have a client that understands CSS2, you'll see CSS2. If your client only unstands CSS1, you'll see the effects of CSS1 formatting but not CSS2 formatting.

The far, far more likely scanario is the not-understanding-CSS-at-all client, like NS3 or links or w3m. CSS pages tend to look perfectly acceptable, though plain, in these clients, because they ignore CSS altogether and only see the simplified (X)HTML that remains.

The only area where CSS is a problem is with NS4.x, which has a hellaciously broken CSS implementation. It tries, and fails catestrophically, to interpret pages containing non-trivial CSS formatting. It is a pile of shite and I advise anyone using it to move to a modern graphical browser like IE or Mozilla, or go to one of the nifty new generation of text browsers like links or w3m.

--
SYN SYN NAK
[ Parent ]

NS4 and CSS (2.60 / 5) (#21)
by coolvibe on Wed Dec 13, 2000 at 09:36:58 AM EST

If you don't like how NS4 renders style sheets, then turn it off! If you don't mind less styled pages, it is cerntainly an option.

In NS4: Edit -> Preferences -> Advanced, Turn off style sheets.

NS4 might be a pig, but don't knock it down for that. :)


--
Yet another community site: hackerheaven.org. Now in juicy Scoop flavour!
[ Parent ]

Degrades gracefully? (3.16 / 6) (#32)
by nstenz on Wed Dec 13, 2000 at 12:08:30 PM EST

Though I didn't mention it, one of the design features of CSS is that it degrades gracefully.

I've read that over and over, and it's somewhat true, but I have a bit of an argument...

Whether you or I like it or not, formatting has become very important on the web. Fancy animated rollovers, buggy JavaScript, and Flash pages we can't navigate with the keyboard have nearly taken over. Eye candy gets people interested. People might stay for content on the site, but flashy graphics sometimes make them look first.

Because of this, formatting is extremely important. I don't think looking like crap != degrading gracefully. The hacks I have to go through to make pages look good on both NS and IE are certainly a pain in the rear; but if I ditch all of those hacks and only use CSS, my pages will look like crap or just be plain ugly on 'older' browsers.

They're plain enough already. NS4's stylesheet support is crap. An awful lot of people use NS4. Mozilla still needs work (although it looks damn nice compared to NS4). I like to be able to have my pages look reasonably decent in IE3. I'll use stylesheets, but I'll be damned if I'm not going to use <font> when necessary. The font a page uses is a large part of the style that page has. Most of my pages look like crap in any 'Serif' font (such as Times, Times New Roman, etc.)

What I'm basically saying is I can't stop writing 'old school' HTML until almost everyone is using Opera 3.6+, IE4+, Mozilla/NS6+, etc. I refuse to alienate a large part of my audience.
(Yes, I do try to design my pages so text-to-speech agents can make some sense of them - I agree changes in the specs are necessary, and I applaud the W3C for their efforts.)



[ Parent ]
But you are alienating your audience (3.33 / 3) (#39)
by AndrewH on Wed Dec 13, 2000 at 12:43:41 PM EST

What I'm basically saying is I can't stop writing 'old school' HTML until almost everyone is using Opera 3.6+, IE4+, Mozilla/NS6+, etc. I refuse to alienate a large part of my audience.

Instead, you take it out on anyone who uses a minority browser, or customises their browser or video preferences.


John Wilkes Booth, Lee Harvey Oswald, John Hinckley Jr — where are you now that we need you?
[ Parent ]
Alienating how? (2.50 / 2) (#60)
by nstenz on Wed Dec 13, 2000 at 03:50:09 PM EST

Instead, you take it out on anyone who uses a minority browser, or customises their browser or video preferences.

How am I alienating anyone? I'm saying I write pages so browsers that don't understand CSS and XML can still format them decently... I do use CSS, and the only cheap hacks I do for formatting involve tables, the way it's been done for years... definitely a bad way to do it, but the only way to do it without breaking any browser more than a few years old. I generally run pages through the W3C's tests to see if handicapped users will still be able to navigate them - and they turn out ok. I use <strong> where I want to make a point, and <b> where I do something for formatting only. Using <font> instead of <span style="..."> doesn't alienate anyone.

As for people who customize their video settings, I'm one of them. I have a computer on a smallish TV at 640x480 with the fonts at least double the size they'd be on any normal monitor settings. They still format just fine. I admit they're not that pretty, but they're certainly readable.

I don't think you understood the point I was trying to make. Like I said, I don't want to alienate anyone.

(By the way... Is anyone else annoyed when they put in HTML character codes for < and > and IE turns them into the equivalent HTML versions? I remember the post a while back where someone thought Mozilla was broken dealing with this issue... It just bothers me.)



[ Parent ]
Resolution and table bodging (none / 0) (#87)
by AndrewH on Thu Dec 14, 2000 at 07:06:36 AM EST

As for people who customize their video settings, I'm one of them. I have a computer on a smallish TV at 640x480 with the fonts at least double the size they'd be on any normal monitor settings. They still format just fine.

My monitor is set to 1600×1200 for fine graphics, with large (in pixel terms) fonts; I have seen a similar setup on a 1280×1024 laptop, where the resolution obviously could not be dropped. Any web site putting text in a fixed-width table (classic CSS avoidance; K5 itself does it) comes out with very narrow columns.


John Wilkes Booth, Lee Harvey Oswald, John Hinckley Jr — where are you now that we need you?
[ Parent ]
Not too narrow but too wide (none / 0) (#88)
by evvk on Thu Dec 14, 2000 at 10:00:26 AM EST

> Any web site putting text in a fixed-width table (classic CSS avoidance; K5 itself does it) comes out with very narrow columns.

To me the problem is often the opposite: the pages are too wide. "Web designers" seem to suppose that everyone is using a fullscreen or similar shape browser. I don't. My browser windows is shaped like an A4 paper in portrait orientation, less then 700 pixels wide, and many pages are way too wide to fit there. I want more than just the browser to fit on the screen simulataneously without overlap and it is easier to read when the lines aren't too long. A rule of typography --- that's why newspapers have narrow columns, LaTeX uses relatively wide margins and many pages emulate narrow columns with table kludges (because they think the users have a wide browser).

[ Parent ]
"Twelve fourteen in the morning and all is we (2.20 / 5) (#13)
by Holloway on Wed Dec 13, 2000 at 06:22:30 AM EST

In the few tests I have done with Netscape 3 on win95 it won't break on XHTML. However, as N3 doesn't understand CSS at all, you'll find yourself in less styled pages with less or no use of Bold, <u>underline</u>, italics, etc...

That's pretty much it, and due to the attempted seperation of style from content in XHTML (I say attempted due to the messy way CSS abstracts positional placement from <TABLE> to boxes defined by X/Y - which doesn't work, IMO)


== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

[ Parent ]

XHTML degrades better (4.25 / 4) (#52)
by jesterzog on Wed Dec 13, 2000 at 02:33:16 PM EST

Actually i think as long as it's done properly, XHTML degrades better than HTML 4. The only potential issues are browsers that half understand CSS but are buggy (eg Netscape 4), and browsers that might cough at the sight of a / at the end of a tag. (eg <br />) LINK, DIV and SPAN shouldn't be a problem because since the earliest HTML specs, browsers were told to ignore tags they didn't understand.

A few days ago I was messing around trying to get a perfect XHTML page, and I got it. The entire formatting in this - including background image - is done using CSS, which I'll move to external CSS when it's ready. There are no formatting tables at all.

Really all it is is in the HTML is a bunch of header and paragraph tags with a couple of images, surrounded by DIV's and SPAN's. Looked at with CSS switched off, it's simple information. Black text on a grey or white background, depending on the browser settings, which is abouit what web pages were supposed to deliver in the very first place. Simple information.


jesterzog Fight the light


[ Parent ]
Tableless HTML (4.00 / 3) (#56)
by joeyo on Wed Dec 13, 2000 at 03:12:41 PM EST

Congrats! I have not yet been able to get my code 100% tableless for formatting purposes. (see here) I tried for a bit, but it looked horrid in netscape 4 and especially the mac version of netscape 4. Shudder.

For the most part I'm xhtml 1.0 compliant with the exception being some code generated by perl scripts. But I'll get that fixed soon enough. I've been really happy with html + css. It's made getting and updating a constant look across all my pages a trivial task. It was getting so that most of my time was spent updating things not adding new content.

I'll have to try again to remove the tables soon. After all, most of the world uses IE (or mozilla) anyway, right?

--
"Give me enough variables to work with, and I can probably do away with the notion of human free will." -- demi
[ Parent ]

Oustanding! (2.66 / 6) (#11)
by gregholmes on Wed Dec 13, 2000 at 05:56:12 AM EST

Best write-up I have seen on this. I would only add my personal soapbox against WYSIWYG editors; that now it is even easier to actually write (X)HTML instead of generate unsupportable monstrosities of pages.



Not the point (3.00 / 2) (#29)
by ubu on Wed Dec 13, 2000 at 11:11:56 AM EST

Ugh. XHTML merely perpetuates the monstrosity-creation process by continuing to butcher and cripple document data. Can anyone honestly argue that (X)HTML is a best-of-breed destination for presentation material? Of course not. Can anyone argue that (X)HTML is a best-of-breed source for document data? Of course not.

So why not author in an XML-application-specific tool (GUI or otherwise, it doesn't matter in the least) and allow translations to handle conversion to other formats -- formats which can competently represent graphical data -- like PDF, FO, and SVG?

If that were your approach, you'd never be concerned with editing the formatted document; it's a throw-away piece of material. You'd be concerned with editing either the document data (in its source format) or the style sheet (also in a capable source format).

Ubu
--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
reality (3.50 / 2) (#34)
by gregholmes on Wed Dec 13, 2000 at 12:23:21 PM EST

I happen to share your sentiments. But that is not going to happen anytime soon, in a widely used web presentation sense.

Essentially, your vision is not what most people making content for the web want. If it was, HTML would have remained primarily structural (in fact, it would have evolved more that way).

While we were berating Netscape and MS, they were giving most web development people what they wanted. Not what they needed, maybe, but what they wanted. And what they wanted was presentation.

At least XHTML with stylesheets lets us make highly structured documents, with most presentational aspects abstractable. And there is nothing stopping you from using SGML, XML, or whatever you want and translating it into what browsers understand (i.e., XHTML). Just don't expect very many other people to do it.



[ Parent ]
Reality sux0rs! (2.50 / 2) (#41)
by ubu on Wed Dec 13, 2000 at 12:49:55 PM EST

While we were berating Netscape and MS, they were giving most web development people what they wanted. Not what they needed, maybe, but what they wanted. And what they wanted was presentation.

I think you're spot-on, and I'm more sympathetic to this "reality" thing than you might suppose from reading my rant. However, I think that XHTML is a solution to a problem that never existed... more to the point, it is a serious problem in its own right: it perpetuates the broken model that XML was intended to repair.

If we don't honestly expect people to "get" XML then we have already conceded defeat. Bring on the proprietary formats, then, it doesn't matter anyway. If, on the other hand, we propose to work hard at changing the landscape of the Web, we could keep our hair longer and curse at fewer idiots.

This data/presentation bifurcation really isn't difficult at all. And the XML pioneers have done such an outstanding job of providing tools and solutions and maturing standards. I hate XHTML because it betrays the hard work and expensive advances that have so far buoyed the next generation of documents.

Ubu
--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
HTML 3.2 is evil (3.14 / 7) (#15)
by enterfornone on Wed Dec 13, 2000 at 07:28:57 AM EST

I'm rather fond of HTML 4 (haven't really played with the X stuff, is there any difference other than the extra slash in <img /> tags?).

HTML just became too ugly as MS and Netscape went about turning it into a typesetting language, moving most of the layout stuff to stylesheets has gone a good way to correcting this.

--
efn 26/m/syd
Will sponsor new accounts for porn.
Pedantic Post (2.33 / 6) (#19)
by blacksmith on Wed Dec 13, 2000 at 09:10:42 AM EST

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> isn't actually a DTD - it's a call to an external DTD.

I'll stop nitpicking now.



It's a DTD, not a DTD :) (2.00 / 2) (#42)
by mdxi on Wed Dec 13, 2000 at 12:55:53 PM EST

The TLA "DTD" is overloaded with respect to markup languages.

The usage I show here is a "Document Type Declaration", and that line is that type of DTD. You are correct, however, that it is a call to an external "Document Type Definition", which in this case if the definition of What Is HTML4.

So we're both right (unless I'm wrong in this assertion).

--
SYN SYN NAK
[ Parent ]

Good old days (3.22 / 9) (#20)
by elb on Wed Dec 13, 2000 at 09:26:55 AM EST

How I miss the good old days of html. No tables, no background images, no javascript. Just clean pages that downloaded quickly even over 9600bps dialup. None of this slick shiny crap meant to make the web nothing more than an "interactive" televison advertisement.

No, I am not a luddite. Yes, I appreciate how far the web has come, and what it has enabled. But permit me my nostalgia, for one brief moment...

Rose-tinted spectacles? (3.33 / 3) (#36)
by martini_time on Wed Dec 13, 2000 at 12:32:27 PM EST

If the shining turds of javascript rollovers, flash movies and rampant .com commercialism disgust you so much, then why not reject the WWW completely - apparently gopher's where it's at for the 21st century. (link won't work in Nutscrape). Personally I think that it all went to shit the moment they stopped using punch cards, DC electric and steam engines...

[ Parent ]
Crazy people writing about standards... (1.60 / 10) (#23)
by sergio on Wed Dec 13, 2000 at 10:04:45 AM EST

Is it me or this guy is out of wack? The article even has a few errors.

I think that the evolution of HTML should have stayed fixed at 3.2 and let the new XML based content and the XSLT translations make sense of matching al the INCOMPATIBLE
BROWSERS there (Hit: Upper case means I am not a happy camper about something).



What have you been smoking? (3.50 / 2) (#25)
by AndrewH on Wed Dec 13, 2000 at 10:29:43 AM EST

The article even has a few errors.

Nothing you can share with us evidently.

the INCOMPATIBLE BROWSERS there

Read the comments or follow the advice.


John Wilkes Booth, Lee Harvey Oswald, John Hinckley Jr — where are you now that we need you?
[ Parent ]
Read (2.75 / 4) (#27)
by ubu on Wed Dec 13, 2000 at 11:05:11 AM EST

Nothing you can share with us evidently.

XHTML1 is simply a re-implementation of the HTML4 syntax in XML rather than SGML

This is not true; the modifications in XHTML really have nothing at all to do with the differences between SGML and XML.

And while I realize that the article is aimed at an HTML-using audience, the XHTML + CSS approach is really unfortunate. The transition to XML isn't about standards-compliance so much as it is about improving document management. A far better approach would be to teach appropriate XML application-specific authoring alongside XSL/FO translation. Style sheets are nothing more than a prescription for translation, anyway, and a shoddy one, at that.

Although many people claim XHTML is vitally necessary, my opinion is that it's a debilitating concession to the foot-dragging "Web monkeys" who feel they've a God-given right to preserve their niche. A lot of people invested heavily in transient HTML technology, and it's hardly appropriate to coddle them at this point, not especially when they've been given so much time to rethink their approaches.

Even the linked comments regarding CSS and its ability to deal with incompatible user-agents ring hollow when you consider that this situation still leaves the user-agent in total, unpredictable control of how the page is rendered. The situation is worsened as user-agents are asked to support an ever-increasing raft of "standards" and features. By contrast, a general translation and formatting specification like XSL/FO allows the author(s) to create data once, format it once, and store it once, while retaining the best pure-data/pure-formatting aspects of any particular format.

XHTML's proponents generally claim that it's "good enough for now", which is essentially an admission that it's destined for the trashbin along with all the other crap browser manufacturers have been floating for the past 5 years.

Ubu
--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
No, you read (1.50 / 2) (#37)
by AndrewH on Wed Dec 13, 2000 at 12:35:13 PM EST

XHTML1 is simply a re-implementation of the HTML4 syntax in XML rather than SGML
This is not true; the modifications in XHTML really have nothing at all to do with the differences between SGML and XML.

Yes, the HTML4 syntax, not an earlier version.


John Wilkes Booth, Lee Harvey Oswald, John Hinckley Jr — where are you now that we need you?
[ Parent ]
Complete the sentence? (1.00 / 2) (#38)
by ubu on Wed Dec 13, 2000 at 12:42:38 PM EST

Yes, the HTML4 syntax, not an earlier version.

I have no idea what this is intended to mean.

Ubu
--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
XHTML v HTHL4 (1.00 / 2) (#40)
by AndrewH on Wed Dec 13, 2000 at 12:48:11 PM EST

I mean that the differences between XHTML1 and HTML4, as opposed to the differences between XHTML and HTML3.x that you seemed to be thinking of, are indeed the differences between SGML and XML.


John Wilkes Booth, Lee Harvey Oswald, John Hinckley Jr — where are you now that we need you?
[ Parent ]
Weak SGML at best (2.50 / 2) (#45)
by ubu on Wed Dec 13, 2000 at 01:09:34 PM EST

The brand of SGML supported in HTML4 is only nominally compliant with ISO8879. Even the HTML4 standard implies (Appendix B.3.3) that user agents are not entirely responsible for full compliance with the standard.

Moreover, the transition from HTML4 to XHTML1 may appear -- from strict reading of the specification -- to be a transition from SGML to XML, but that is only one small facet of the change. The larger issue of user agent implementation -- requiring well-formed and even valid documents -- is the key issue at this point. SGML doesn't even support the notion of "well-formed" documents; valid documents are the only allowed input. With that in mind, HTML4's de facto usage isn't particularly affected by any implications of an SGML --> XML migration.

Ubu
--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
On Errors... (1.00 / 2) (#59)
by sergio on Wed Dec 13, 2000 at 03:47:38 PM EST

Maybe you can try and spot a few of them... I don't want to spoil all the fun and learning
you can get from that exercise :-)

[ Parent ]
UPPERCASE tags (3.50 / 6) (#24)
by flieghund on Wed Dec 13, 2000 at 10:28:40 AM EST

I miss the uppercase tags. The two things about HTML that I found the most helpful when trying to write and later read through source were the ability to add meaningless white space (meaning you could indent tags to add structure to the source), and that tags were in uppercase letters (at least in every page I ever worked on). The latter was very important to me because, even without structural whitespace, I could scan down a page of source and find a particular section of the web page fairly quickly. Just like using bold to emphasize certain words in a passage, UPPERCASE LETTERS do the same trick for hundreds of lines of source.

The (IMHO) silly conversion to lowercase-only tags and attributes, while mostly a psychologial barrier, still remains a huge barrier for many people. The source looks different, and that is enough to cause some people to avoid the conversion. And if you are faced with converting legacy source from hundreds of pages -- which was poorly WYSIWYG coded with something like FrontPage 1.0 and hacked into a functional state with the electronic equivalent of duct tape (I wish I was making this up) -- it becomes a daunting task, usually with little support from management to make the change. (...Since the pages "look" fine as they are now. Nevermind that they have 1:2 s/n ratios, burried broken links and "hidden" text, etc.)

(And yes, I know there are conversion tools available, but when the source code bites as much as this stuff I'm working on does, the converters spit out garbage. How some of these pages display at all is beyond me.)

Something I wonder, however, is why you couldn't just specify a call to an alternative XHTML DTD that allowed uppercase tags? I mean, other than the fact that it would "go against the specification," what if the only difference was the presence of uppercase tags? Maybe even in addition to (versus "instead of") lowercase?


Using a Macintosh is like picking your nose: everyone likes to do it, but no one will admit to it.
I AGREE *grin* (2.66 / 3) (#28)
by nstenz on Wed Dec 13, 2000 at 11:10:39 AM EST

Whether I'm writing HTML or spitting out 'real' code at work, I just fly through things in lowercase and get my ideas on the screen. But- When I'm done with a page/function/whatever or have a free minute to just stare blankly at the screen, I go back and convert everything to uppercase. It really does make everything much easier to read and understand. HTML tags literally jump out at you when they're in all caps... having < >'s around them doesn't do a damn thing - they're all smushed together so the tags bump up against the data. I tend to nest my HTML so the text is on the line below the tag and indented, but that doesn't always happen, and it isn't going to with XML either. Likewise with my code - built-in functions, constants, and reserved words are in uppercase, my functions and variables are in lowercase. It's so much easier to read.

Color-coding HTML editors and IDE's take care of much of the problem, but some people DO have to use vi/emacs/notepad/whatever once in a while without any pretty colors. (I just hate those hack jobs from a friend's house when I realize I screwed a page up...)



[ Parent ]
I dislike UC (2.50 / 4) (#30)
by titivillus on Wed Dec 13, 2000 at 11:34:49 AM EST

I was told in courses that writing HTML with uppercase tags made the HTML stand out from the text. I've never really agreed, and with my favorite browser, if I'm looking for something, I just have to type "/<tag" to find what I need. It has never worked as advertised for me, so I find the switch to lowercase for XHTML a source of amusement.

[ Parent ]
A Poor Solution (3.60 / 5) (#44)
by mdxi on Wed Dec 13, 2000 at 01:02:06 PM EST

IMO, uppercase tags was a cheap hack designed to deal with a lack of intelligent tools for authoring HTML (and no, I don't mean WYSIWYG editors).

If you write HTML in XEmacs, for instance, it will color syntax-highlight everything you write, which maked tags stand out quite remarkably (they're orange for me instead of the grey of plain text) and makes it abundantly clear when you've forgotten to close a quoted attribute (because everything after it turns the green of quoted strings).

Additionaly, it indents everything for me, based on parsing the DTD, which makes the document structure far easier to see than vgrepping for uppercased tags ever would. So the problem isn't one if tag case, but of intelligent tools.

Your sig mentions Macintosh; I believe BBEdit is popular because it has smilar capabilities

--
SYN SYN NAK
[ Parent ]

htmltidy (3.25 / 4) (#50)
by HypoLuxa on Wed Dec 13, 2000 at 02:03:20 PM EST

I've had great success with html tidy, actually written by on of the guys at W3C. I write total crap, illegible to anyone but me html. I generally run it through htmltidy to universally uppercase my tags (it can be run to universally lowercase tags as well), add correct DOCTYPE defenitions, indent, and generally "tidy" my html up (hence the name). With tools like that, which do work in my experience (YMMV), this kind of change for case sensitivity is not a problem.

--
I'm guided by the beauty of our weapons.
- Leonard Cohen
[ Parent ]
I and B nitpickiness (4.25 / 8) (#31)
by Greyhame on Wed Dec 13, 2000 at 11:37:54 AM EST

While the <i> and <b> tags have been left in the XHTML spec (more as a concession to the countless "web designers" who don't know better than to throw a fit if they were taken out, than in the interests of a useful markup language), they are still layout markup elements, and, to be most correct, should not be used in a content markup language.

Yes, it would be an incredible PITA to use <span class="foo"></span> tags to put in bold and italic text in one's XHTML documents; but that is also not the W3C's goal. Since at least HTML4.0 (I don't recall whether they existed previously), the spec has included (and I've never seen a browser that didn't understand) <em> and <strong> tags, for "emphasized" and "strong" text, respectively. Since these almost invariably map to italic and bold in user agents, it seems a little like a mere semantic dodge on the W3C's part, but the distinction is actually valid. CSS can always be used to overrule the user agent's default rendering of the tag; and to cite on of the W3C's examples, the newer (X)HTML/CSS specs are designed for better accessibility--e.g. a text-to-speech renderer for blind users. "Strong" and "emphasized" make much more sense in a speech context than "bold" and "italic" do.


I am Ozymandias, King of Kings.
Raises the bar for doing. (2.87 / 8) (#35)
by Cyberdeck on Wed Dec 13, 2000 at 12:29:15 PM EST

Disclaimer: I write device drivers for a living. This is the first document that I have seen on ***TML.

The similarities between what mdxi writes here and the releases for specifications like "Plug and Play" and "WDM" are astounding. The specs were written to reign in the chaos of design, provide a framework for new things, and simplify the lives of all involved. That the actual implementation was bobbled is not the point.

The point is that whereas it used to take a week or so to write a bare-bones driver, it now takes months for the same thing, and the writer/author must have a very thorough understanding of the new spec before they can begin. Advanced tools will not help the pronounced learning curve that this kind of spec creates. If past experience translates, this means that there will have to be a rigorous design phase, a TLD session, and planning of the style and content both together and then separately. I figure a very simple 20 minute web-page design might now take 2 days to do.

This is my point. It will now take much longer to do simple things, raising the bar to getting these things done. This is the real reason why people object to the new spec.

Do not misunderstand me. I approve of the new spec (having suffered through many bad or broken web-pages), but it does add effort to doing the job.

-C
You can never have a bad day when you start it with "FORMAT C:".

why more difficult? (4.33 / 3) (#43)
by gregholmes on Wed Dec 13, 2000 at 12:57:17 PM EST

I just don't see how this is more difficult, at least on a page of any complexity and size.

For example, in IE5 and NS6, you can basically position boxes of content however you want, without using tables. You can do it with absolute or relative positioning, relative to an enclosing container or to the page. And you can do it with amazingly few lines.

The spaghetti mess of trying to replicate such a layout in older HTML (if it can even be done) is a horror to see (and edit).



[ Parent ]
CSS Positioning (3.33 / 3) (#46)
by mdxi on Wed Dec 13, 2000 at 01:25:29 PM EST

I've played around with CSS's positioning capabilities and Z-buffering, even made a document which mimicked a Window Maker screen using overlapping tables and transparent PNGs, just because I could.

It's really neat, but to be honest, I'm not really sure what the point of it is. You mentioned layout without tables, which hadn't even crossed my mind. I can't wait until that sort of thing is an option in GeoCities's HTML Builder Thingy :)

--
SYN SYN NAK
[ Parent ]

Here is a good example (4.50 / 2) (#49)
by gregholmes on Wed Dec 13, 2000 at 01:58:06 PM EST

Here is a good use; a two column layout without tables. This tutorial even shows you how to make it work in NS4! (not easy)



[ Parent ]
Netscape stops this (3.66 / 3) (#58)
by Jim Dabell on Wed Dec 13, 2000 at 03:32:36 PM EST

I agree, CSS positioning is easier to use, quicker to use, and a better design. However, when I implemented a simple layout using it, guess what Netscape did to it? It:

  • Made items overlap, causing sections of the page to become unreadable
  • Made links "unclickable"
  • Complete removed the possibility of using that design with CSS

Now before you say anything, I'd better note that this was all valid XHTML+CSS1. And I wasn't asking for very much. Just a sidebar, a title, and a content area with items in a box with a border. It couldn't even manage the border.

Now what's easier: finding workarounds for the ten major bugs or so in Netscape (assuming they exist) that my site triggered, or just keeping the old table layout? Of course, there is a bug in Netscape that allows a CSS file to be "hidden" from NS4, but my site renders as if it was viewed in Lynx without CSS, and I would prefer at least a little style.

At the moment, I'm moving towards XML+XSLT, and serving up different pages based on user-agent. I know it's unreliable, buts as long as I keep to spec and default to the "most compatible" version, I can't really be blamed when my site blows up when somebody is using NS4 and sending a UA header claiming to be IE5.



[ Parent ]
well, sure ... (3.00 / 1) (#64)
by gregholmes on Wed Dec 13, 2000 at 04:34:21 PM EST

By all means, design to your needs. If you must support every browser in existence, do so.

We're talking about new standards. NS4 isn't going to render XML + XSL by itself anytime soon either. If you're going to generate browser specific pages, I don't see why you can't generate XHTML while you're at it.



[ Parent ]
re: well, sure ... (3.50 / 2) (#66)
by Jim Dabell on Wed Dec 13, 2000 at 05:14:13 PM EST

When I was talking about XML+XSLT, I meant on the server-side. I wouldn't have to go to the trouble of generating browser-specific pages if NS4 didn't screw things up so badly. The tables layout solution is a backwards compatible hack, and a really ugly one at that. But it's necessary as long as a significant number of people are using NS4.

[ Parent ]
no argument here (2.00 / 2) (#89)
by gregholmes on Thu Dec 14, 2000 at 12:46:52 PM EST

I guess we're talking apples and oranges. Server side transforms are great. XHTML (or HTML3.2) is what you transform the info into.

I was limiting my comments to what the browser is parsing, or rather what standard to use for what it should be parsing.



[ Parent ]
Lowers the bar (5.00 / 1) (#94)
by KindBud on Thu Dec 14, 2000 at 08:00:56 PM EST

This is my point. It will now take much longer to do simple things, raising the bar to getting these things done. This is the real reason why people object to the new spec.

Simple things can be done in HTML 2.0, for some definition of simple. What is your definition of simple, if HTML 2.0 is not able to do it?

I don't think the bar has been raised, I think it's been lowered. HTML code is a lot easier to read and maintain without all the formatting tags sprinkled throughout, and the browser doesn't have to download a zillion fonts tags on every page hit, if a consistent style sheet is used throughout the site. Those two things do wonders for both authors and browsers.

--
just roll a fatty

[ Parent ]

the -really- cool shiznit (4.18 / 11) (#48)
by cbatt on Wed Dec 13, 2000 at 01:38:47 PM EST

Hehehe... you know what I love about XHTML/XML/Xetc...?

XSLT/XPath. CSS is really just a minor factor in all of this.

With these key technologies, I can transform any valid XML file into another format.

Have an XHTML 1.1 document, but the requesting client can only view HTML 3.2? No problem. Set up an XSL server side transform, and tada, the client receives HTML 3.2, <font> tags and all. Need to serve the same document in HTML4.1 with CSS? Set up a different server side transform, same excellent results.

I'll concede that most people will not have the resources/know-how to take advantage of this technique, but backwards compatibility will always be there. I can't see MS or Netscape removing HTML 3.2 support from their browsers in the near future.

In the meantime and in between time, HTML scripters can casually migrate over to the new standards. Or stick with the old ones as they'll be supported for quite some time. (They have to be. There's far to many documents out there in old, non standard 'broken' HTML for them to simply throw the support away).



-----------
Before you can understand recursion
you must understand recursion.

I agree (4.50 / 2) (#51)
by mdxi on Wed Dec 13, 2000 at 02:27:47 PM EST

I whole-heartedly agree. I'm working on some XML/XSL:FO stuff myself in a large-scale document authoring/publishing/maintenance system I'm designing for my own use.

That direction certainly is where the true promise of XML lies, but in this article I was trying to address the immediate concerns of people I've recently spoken to.

A full treatment of what XML and a good toolchain can do for us would make an excellent article. Anyone want to write it? :)

--
SYN SYN NAK
[ Parent ]

cool (3.00 / 1) (#65)
by cbatt on Wed Dec 13, 2000 at 04:37:26 PM EST

I'd love to write that article, but I'm busy writing software. Though I too would love to see an article that shows how XML can be used and how it is best being used right now. Outside of the realms of simple website issues.

Something that helped to dispell some of the myths that surround it. There are so many of those that it's difficult to see the reality of the technology, and I'm tired of reading the countless articles that just get things all screwed up over a single aspect, when the totality of XML is so much more.

However, I suspect that K5 and it's ilk are not the best places for an article along those lines.



-----------
Before you can understand recursion
you must understand recursion.

[ Parent ]
Actually, old web pages may break (3.50 / 4) (#53)
by broken77 on Wed Dec 13, 2000 at 02:33:33 PM EST

Regarding the comments "Container tags must be properly terminated (meaning that P and LI tags must be closed, for instance)" and "Your Pages Will Not Break"... Actually, I can explain a specific instance that will crash Netscape 4.7 (or was it 4.61, can't exactly remember) _every_ time. Make an absolute-positioned <div> tag with another absolute-positioned tag inside of it, and inside the inside tag, put a

element, and _properly close_ that element. This will crash NS every single time. The only way to fix it is to take out the closing tag. I'm sure there are other examples of how well-formed HTML will break in older browsers. And unfortunately, a good number of people are going to be using older versions of NS for quite a while in the future :-(

I'm starting to doubt all this happy propaganda about Islam being a religion of peace. Heck, it's just as bad as Christianity. -- Dphitz

What about... (2.66 / 3) (#57)
by Mandos on Wed Dec 13, 2000 at 03:14:05 PM EST

Some forum software lets us post a breathtaking array of tags. In the future, will we have to write CSS at the top of our posts or something for this to happen?
---------------------------------------------------------

`o Mandos `o tyrannos tôn 'exoterikôn

On learning CSS (3.50 / 10) (#61)
by ignatiusst on Wed Dec 13, 2000 at 03:50:53 PM EST

People hate change. Always. I hated the thought of CSS. It worried me, and I closed my eyes, hoping it would go away. For a while, just that seemed to be happening. It was slow to catch on, and met with a lot of resistence. This was good.

But then wiser web designers than I began to take a closer look at CSS, and began the slow realization that CSS had a world of possibilities that HTML could never hope to incorporate.

Still, I hated CSS.

More and more web pages began incorporating CSS into their site development, and it was cool. They could do amazing things that I had to use Photoshop and gifs to accomplish. They had sleek, sexy pages. I had slow, bloated pages.

I developed CSS-envy.

Today, I have a stack of tutorials and reference guides 18" thick on my desk -- All on how to implement CSS. I hate to read through them, and often curse the W3C gods for their indiffernce to my plight. Sooner or later, though, I will be a CSS expert and I will speak on the subject with an air of condescending superiority... Then k5 will no longer be able to hold my Ego, and I will have to reactivate my /. account.

hehehehe....

When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him. -- Jonathan Swift

CSS isn't that hard (1.00 / 2) (#74)
by krogoth on Wed Dec 13, 2000 at 07:13:51 PM EST

I remember when I first heard about CSS while looking for information no DHTML. I thought it was a great new tool that would make it a lot easier to make more strongly formatted webpages. I still use the simple tags like and to make a quick webpage where I just want to display some information that's easy to navigate, but when I want to make a more advanced webpage, I use CSS a lot. It is longer sometimes, but after you learn a few simple rules all you need to do is remember the attributes you use. I can understand that people would be scared if their job was threatened by a new technology, but I like finding a new tool that makes my job easier. The only problem is that if we move to the newer XHTML standard, small pages will probably take longer to make. <span class="bold"> will always be longer than <b>. If they find a way to fix that problem, I will probably use pure XHTML all the time (by that time, if it ever happens, it should be safely compatible with most people's browsers)
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
dammit.... (1.00 / 2) (#75)
by krogoth on Wed Dec 13, 2000 at 07:16:08 PM EST

I forgot to turn off the bold and italic (i probably wrote the tags by accident. The place where the bold starts is supposed to be and the place where the italic starts is supposed to be .
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
dammit.... (1.66 / 3) (#76)
by krogoth on Wed Dec 13, 2000 at 07:16:15 PM EST

I forgot to turn off the bold and italic (i probably wrote the tags by accident. The place where the bold starts is supposed to be <b> and the place where the italic starts is supposed to be <i>.
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
I agree. (3.00 / 1) (#91)
by Moghedien on Thu Dec 14, 2000 at 03:42:21 PM EST

I agree. I grew up with CSS and DHTML, and it has served me well.

I have dabbled in IE5 with custom tags (<nih:b> for <b>, for instance) using XML namespaces, it's shorter than using span classes, and it's easier to read. But I strongly suspect this is a MS-only standard... though it would be nice if it caught on.


---
[57 68 6F 20 63 61 72 65 73 2E]


[ Parent ]
CSS - good idea? (3.25 / 4) (#62)
by andreas on Wed Dec 13, 2000 at 04:07:36 PM EST

I didn't really do a lot of HTML since version 2.0, but I think XHTML is the correct answer to the creeping featurism in HTML.

But I'm not so sure if CSS was done the right way. Why does CSS have it's own syntax? Wouldn't XML have been a much better choice?

If CSS had XML syntax, I could use the same set of tools I use for processing XML files (parsers, XSLT engines, editors etc.). The way it is, I always have to treat the CSS file separately.

I've heard that SVC used CSS nowadays as well, because the guy who sits in the SVC committee is the same guy who invented CSS, and he was so fond of it. COmmittees, blech.

separated formatting model (4.00 / 1) (#71)
by jesterzog on Wed Dec 13, 2000 at 06:44:39 PM EST

HTML and CSS were never supposed to be bound together, I don't think. The HTML specification itself seems quite careful to point out that they're not tied together - CSS seems to have simply been first out of the gate and therefore most popular. From here:

Independence from specific style sheet languages

This specification doesn't tie HTML to any particular style sheet language. This allows for a range of such languages to be used, for instance simple ones for the majority of users and much more complex ones for the minority of users with highly specialized needs. The examples included below all use the CSS (Cascading Style Sheets) language [CSS1], but other style sheet languages would be possible.

I think there are one or two XML-based style languages around (eg XSL, although that's more of a template language IMHO), but they're not supported very well. Thankfully though, new style and formatting languages can easily be developed in the future without the HTML spec having to be changed at all. It's one of the nicest things about separating the markup from the formatting.


jesterzog Fight the light


[ Parent ]
CSS was published before XML (4.00 / 2) (#86)
by paranoidfish on Thu Dec 14, 2000 at 06:16:20 AM EST

There's a simple reason CSS doesn't use XML - Css was first published in 1996 and XML was first published in 1998

It's a bit much to expect the W3C to have used a standard that doesn't exist!



[ Parent ]
Framesets (2.50 / 2) (#63)
by dennis on Wed Dec 13, 2000 at 04:09:40 PM EST

For static hypertext I hate framesets. But for a complex web application, where you're building client-server database stuff on the web, framesets can help a lot. You can keep menus on screen without refreshing them all the time or copying them into lots of pages. You can play nifty tricks with javascript that reaches between frames, so you can hit the database by refreshing a hidden frame, pull in just the little bit of extra info you need, and use dhtml to write it into your main display page, instead of refreshing a page full of info just to add a little something. You can persist information in a hidden frame instead of using cookies. There are all sorts of advantages to having independent pages displayed in framesets. Is there a CSS equivalent for this?

Framesets vs. IFRAME (3.00 / 1) (#67)
by nstenz on Wed Dec 13, 2000 at 05:30:06 PM EST

Something just occurred to me... If framesets don't exist in XHTML, does that include the <IFRAME> tag? I had a kick-ass idea about how to write a little web-chat page that didn't require 'push' or constant refreshing of the page. Problem is, it needs IFRAMEs... Are those gone too? That would be taking away some functionality- there is no way to make stylesheets and such replace that like server-side includes and a refresh can replace frames.

[ Parent ]
Sounds neat... (3.00 / 1) (#69)
by dennis on Wed Dec 13, 2000 at 06:08:42 PM EST

Actually server-side includes and refresh wouldn't help for the things I was talking about... I'd be interested in how your chat idea works. Feel like sharing?

[ Parent ]
Backward Compatability (3.50 / 2) (#70)
by bjk4 on Wed Dec 13, 2000 at 06:43:05 PM EST

I believe there is one point left unaddressed in this very well written essay.

If everything were equal, I'd write using CSS, XHTML, and XML. The problem is that not all browsers were made equal. The netscape browser, at least up to 4.7x, does not enable CSS if you have javascript turned off. I turn javascript off because it does things I don't like.

There also happen to be people who do not use a 4.x browser. These people are stuck without the benefit of CSS entirely. Why do I care about these people? I care because I cannot make a change in the font-size without the font tag. I care because I would have to make two pages, and serve the more advanced one to browsers that can handle it.

Many people like to dismiss these things, but if you operate a grocery store, you don't turn away everyone wearing red! It puts people who are unable to upgrade, or unwilling, at a great disadvantage.

Anyway, I felt this wasn't addressed in the essay. Too bad the world isn't ideal.

-B

(nice theory, bad practice) (4.00 / 6) (#72)
by seb on Wed Dec 13, 2000 at 06:52:03 PM EST

As I think others have pointed out, the problem with HTML4.0 is backwards compatability. They won't break old browsers, but HTML4.0 pages _will_ look like crap in something like IE3. "User experience" is king in the commercial Web; the branding exprience must be as uniform as possible across all browser platforms. At least 1% of the average internet audience will be using pre-version 4 browsers, perhaps more if your site is heavily used by corporate users. It's worse than this, though. The standards are applied differently across different browsers. And that's not just between NS and IE: IE 4, 4.0x, 5, 5.5, and Mac IE 4.5 and 5 all understand their HTML4.0 differently.

You can bet that the most popular web sites are the ones who have invested the most into usability testing and cross-browser compliance, and a look at their source code reveals that they nearly all use the dreaded <font> tag. (try microsoft, lycos or amazon).

Things like mozilla's XUL are really, really exciting but their benefits are unlikely to filter through to mainstream web usage within the next couple of years. I'll still be using <font> for another year, at least.

I'd rather just move forward (4.50 / 8) (#77)
by mdxi on Wed Dec 13, 2000 at 07:20:46 PM EST

I really didn't want to get into this argument, which is a large one with no "correct" answer. That's why I didn't say anything about it in the write-up, but I'll share my thoughts here.

I test every page I create on Mozilla (Linux and Mac OS), IE5 for Mac, and w3m. I make sure that Mozilla and IE render things *identically*, font differences aside, and I make sure that the design is clearly laid out in w3m (and thus links; they're very similar in layout).

Also, I *know* that every page i create is kinda fucked under NS4.x. I know this. It pains me to look at my sites under NS4, but most people who use it don't notice anything wrong, because ALL CSS-using sites look that way to them.

As for NS3/IE3...if you're still using something that old, it MUST be through a concious decision and I doubt you expect things to be rendered perfectly in the first place.

I feel that by making sure my layout is clean in the current generation of graphical browsers and text-based browsers, I achieve three things: (1) I feel good because I'm writing clean code based on modern standards, which (2) makes things better for handicapped users, because modern HTML is far less cluttered than HTML3.2 and seems to be easier to use with voice-browsers, and finally (3) looks right to the *majority* of people using graphical browsers.

I honestly feel that using modern standards for my layout makes them *more* backwards compatible. You'll never see one of my sites using 100% JavaFoo pages. You'll never find Flash content at all, much less the infamous Intro Page Of Death (you know, 1337 Flash intro with no way past it? 'Cause EVERYBODY has Flash, right?)

You cannot maintain backwards compatibility above all else. That is a losing strategem. What if Linux had never moved to the ELF format? What if glibc2 had never been implemented? what if Apple had never jumped to PowerPC? I'll tell you what: we'd all be in the same mess Microsoft is now with *wanting* to move forward but being held back by 2 decades of insisting on backwards compatibility. You must be able to at some point say: "This is the point of diminishing returns; damn the torpedoes, full speed ahead".

People *will* upgrade their browsers. The Unwashed Masses will, anyway. Those who don't are either so out-of-touch that they won't notice the difference anyway or technical iconoclasts with chips on their shoulders (like me).

I think the argument abuot corporate sites needing to maintain compatibility at all costs is an empty one. Corporate sites are usually the worst offenders at accessibility and readability (to say nothing of their usual content-free nature).

Anyway, I'm done ranting about that now. Thanks :)

--
SYN SYN NAK
[ Parent ]

Yes, but corporate sites pay my wages (4.25 / 4) (#85)
by seb on Thu Dec 14, 2000 at 05:49:11 AM EST

I agree with everything you say (and your article was excellent, btw). There's no "right" answer to this issue. I think that the nearest thing to a "right" answer depends on your own relationship with the web. Mine is defined by commercial necessity, unfortunately.

If the internet were just about technical elegance, we'd all be spiritually content, but those of us who make a living out of the web would be in trouble. I don't have a choice. I have to produce a site that looks good on any vaguely significant platform, to keep my clients happy, to earn money. That's the real world that *I* live in. Yours is different, but I would suspect that most people who work in the industry would (reluctantly) agree with me. I appreciate your point about, for example, Microsoft. It is a commercially successful company which stifles innovation. Commercial interests and innovation are usually mutually exclusive.

Therefore, the "real world" must be a compromise between the two. You have to recognise that HTML 4 will remain the cutting edge rather than the norm for some time. Meanwhile, I think that people such as you who are willing to push the boundaries, and do that which is right rather than expedient, play a crucial part in shaping the web of the future. But I'd submit that you need people like me as much as I need people like you.

On another note, it *is* particularly important to enable people with disabilities to read web pages, and this is where the w3c have really excelled in the HTML 4 standard.

But even here, theory and practice are different. I've experimented with one of the main voice-browsers and to be honest, it's pretty brain-dead, and doesn't support half of the W3C accessibility features. It ignores all the special CCS directives for voice browsing. For someone with a disability, theory is a luxury when it comes to accessing content on the web.

Because voice browsers ignore almost all mark-up, the priority in making accessible pages is to ensure that your content is not reliant on visual layout in order to make sense. That means not using tables in inconsistent ways. The other priority is to make sure you use descriptive alt tags (I notice your site doesn't do this consistently. Nor does it use HTML4, nor does it use correct HTML3.2. Sorry, couldn't resist that :-P).

My approach these days is to encourage clients to produce an alternative, parallel site for those with accessibility problems. So far only one has been willing to pay (and the results were somewhat dubious...), but happily this is becoming a legal requirement soon.



[ Parent ]
I'll be damned (3.00 / 1) (#96)
by mdxi on Fri Dec 15, 2000 at 04:09:07 AM EST

Wow, you're right.

All I can offer as a defense is that my personal site (mdxi.collapsar.net) is [A] Very Spottily and Infrequently Maintained and [B] the first thing I ever converted to a CSS-ful state. Portions of it still don't even obey the most current stylesheet; I've been focusing my efforts elsewhere (read: anime.collapsar.net).

I would never have noticed that the DTD on the index page was for 3.2 if you hadn't pointed it out. I could have sworn I went through and changed them ALL, months ago :)

Thanks for the heads up. Now, I'm off to see what else needs fixing.

--
SYN SYN NAK
[ Parent ]

CSS and visual similarity betweeon browsers (3.75 / 4) (#78)
by jesterzog on Wed Dec 13, 2000 at 08:23:01 PM EST

One of the cool things I noticed when I made this page a few days ago (still heavily being worked on) is that it comes out almost identically in both MSIE5 and Mozilla. When I made an unusual mistake that I couldn't understand and one of them mis-rendered the page, the other one mis-rendered it in exactly the same way. Probably that was my fault, but it was evidence that they're even consistent in some of the more obscure specs.

Perhaps it's because the Mozilla team copied the MSIE display, or it might be because the specs are so consistent and specific. I hope it's the latter, because if so it'll make it much easier to design consistent-between-platform pages using CSS in the future, yet still have them readable in text based and speech browsers, and so on.


jesterzog Fight the light


[ Parent ]
the scoop (4.40 / 5) (#79)
by cbatt on Wed Dec 13, 2000 at 08:26:08 PM EST

As I posted somwhere down this thread, the real deal with XML/xhtml comes into play when mixed with XSLT to produce documents for delivery to any platform.

Once the source document is in a proper XML format, then it becomes trivial to serve it in whatever other format you wish.

The key is to get everyone producing correct XML documents. Hence, the coming of XHTML to supplant HTML4.x.

The main thing to remember is that you will rarely ever need to directly serve XML/xhtml documents to your users. You will, 99% of the time, filter them through an XSLT into something that their browser can use.

Furthermore, if you are in a real XML/XSLT environment, the need for the totality of the HTML tagset is decreased as you will invariably be customizing the root DTD/Schema by which your markup will be validated. Again, this will ALL be server side.

More on this later... I've gotta run...

-----------
Before you can understand recursion
you must understand recursion.

[ Parent ]

Yes, yes, yes (4.00 / 4) (#80)
by trhurler on Wed Dec 13, 2000 at 09:49:50 PM EST

But when will browsers actually have proper support for it? As of now, I can write HTML 4 code with CSS that will actually cause some popular versions of popular web browsers to crash, to say nothing of the ways you can fool existing rendering engines into producing unreadable tripe. I doubt they're suddenly going to catch up to the new standards.

This has been a peeve of mine for years: do not tell average people to utilize a new standard before the software average people use can actually handle that standard. Otherwise, you are the problem.

By the way, making people use lowercase for tags is EVIL. It makes tags blend in with text even more than they already do, which makes scanning a large HTML document looking for some particular item or other impractical without resorting to regular expressions - which of course most people can't use effectively. In addition, getting rid of framesets is a really bad idea. You can simulate them, but it is much more difficult, and there is no good reason for it - it is a decision made purely for reasons of ideology.

Also, browser authors are not going to benefit from any of this - because they must support all prior versions of HTML if they want to claim to be compliant with the standard. Talk about how it makes their lives easier to use this new standard is bullshit. The benefits of this, in the next 10 years will be primarily for ideological purists and that ever-so-annoying breed of wannabe who asserts that he is superior because his web page is compliant to this spec, or his latest program is written in that language, or whatever - the trendfreak. Real men don't follow trends. Real men write in C, and they liked the way HTML 2.0 looked, god damn it.

:) A bit of an overreaction, I realize, so there's no need to crucify me for it, but I really am sick of people who think constantly messing with a good thing is sensible behavior. The company I work for has somewhere on the order of 20,000 users spread across thousands of sites in addition to indirect users through partner arrangements, almost all of whom use web browsers to access our services. The single biggest user problem we have, aside from users who forget passwords, is browser problems - and that is entirely the fault of people who can't leave well enough alone long enough for the software writers to actually catch up. Thanks, W3C.

--
'God dammit, your posts make me hard.' --LilDebbie

Framesets are still there (4.00 / 1) (#81)
by DavidTC on Wed Dec 13, 2000 at 10:44:53 PM EST

See the DTD



-David T. C.
Yes, my email address is real.
[ Parent ]
UPPERCASE tags are EVIL (5.00 / 1) (#82)
by F'jord on Wed Dec 13, 2000 at 10:56:27 PM EST

By the way, making people use lowercase for tags is EVIL.

You have this wrong. The W3C orginially did advise that the tags should be in uppercase to more easily differentiate from content, but later reversed this decision. Why? Because lowercase text compresses better, since there is invaribly more lowercase text in the content than uppercase. Having an even mix of the two cases in the document causes the compression of the document to dtrastically change.

So what? You say. I don't download .html.gz files. But the fact is that html files get compressed at many different points on their way to you without you even knowing it, and having them compress better is better for everyone.



[ Parent ]
compression (3.33 / 3) (#90)
by trhurler on Thu Dec 14, 2000 at 03:03:06 PM EST

Readability is so far and away more important than compression that it is not even comparable; if compression characteristics are that important to one particular user, then that user should run the HTML through a filter that lowercases the tags before sending it off, but the idea of making things harder on humans in order to make it easier on machines is ludicrous - this is not 1950, and today, people are much more expensive than computers.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
readability (none / 0) (#98)
by Tumbleweed on Sun Dec 17, 2000 at 01:47:45 AM EST

If you're concerned with readability, then you should structure your (X)HTML code such that it doesn't matter what case your tags are in.

[ Parent ]
I like lowercase tags (3.00 / 1) (#97)
by Delphis on Fri Dec 15, 2000 at 09:53:52 AM EST

Yep, I like lowercase tags.. I actually find them MORE readable than uppercase tags too. I like using Homesite to edit pages in too, it's fast and has a lot of useful tools, one of which is 'convert tag case' .. that makes it the function of the user writing the document to decide how they want to view it. I'd never thought of the document case making a document more compressible.. I guess it might do, but as someone else mentioned, that's not the most important thing. I write HTML and PHP in lowercase and I'm happy... plus my shift keys are happy too :>
--
Delphis : For Pay Distributed Processing
[ Parent ]
procrastinating retired newbie question (3.00 / 2) (#83)
by mami on Thu Dec 14, 2000 at 02:45:11 AM EST

Thanks for the article.

I retired from making web pages three and a half years ago and have never used anything more than html3.2. I made at that time almost thousand pages by hand and hated it, because I knew I should have done it differently, but wasn't quite sure how and had no time to learn more.

Now I would like to slowly restart. Can I skip learning CSS ? Just go directly to XML ? What about DocBook ? I want to make consistently looking pages with have a lot of code, text and footnotes in it, which request consistent format and layout. They will be served from a MySQL database with the Interchange content management/shopping cart system.

I have so many other things to learn that I really don't want to spend a lot of time learning the wrong stuff and like to get an advice what I can leave out. I like spartan design and do mostly rely on color and ample white space for look and feel, will never use ads and can't stand pages who look like they are made for TV.

Any short advice what the minimum is I have to dig into ? Books to suggest? I kind of keep procrastinating to start the whole thing because the actual formatting of the content is the thing I am the least interested in. But of course I have to do it.

CSS is important (3.00 / 1) (#99)
by job on Sun Dec 17, 2000 at 10:34:00 AM EST

Sorry. CSS is probably the most important thing you can learn right now. It still exists in XHTML and will not go away just because of XML, it'll just mutate into something called XSL.

For today, learn HTML4 and CSS2. That's what's important right now.

[ Parent ]
Standards are a good thing, but... (4.12 / 8) (#84)
by Radagast on Thu Dec 14, 2000 at 05:36:54 AM EST

The W3C has made a number of unfortunate design decisions lately, both in HTML4 and XHTML1, that make them incredibly difficult standards to follow if you want some measure of backwards compatibility (your idea of backwards compatibility seems to be that old pages should work in new browser, while there's also the more important issue of new pages working acceptably in old browsers).

Mistake number 1: HTML 4 Transitional isn't transitional enough.
When the W3C designed HTML3, they didn't catch up with what vendors were doing, hence HTML3 was never deployed. Instead, they gathered up all the vendor tags and released HTML3.2, which was a snapshot of HTML as it was being used at the time.

One would expect that they would have learned from this problem when they designed HTML 4 Transitional, but they didn't. The "transitional" elements in HTML 4 Transitional are limited to the ones included in HTML 3.2, totally ignoring what elements had come into common use in the meantime. As such, HTML 4 transitional does not incldue the very common topmargin/leftmargin/marginheight/marginwidth attributes to the <body> element, nor the background/bgcolor attributes to table cells. It's fine to keep these out of HTML 4 Strict, but they should have been in transitional, it would have made it much easier to design pages that also looked as intended on older browsers.

Mistake number 2: XHTML mime type confusion
The XHTML1.0 spec describes a number of tricks one can use to make XHTML parse in older browsers which use SGML parsers. Things such as <br /> instead of <br/> will keep element recognition from breaking, for instance. Additionally, the spec seems to hint that one can use text/html as a mime type for XHTML, and that this will work perfectly. However, things got more complicated. The W3C stated that if the document is served up as text/html, it should always be parsed by the SGML parser, even in XML-capable browsers. The problem was solvable (specifically by parsing text/html as SGML to begin with, and restart parsing with the XML parser if the <?xml?> element was encountered, but the W3C explicitly forbade this.

The result is that it's impossible to use XHTML in any backwards compatible fashion at all, since you have to choose your mime type (you could sniff HTTP Accept: headers, but most browsers send */* anyway, so that would break in a large number of cases), and if you choose text/html, you get none of the advantages of XML (like namespaces, one of the major wins of using XHTML over HTML4), or if you choose text/xml, you get a page that can't be displayed at all in older browsers (most will say "text/xml is not a supported mime type" and give you the option to save the file to your local disk).

These are just some of the examples of severe brokenness coming out of the W3C (don't get me started on the near-unimplementable complexity of things like CSS2 and SVG, the latter so complex that the only people in the world who've come close to implementing all of it are Adobe, who just happen to own the world's most advanced structured imaging architecture, PDF 1.4).

So yes, standards are good. But no, W3C standards are not all good. I don't know what else we have, though, which is unfortunate, but I do know that if browser makers follow the W3C standards to the letter, we'll end up with a world of completely broken backwards compatibility and extremely slow implementations because of the complexity of the standards. The W3C made some mistakes in the past, but it seems that they're so eager to rectify them that they're going to burn all bridges to do so.

-Joakim Ziegler

Well it's about time (3.00 / 2) (#93)
by KindBud on Thu Dec 14, 2000 at 07:29:20 PM EST

I found this paragraph amusing:

First off, the elimination of tags like CENTER and the FRAMESET tags may seem rather extreme. How will you ever be able to write webpages without basic tags like that? The answer is simple: CSS. When I first read the HTML4 spec, I had a thorough knowledge of HTML3.2 and was completely mystified as a result. It's like Yoda says: You must unlearn what you have learned.

I stopped paying attention to the next HTML revision around 3.2, when <FIG> was left by the wayside, but <font> and the other presentation tags were made official. Even though CSS was introduced at about the same time, nothing supported it, and nothing would for quite a long time (except Arena). At that point HTML became uninteresting to me, just a really terrible Postscript-sort-of-wannabe. I turned my attention to other things, and paid no attention to the files on the web farm.

So I don't have anything to unlearn here. I can just pick up where I left off and I'll be right up to speed. It is as if the last 4 years or so didn't happen, only it's too bad they didn't happen 4 years earlier, uh, or something.

Back when all the changes were being made away from structure to presentation, I spoke out in newsgroups and so on about the way HTML was going, subscribed to W3C mailing lists, all that. Didn't have any effect, the web went careening down the path of least resistance, or path of quickest profits, however you want to look at it. But I always said that if HTML as a structural language was no more, then something else would need to be created to take its place. And now its happening, and it is HTML itself that has returned. So now I get to say:

I TOLD YOU SO!!

--
just roll a fatty

Fear of a XHTML World | 100 comments (92 topical, 8 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!