Is this what the W3C is gunning for?

[Mr Initial Man]

Yes, this webpage is purely satirical. But, like most satire, it seeks to make a point. In this case, the point is that of trying to get rid of a lot of tags that are, in my mind, still useful. Check it out, particularily the coding.

Just a warning: It won't work in IE; there are CSS rules in there that IE does NOT support.

http://mrinitialman.furtopia.org/Stu.../elementml.xml

[drhowarddrfine]

Well, you're cheating and you know you are. Just because you can do it that way doesn't mean you should.

If anything, you are showing the flexibility of xml over html. As the tags are deprecated, the usability of css increases and the need for those tags disappears. I can hardly wait till I can reliably shed (x)html and html altogether. I might even be able to do it now if I take the time to find out.

[Mr Initial Man]

Damn right I'm cheating!

As for (X)HTML, I hope it never goes away entirely. The reason is this: I think we NEED to have predefined markup languages such as XHTML, SVG, MathML, so we don't have to reinvent the wheel every time we make a website. Besides, when I use XSLT to turn XML into something readable on the internet, you know what it's transformed into? XHTML!

[felgall]

There is a clear distinction between what should be in (X)HTML and what should be CSS.

If the same code describes what it is correctly for people viewing on mobile phones, computer screens, braille keyboards, and listening via a web reader then it belongs in the HTML. If it doesn't make sense for all those people then it should be defined in a stylesheet targetted at the appropriate media.

People listening to a site can't hear fonts and centered and aligned right and things like that so those things are meaningless to them and shouldn't be cluttering up the HTML any more than the HTML should contain information on whether to use a male or female voice when speaking the content.

[Mr Initial Man]

You have a point. I know, I'm lazy and much prefer the (usually) smaller presentational tags (like <sup>) to <span class="superscript">. In a story I'm writing, I use <i> tags here, there, and everywhere, since it's easier for me to write <i>Guten Tag</i> than it is for me to write <span class="character_speaks_a_foreign_language_here">"Guten Tag"</span> followed by span.character_speaks_a_foreign_language_here{font-style:oblique;}, especially considering I use that over and over again.

[NogDog]

There is absolutely nothing wrong semantically with <i>"Guten Tag"</i>. You can give it more meaning as <i lang='de'>"Guten Tag"</i> (in case a really clever text-to-speech reader can read in multiple languages). And of course you can add class and/or id attributes to it as needed for CSS attributes.

Note that neither the <i> nor the <b> tag has been deprecated, though when either is being used for reasons of emphasis, then the <em> or <strong> tags make more sense; but when you are displaying foreign language text which by typographic conventions is typically set in an Italic font, the <i> tag would seem to make perfect sense. Non-semantic tags like <span> and <div> should only be used when you need to designate some sort of grouping of content where no meaningful tag makes sense.

[Mr Initial Man]

Thing is, I don't think <i>"Guten Tag"</i> would be possible in XHTML 2.0. I was checking the tag list on w3.org and didn't see it. I don't use the lang attribute, since the language used is a fictional one.

[drhowarddrfine]

we NEED to have predefined markup languages

XML Namespaces.

I don't think <i>"Guten Tag"</i> would be possible in XHTML 2.0.

That's what css is for.

[the tree]

I'm fairly sure the correct markup should be

<q lang="de">Guten Tag</q>

As that would mean something, <span> wouldn't and neither would <i>.

[Mr Initial Man]

Originally Posted by drhowarddrfine

XML Namespaces.

Ah, but isn't one of those namespaces the HTML namespace, which you're itching to be rid of?

Originally Posted by drhowarddrfine

That's what css is for.

But then we're back to <span class="character_speaks_a_foreign_language_here">"Guten Tag"</span>

Originally Posted by the tree

I'm fairly sure the correct markup should be

<q lang="de">Guten Tag</q>

As that would mean something, <span> wouldn't and neither would <i>.

I'll use <q> when the browsers handle it consistently. That is, when it no longer has those bloody quotation marks!

[Stephen Philbin]

Originally Posted by drhowarddrfine

XML Namespaces.

That doesn't make a lick of sense. What do XML namespaces have to do with your stated desire to replace a well established and meaningful markup language with a meaningless and unknown one?

As for the original topic, I don't really agree. The subtractions made from the markup "vocabulary" seem perfectly sensible to me. The subtractions I know of anyway.

[Mr Initial Man]

Well, isn't the point of getting rid of presentational tags to get rid of code bloat? Which looks more bloated? <i></i> (7 characters) or <span class="italic"> </span> (28 characters). Particularily when used over and over again?

[theuedimaster]

No, it's not about bloat. It's about EFFICIENCY. And efficiency is about having all the gears of a machine be distinct and not be conflicting with each other. It's about mobility, it's about organization, it's about accessibility. Plato's definition of Justice IMO.

[Mr Initial Man]

Well, <i> still looks a bit more efficient to me, though I could be wrong. :-/ Unless looking solely at file sizes isn't the way to go. ^^;

[theuedimaster]

Exactly, looking at file sizes is not the only way of looking at it. <i> is quicker, and efficient if you think of efficient in terms of the quickest way of doing something, but having something done quick is not always the best. Sure, when hardware specs were low, having software do things in the quickest manner possible was key. But now that we have gotten by that limitation in terms of html, we have to turn to other needs such as accessibility and mobility. By seperating all the parts of the machine, instead of having it all mixed up in a black box, we can more clearly fix things and find the information we want.

Basically, all the arguments you can use for supporting object oriented design can also support the separation of HTML into XHTML, CSS, etc.