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/Stuff_Set_aside/elementml/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 languagesXML 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]

XML Namespaces.

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


I don't think <i>"Guten Tag"</i> would be possible in XHTML 2.0.
That's what css is for.
But then we're back to <span class="character_speaks_a_foreign_language_here">"Guten Tag"</span>

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]

we NEED to have predefined markup languages.

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.

[Mr Initial Man]

Fine, you win. Instead of going with <i>, I'll use <font class="italic"> Happy now?


:D

[Stephen Philbin]

There's no need to use that though; well — not in most cases anyway. Just like the tree said, you should be using <q></q>. It's your choice that you do not.

It is intended that <q></q> causes quotation marks to be rendered. The idea being that <q></q> is better suited to internationalization than typing literal "s or 's, because the browser can replace <q> and </q> with the proper quotation marks used in the native language of the user. Rather than making the usual assumption that everyone in the world is English (or at least claims to speak it ;) )

[Mr Initial Man]

Well... In that case, there's still a problem with not all browsers supporting <q></q>. Excuse me a moment.

BLAMBLAMBLAMBLAM!

*Comes back out, gun smoking.* Anyone got another Internet Explorer poster? The one I've got now is... shot.

Couple of points I wanna make. If someone can't read English, my site's gonna be of no use. EVERYTHING I write is in English, I might as well use the appropriate quotation marks.

Oh, and the <font> bit was me tyring to joke.

[theuedimaster]

Well see... the quotation marks tag makes sense, because it doesn't necessarily define something that affects the whole. It just puts something at the beginning and end of the content... rather than applying italics to the content, which would require css...

And stuff like borders changes the whole, so you can't use that argument on me.

[Mr Initial Man]

And stuff like borders changes the whole, so you can't use that argument on me.

Could you explain a bit better?

[Stephen Philbin]

Hehe. Yup. He lost me with that one too.

[theuedimaster]

Well, HTML is all about structure. The structure of a web page is made up of elements, and these elements can be visualized in a box format. So, a web page is basically a bunch of boxes with content in terms of HTML (a stricter approach would be taking out content and putting it in XML, making HTML all structure).

CSS can do different things in terms of how that box looks to the user, and how the content within those boxes should be displayed. The border parameter changes how that box is displayed, and italics changes how the content is displayed. The <q> tag on the other hand, doesn't really fit into the definition of css. It doesn't affect how the box is displayed, and it doesn't affect how the content is displayed... instead, it actually sort of differentiates between different types of content (structure) and it adds some quotation marks (content).

That's why there should be a <q> tag, but not an <i> tag.

[Mr Initial Man]

a stricter approach would be taking out content and putting it in XML, making HTML all structure.

And how'd you get it OUT of the XML into the HTML? I dunno if XSLT would be very good at that with what I do. :-/

[theuedimaster]

Well, you could use a server-side language to parse the xml and put it into the html. But that's a *****, and sometimes, using a database is a better solution. At least with current technologies, putting content into the structure from a different file is sort of *****y. Which is why people usually leave content in with the structure.

[Mr Initial Man]

*Looks at the stars that suggest bad language.* WATCH YOUR %^$&#^ LANGUAGE! :D

Um... I use a flatfile database. One text file for each short story, essay, or chapter of my novels.

[theuedimaster]

Well see, in your case, xslt would be perfect. Put certain formatting for paragraphs, some for title chapters, etc. It would be very easy. Of course, you would have to put your novels in xml format.

[Mr Initial Man]

And how would I deal with all the inline formatting within the paragraphs? Which occur at irregular intervals. XSLT's good when info follows a set pattern (like for a table), not for this.

[theuedimaster]

such as?

[Mr Initial Man]

Here's the actual code for one page. No, it is not complete, as it is an include.

[theuedimaster]

Well, within <p> you would have to have a tag <content> for normal text, and maybe <i> for italics.

[Mr Initial Man]

Yeah, but how would I get it all to display properly?

[theuedimaster]

... using xslt? I don't really understand your question.

[Mr Initial Man]

... XSLT has to follow a set pattern of inputs, and my novels don't really follow such a pattern

[theuedimaster]

In that case, you apply templates to the different elements in your xml file.

http://www.w3schools.com/xsl/xsl_apply_templates.asp

[Mr Initial Man]

Which go tits-up if I try to add any sort of extra elements or styling.

[theuedimaster]

Reference your elements with css to do your styling (I think you can do that), and if you add extra elements, well, you'll have to style them. It's part of the job.

[Mr Initial Man]

No, I've tried to use elements and so on to define a template. The result was that Firefox couldn't read the XSLT file.

[theuedimaster]

Hmm... well I'll have to try doing that... I have no experience with actually implementing it, so I can't really help you here :). I'll try to mess with it soon. I wonder why firefox couldn't read the file...

[Mr Initial Man]

Besides, I can't help but wonder what the point of sticking all your content in a seperate file really is. Isn't it perfectly acceptable to have content and structure all in one?

[theuedimaster]

This gets to one of the main points for why you would not want to use xml for everything. The main reason for having xml is to create a universal playing field for displaying data. The power that this gives is to make data easily transferable from application to application, and programming language to programming language. BUT, if your content is for sure going to stay with the html language, like most websites, there's no reason to make your data have the mobility of xml.

In that case, having content with html structure is fine. Content and structure have a very mutual relationship, so combining them gives many advantages.

[Stephen Philbin]

You'd most likely be able to transform it all rather easily with XSLT (as long as the recieving XML processor is up to the job (which I'm not convinced Firefox is)), but rather than waste time messing with XML and XSLT why not just put q {font-style:italic;}?

[Mr Initial Man]

Actually, I'd have something like

q:before, q:after{content:"";}
q.foreign, q.thought{font-style:oblique;}


That puts all browsers on equal footing (IE doesn't support <q> properly), and allows me to use such things as .o0( ) for thought, and [ ] for when someone is speaking in a foreign language translated into English.

[felgall]

Say something in italic the way that you expect web readers to speak the content of the <i> tag.

[Mr Initial Man]

Let's see here.

I remembered my cat on the barn floor, wrestling with her sister. Cousin Robert thought she reminded him of Owen Hart, so Owen she became.

In this case, italics would be used to show that this is a flashback. In speaking, the tone of voice would be used to suggest the same thing. Of course, if you REALLY wanted to talk in italics, you could always lean to the right.

[theuedimaster]

I sort of agree with Felgall - a good writer doesn't need any formatting to emphasize a mood or idea. His words should be able to convey this message in its entirety. However, I do sort of disagree with Felgall - why does a writer only have to restrict himself to words? If he formats and styles his text, which is a visual enhancement to his ideas, why can't he do it? Who says you can't mix the two arts?

[Mr Initial Man]

For a writer, formatting helps. For example, I could write "'How could you do this to me?!' she screamed." But it doesn't have quite the same punch as "'How could you DO this to me?!' she screamed" (which is the formatting of class="yell-2").

Besides, doesn't <em> and <strong> come with their own formatting?

[Ultimater]

Saying formatting helps a writer is like saying images help the web designer.
JK Rowling emphasizes words that are said with attitude as well as unspoken thoughts and various other things including but not limited to magical spells.

[Ultimater]

Cursed new 10 minute editing limit. Two minutes over the clock and need to make a new post just to add this:
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!
I think coding in (X)HTML is reinventing the wheel. XSL allows the programmer to, in a sense, create modules for markup.

[Mr Initial Man]

Cursed new 10 minute editing limit. Two minutes over the clock and need to make a new post just to add this:

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!

I think coding in (X)HTML is reinventing the wheel. XSL allows the programmer to, in a sense, create modules for markup.

Okay, let's get rid of XHTML. Hell, lets get rid of ALL predefined langauges. Now. A newbie wants to build his first page. What does he use?

I agree XSL creates modules for markup. But if you're gonna be using ONE type of markup (In my case, XHTML), why use XSL?

[theuedimaster]

Because it integrates better with XML?

[Mr Initial Man]

If I use XHTML, I've got what I want already: A webpage! Okay, I use HTML 4.01, but when Internet Explorer clues in to what XHTML really is, I'm switching to XHTML 1.1 so fast... (Or, by that time, XHTML 4.01, probably ;) )

OKay. So let's say I have my page in XHTML. Suddenly I want to have a PDF version of my novels. Oh, dear, now I have to put my page into XML format and...

Wait a minute. What is XHTML? It is XML in and of itself! I just shove THAT into XSL, and I have my PDF.

Oh, but what if I don't want to write out the headers over and over again? It's called PHP INCLUDES! And I use those here, there, and everywhere in my webpage!

In short, I don't NEED to use XSL. Content with structure works perfectly well here.

[theuedimaster]

Because putting it in XSL saves an extra step in your pdf thingy. This = better. The only reason XSL isn't being totally fondled by the web community is that it isn't supported to the degree that XHTML is.

[Mr Initial Man]

How would having it in XSL save a step? I'd have to have something like this:

XML
|
+------------+------------+
| |
XSL-1 XSL-2
| |
XHTML* PDF
*Or something that can be displayed in a browser. PDF's SUCK at that.

Now let's say we start out with XHTML
XHTML**
|
XSL
|
PDF

**Already both browser friendly and XML.

Looks simpler to me.

[theuedimaster]

Yea, I decided to read up on what you just pointed out. Touche ;). I realize that XHTML is a powerful browser language, but I just keep forgetting that XML and XSL are just the universal translators, nothing more.

[Mr Initial Man]

Another thing about XHTML is it gives newbies somewhere to begin. If you can use XHTML, you can learn XML (including XSL)

[felgall]

I sort of agree with Felgall - a good writer doesn't need any formatting to emphasize a mood or idea. His words should be able to convey this message in its entirety. However, I do sort of disagree with Felgall - why does a writer only have to restrict himself to words? If he formats and styles his text, which is a visual enhancement to his ideas, why can't he do it? Who says you can't mix the two arts?


The whole point is that to emphesize something visually and to emphesize something when spoken are done in different ways. One may use italics but the other can't. Things which differ depending on the media being used to present the content belong in the STYLESHEET for the appropriate media and NOT in the HTML.

I never said that you should restrict yourself to words - my argument is the opposite - that you shouldn't use HTML markup that only makes sense for a written media. The <em> tag defines that something should be emphesized but doesn't specify that the emphesis should be italics because screen readers can't talk in italics and braille printers can't either (each has different ways of applying emphesis). The <i> tag implies that the content should be italicized and doesn't imply emphesis at all and therefore a screen reader which can't talk in italics would reasonably ignore the tag completely.

[felgall]

Besides, doesn't <em> and <strong> come with their own formatting?

Yes but their default formatting depends on whiich web browser/pda/web reader/braille printer that you are using which will apply the emphesis in a way that is appropriate for the media type.

[theuedimaster]

Oh, I've got it. You've got a different point entirely. I totally agree- the styling tags such as <i> must be taken out to ensure accessibility form not only pc browsers, but also phones, and even braille devices. That's a great reason to keep the styling out of the structure of HTML.

[Mr Initial Man]

*Nods.* So I really should replace all my <i>'s with <span class="">? I avoid <q> because of inconsistent support.

[felgall]

What's wrong with using <em> when you want to apply emphesis? Most browsers will display that in italics by default while web readers will use an appropriate voice to apply the emphesis and so forth.

The <i> tag does actually still have one genuine use and that is where you have a web page discussing typography where the page needs to show something specifically in italics rather than just using italics to provide emphesis.

Don't use <span class=""> where a semantic tag exists that properly identifies the content (such as <em> for emphesis and <strong> for strong emphesis) but do use it where such a semantic tag doesn't exist. Hopefully once the W3C gets all the presentation code that is actually media dependent out of the HTML into the stylesheet they will then be able to consider adding new semantic tags for the types of page content that are currently missing and where we currently need to use <span class=""> because the correct semantic tag doesn't exist.

[Ultimater]

The <i> tag does actually still have one genuine use and that is where you have a web page discussing typography where the page needs to show something specifically in italics rather than just using italics to provide emphesis.
Mind explaining a bit deeper upon this usage of the italic element over the emphasis element? I know its been depreciated in favor of <em> since it adds emphasis to the media although why cannot CSS3's voice-stress (http://www.w3.org/TR/css3-speech/#voice-stress) property be used on depreciated italic elements? Guess it could be used however I don't see how the italic element can be considered better in any manner.
Edit: Oh wait I see what you are saying, for visual italics without speech emphesis.

[Mr Initial Man]

How about in the case of the phrase "He said something sotto voce"? It is an Italian phrase, so in writing we show it in italics. My original markup was He said something <i>sotto voce</i>, but it should be more He said something <span class="foreign">sotto voce</span>. Am I not correct?

BTW, sotto voce means "under one's breath."

[EDIT] Ultimator, I do believe that it has to do with the actual name of the tag; <em> means "emphasize". It emphasizes its contents, no matter what its media (though I wonder how'd they do it with braille.) <i> means italics, which is written work only. And, unless I'm mistaken, both were around from the beginning.

[felgall]

Mind explaining a bit deeper upon this usage of the italic element over the emphasis element? I know its been depreciated in favor of <em> since it adds emphasis to the media although why cannot CSS3's voice-stress (http://www.w3.org/TR/css3-speech/#voice-stress) property be used on depreciated italic elements? Guess it could be used however I don't see how the italic element can be considered better in any manner.
Edit: Oh wait I see what you are saying, for visual italics without speech emphesis.

Yes typography has to do with how things should appear on the printed page. In typography there are rules for when you should print something in italics or bold and in those instance and only those instances the <i> and <b> tags are actually the correct semantic tags to use since it has to do with typography and not emphesis. Of course if you are not actually discussing typography but using it then you need to consider what the purpose of that particular typographical convention is so that you can apply an appropriate tag that can be rendered as italic for print and dealt with appropriately for other media. As the most common usage is to apply emphesis that makes the <em> tag the most likely tag to use for correct semantic markup.

[Stephen Philbin]

I can't seem to make a whole lot of sense out of most of the posts in the past page and a bit, but it strikes me that a lot of people are (understandably) still having trouble with letting go of the idea that meaning and expression are linked and remembering that the meaning of markup is based on a consensual understanding, rather than a programatical one (The reason why (X)HTML should never be done away with simply because we can custom build one with XML).

[theuedimaster]

Hopefully once the W3C gets all the presentation code that is actually media dependent out of the HTML into the stylesheet they will then be able to consider adding new semantic tags for the types of page content that are currently missing and where we currently need to use <span class=""> because the correct semantic tag doesn't exist.

What are these tags that we need?

[Mr Initial Man]

The <bot> tag, for instance. If you have something utterly idiotic that your superiour INSISTED upon, you put it between <bot>idiocy here</bot>

Boss Ordered This.

it strikes me that a lot of people are (understandably) still having trouble with letting go of the idea that meaning and expression are linked

Please explain what you mean here.

the meaning of markup is based on a consensual understanding, rather than a programatical one

"Programatical"?

[Stephen Philbin]

Please explain what you mean here.

Well as a simple example take the <strong> element. It means that strong emphasis should be placed on the content of the element; however, how this strong emphasis should be expressed is not not defined, nor should it be. You either leave the user agent to attempt to express this meaning in whatever way it has been instructed to do so by default (assuming it has a default), or you can recommend how this meaning should be expressed via a stylesheet.

It's easy to forget the two things are separate because it's human nature to combine the two in our every-day speech and writing. Like if someone says something in anger they may shout, gesture and use facial expressions as an expression of that anger, but the expressions are completely independent of the words being said. The same expressions can be used to accompany endless amounts of other words, and the same words could be accompanied by many different expressions. They are separate, but we tend not to consciously combine them. It's usually more of a conscious effort not to combine them.

Your decision to use <span class="blah"> instead of <q>, much like the use of tables for layout, is a classic example of expression in favour of meaning. It gives a visual expression of the content, but doesn't actually denote the true meaning of what the content is. It reminds me of the old theatre games I used to play: Having to say something without expression and then express without saying.

"Programatical"?

Binaryistic.

[Mr Initial Man]

Your decision to use <span class="blah"> instead of <q>, much like the use of tables for layout, is a classic example of expression in favour of meaning.

Not entirely true, actually. While <q lang="de">Das tut mir leid</q> is more correct than <span class="foreign" lang="de">"Das tut mir leid"</span>, it would not be correct to write, for example, He had a sense of <q class="foreign" lang="de">schadenfreud</q> seeing her in this mess. (the word schadenfreud is not a quote), or He had a sense of <em lang="de" class="foreign">schadenfreud</em> seeing her in this mess. (nor is schadenfreud being emphasized). BUT it would be semantically correct to have, perhaps, He had a sense of <foreign lang="de">schadenfreud</foreign> seeing her in this mess.. The problem, of course, is there is no such tag. Therefore, He had a sense of <span lang="de">schadenfreud</span> seeing her in this mess. will have to do.

My problem with the <q> element, of course, is that its default setting is both undesirable and unreliable. For example, should I use [code=blue]<q class="thought"> </q>[/color], I do not want " ", I want .o0( ). Furthermore, Internet Explorer does not add the quotation marks to this element, but other browsers do. I would like to use a rule such as q:before, q:after{content:"";}, but I am told that is a most undesirable thing to do.

I will have to admit to using a table in a webpage. I tried to use a definition list, but trying to style it to do what I wanted was such misery!

[Stephen Philbin]

...will have to do.

I wouldn't consider it a case of "will have to do". If you're not emphasizing or quoting then I'd say <span lang="de"> would be the most appropriate and accurate markup.

My problem with the <q> element, of course, is that its default setting is both undesirable and unreliable. For example, should I use [code=blue]<q class="thought"> </q>[/color], I do not want " ", I want .o0( ). Furthermore, Internet Explorer does not add the quotation marks to this element, but other browsers do. I would like to use a rule such as q:before, q:after{content:"";}, but I am told that is a most undesirable thing to do.

Well of the two problems you have with the inline quotation element only one is of your own design (and even then, if proper support for the :before and :after pseudoclasses was widespread, it wouldn't be a problem). The first one is the one we all face. I don't worry about it because there's not really anything I can do about it. You can't really expect expect a semantic resolution to your second problem though, because it's a sort of unknown, created punctuation. The only potentially undesirable thing about using the :before and :after pseudoclasses are that they are not well supported. Other than that I'm unaware of any other problems.

I will have to admit to using a table in a webpage. I tried to use a definition list, but trying to style it to do what I wanted was such misery!

Well in previous posts I haven't been referring to you in particular; I was meaning many developers in general. I wasn't even suggesting that you had actually used tables for any page layout either. I was just drawing a parallel between misusing span in place of the inline quote and and already widespread and well-known misuse of markup.

I'm also painfully familiar with the experience of trying to style definition lists. :mad:

[Mr Initial Man]

In the novel I'm writing, much of the <span class="foreign"> marks a fictional language, so I can't even use the lang attribute.

Here's where I used a bit of tabular layout; it's one of those "you can get away with it" situations:
<div class="letter">
<table>
<tr><th>Missive for:</th> <td>Styral Taraynson Kosgan Beers, Bastard Son of the House of Kosgan</td></tr>
<tr><th>From:</th> <td>The Council of T&oelig;skh&acirc;n</td></tr>
<tr><th>Scribed by:</th> <td>Prince Jorald Kh'Naral, Head of the Council of T&oelig;skh&acirc;n and Head of the Elite Warriors</td></tr>

<tr><th>Concerning:</th> <td> The receiver's bid to join the ranks of the Elite Warriors</td></tr>
</table>
<p class="space">While your prowess is indeed satisfactory, your spirit has been matched against the standards of the Elite Warriors and found a poor fit. It is therefore the decision of the Council of T&oelig;skh&acirc;n that you are no longer an Elite Warrior In Training. We discharge you from your training honorably with the understanding that not all are cut out to follow this path. We congratulate you on your prowess, and see no reason you should not continue it, but you are indeed more suited to Markh&aelig;ral alone than the paths of T&oelig;skh&acirc;n.</p>
<p>We wish you all the best.</p>


<p class="space">The Council of T&oelig;skh&acirc;n at the Great Temple of The One Beyond Naming in the Imperial Capital of the Smilodons</p>
</div>

[felgall]

Here's where I used a bit of tabular layout; it's one of those "you can get away with it" situations:

Looks more like a tabular data and therefore should be a table situation and using anything else would be incorrect rather than a get away with it situation.

[Mr Initial Man]

Looks more like a tabular data and therefore should be a table situation and using anything else would be incorrect rather than a get away with it situation.

Including a definition list?

[Stephen Philbin]

I'd say a <dl> would also be appropriate. Just a nightmare to style.

[Mr Initial Man]

One of these days, I'll see if I can't get the <dl> styled the way I want it. ^^

[Stephen Philbin]

Well I tried for two weeks and still couldn't get it to behave. That said, I do suck rather badly with CSS. I just go crying to Dave every time I have a problem. :cool:

[Mr Initial Man]

Maybe negative margins will help. I dunno. I do know I gave up on <dl>s when I tried to view things at a different resolution on my screen. Did you know that relative and absolute positioning don't mix well with line wraps?

[felgall]

To style a dl to put the dt and dd next to one another you float the dt left and give it a width. You then give the dd a margin-left the same size as the width of the dt.

[Mr Initial Man]

Getting them to line up is the fun part. >.<

[bokeh]

Well, isn't the point of getting rid of presentational tags to get rid of code bloat?No, of course it's not! To the typical cowboy coder (http://en.wikipedia.org/wiki/Cowboy_coding) it might be hard to understand but in a professional environment where there is structure and order a system of demarkation is essential. In this type of workplace the designer would be engaged in preparation of the stylesheet but would not have access to the HTML document while the person responsible for the HTML document would not be allowed to add anything the designer cannot modify from the stylesheet. The same idiology is true for the programming and logic sections of a site being separate from the content (Model, View, Controller (http://en.wikipedia.org/wiki/Model-view-controller)).

[Mr Initial Man]

Shows you how much I really know about HTML...

[R Stephan]

Not entirely true, actually. While <q lang="de">Das tut mir leid</q> is more correct than <span class="foreign" lang="de">"Das tut mir leid"</span>, it would not be correct to write, for example, He had a sense of <q class="foreign" lang="de">schadenfreud</q> seeing her in this mess. (the word schadenfreud is not a quote), or He had a sense of <em lang="de" class="foreign">schadenfreud</em> seeing her in this mess. (nor is schadenfreud being emphasized). BUT it would be semantically correct to have, perhaps, He had a sense of <foreign lang="de">schadenfreud</foreign> seeing her in this mess.. The problem, of course, is there is no such tag.
Actually, there is:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-foreign.html

In TEI XML, all rendition issues are deferred into the rend attribute, so you could say <foreign lang='it' rend='italic'>sotto voce</foreign>.

Regards,
ralf

[Mr Initial Man]

Very cool. Wish HTML had that.