The Future of HTML!

[Mr Initial Man]

Most importantly, have a look at the code. ^^

It's a really short page, I know. And it does NOT work in Internet Explorer, because of the CSS.

[knowj]

nice work.

personally I'm not a big fan of the mark up style looks like its making a lot of work for us developers for the same standards which we archiving now by using html/xhtml correctly.

and lets face it. we will be waiting 50 years before Microsoft realise the style had been invented

[Mr Initial Man]

Nah, all they've gotta do is properly support XML and CSS... wait... yeah, 50 years sounds about right.

[d3sc3n7]

Well, I use IE...so I cant see it...I'm sure its nice though...Stupid IE...cant stay with the learning curve

[KDLA]

Interesting....
how much styling can you do with those types of tags? Anything position-related? Or are they simply text-related?

KDLA

[felgall]

I can't see such code ever taking the place of paragraph, list, heading etc tags. There is no point in having a markup language unless it has the necessary tags to say what the content is. Having only one type of element makes the markup language cumbersome to use.

The standards are moving toward making web page creation easier rather than harder so that is more a 1960s style of markup rather than 2060.

[Mr Initial Man]

KDLA: Probably, all I'd need to do was write the CSS for it.

felgall: My point was that--from my point of view, anyways--XHTML 2.0's simplification of the tag list was making the markup language more cumbersome, forcing us to use the "class" attribute more and more, rather than using the older inline presentational tags which we could then style to our heart's content.

This language is SUPPOSED to be cumbersome; there's this little thing called satire...

[KDLA]

Originally Posted by Mr Initial Man

KDLA: Probably, all I'd need to do was write the CSS for it.

Duh.
I think it's cool. I was curious as to how you'd position all that without CSS classes and/or ids. like:
<element role="container">a;slkdfjlskj</element>
where "container" knows to pad the area 10px or something without a CSS setting -- perhaps a default setting interpreted by the browser by the doctype you created.

[Mr Initial Man]

Ah. I'd have the css rule read like [role="container"]{padding:10px;} That's why it doesn't work in IE.

[felgall]

Originally Posted by Mr Initial Man

felgall: My point was that--from my point of view, anyways--XHTML 2.0's simplification of the tag list was making the markup language more cumbersome, forcing us to use the "class" attribute more and more, rather than using the older inline presentational tags which we could then style to our heart's content.

This language is SUPPOSED to be cumbersome; there's this little thing called satire...

The point that I was trying to make is that the way that the W3C is changing the XHTML standards is the EXACT OPPOSITE of the cumbersome way that you have demonstrated there. Everything that relates to how the page sounds when it is read out or how it looks when it is displayed is moved out of the HTML in order to make the HTML less cumbersome and more device independent. XHTML 2.0 is definitely a lot less cumbersome than any of the (X)HTML versions that have preceeded it BECAUSE it removes all of the presentational tags and attributes that never belonged there in the first place.

[Mr Initial Man]

The point I was trying to make here is that, to be honest, I find stuff like <i>, and <b> to be a lot less cumbersome than <span class="italic"> and <span class="bold">. They're presentational, but I use them when <em> and <strong> are not really good options. Not only that, but I'm watching a lot of other tags (such as <a> and <img>) hit the dumpster as well, and those were HARDLY presentational. So I'm looking at this trend and wondering "Okay, what's next? A reduction of all body tags to <div> and <span>? Or even taking things to the extreme I did?" After all, <span> and <div> do have something to do with the way the page is displayed or sounds. You see what I'm getting at?

[felgall]

How does a web reader speak in bold and italic? Go on say something in bold the way you expect the web reader to say it when reading out your page to a blind person.

<p> <div> <li> <h> etc have nothing to do with how the content looks or sounds, they have to do with what the contents are.

[slaughters]

Originally Posted by felgall

...Everything that relates to how the page sounds when it is read out or how it looks when it is displayed is moved out of the HTML....

That is *exactly* what "Mr Initial Man" demonstrated. Everything relating to how it looks was removed from the HTML. CSS was used for all presentational formatting.

From what I've seen the w3c is going in the EXACT SAME DIRECTION of the cumbersome way that he has demonstrated.

It's not easier to develop code with this standard - it's just easier to re-use code.

I understood the satire of the posted page almost immediately

[edit]
"How does a web reader speak in bold and italic?" - what silly comment.

If it does not understand a tag a web reader would ignore it, or use approximations using a stronger voice emphasis or modify the timing.

I mean - how does a web reader speak "paragraph" - it is a visual break in a page. How does it speak "<ul>", "<li>" - once again, visual ordering of information on a page.
[/edit]

[Mr Initial Man]

Slaughters has put his finger precisely on what I was trying to say with this page. EVERYTHING on how this page is displayed is dependant on CSS, precisely as the W3C has tried to do. <element>, in and of itself, does nothing. CSS takes the attribute [role], and decides "is this instant going to be bold, italic, superscript, or normal? Will it be even inline or block?" (Still working on how to turn something into a list or page title.)

It seems that the W3C is working on ridding all elements of what they traditionally do, passing the "doing" onto CSS. This is simply the end point of their trend:<element> does nothing, CSS does it all.

[felgall]

A paragraph is presented in different ways depending on whether it is written or spoken. people know what a paragraph is even if they don't see or hear it. A paragraph is what something is and that is what HTML was intended for in the first place - to identify what the parts of the contents are such as paragraphs. The HTML is meant to indicate what the parts of the content are and so elements such as paragraphs will not be replaced in HTML.

It really looks like you don't understand the difference between what (HTML) and how (CSS) well enough if you are proposing that both be removed from HTML when the idea is only to remove how and leave what alone.

A paragraph is still a paragraph even if it isn't spoken or read but is just stored as magnetic impulses on a hard drive.