×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

W3C Considering An HTML 5

Zonk posted more than 5 years ago | from the party-like-its-1999 dept.

Software 414

An anonymous reader writes "When the decision was initially made to move in the direction of XHTML, instead of a new version of HTML proper, it seemed like a good idea. Years later and the widespread adoption of CSS (among other things) has proven that things don't always develop the way we expect. As a result, HTML 5 has been revived by the W3C. After some lobbying and continued work by the Web Hypertext Application Technology Working Group, the old web markup language is getting an official face-lift. A post to the Webforefront blog explains the history behind the initial decision to move to XHTML, and why things are so different in the here and now."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

414 comments

Absolutely right (5, Insightful)

jimicus (737525) | more than 5 years ago | (#19925565)

Because what the world really needs right now is another version of a web standard which has had hardly any full, correct implementations in any version that's ever existed.

Or are the W3C just trying to justify their existence?

Re:Absolutely right (4, Funny)

Valacosa (863657) | more than 5 years ago | (#19925601)

Because this time people will code to it, dammit.

Re:Absolutely right (3, Insightful)

arivanov (12034) | more than 5 years ago | (#19925729)

Yeah, right.

That shall be coding to a standard defined by a vendor infested committee where each representative has been obsessed to ensure that all of their bugs are standardised as "this is not a bug, it is a feature".

As a result the implementations will remain as quirky as they are now. At best. At worst...

Re:Absolutely right (3, Funny)

fbjon (692006) | more than 5 years ago | (#19926477)

You jest, but it is actually that simple. HTML 5.0 = HTML 4 with some new sugar + XHTML parser strictness.


The result is that browsers will show you the finger if you don't code to the standard.

Re:Absolutely right (5, Interesting)

tolan-b (230077) | more than 5 years ago | (#19925615)

Actually HTML5 is largely a result of work by the main browser makers, except Microsoft I believe. Hixie from Opera is the project lead of the WhatWG which was created to extend HTML to make it more applicable for web applications. It fixes a lot of the problems with both HTML 4 and XHTML, and its backwards compatible with *both*.

Re:Absolutely right (0, Flamebait)

suv4x4 (956391) | more than 5 years ago | (#19926083)

Actually HTML5 is largely a result of work by the main browser makers, except Microsoft I believe. Hixie from Opera is the project lead of the WhatWG which was created to extend HTML to make it more applicable for web applications. It fixes a lot of the problems with both HTML 4 and XHTML, and its backwards compatible with *both*.

This is not the HTML5 W3C is talking about. They want to make their own. And just like XHTML1.1 and especially XHTML2, I suspect it'll be largely bullshit.

Microsoft is working on XHTML support in IE8 now, and right at this point W3C comes out and says "ok XHTML wasn't exactly what we needed". Idiotic.

Now that we know W3C doesn't know what they're doing (or what we're doing), maybe we can finally see a better push of the set of technologies in WHATWG's HTML5. It's actually a pretty neat standard and a proper superset of HTML4, adding stuff we sorely missed since the web came into being.

You see, W3C is about "semantics and clean code" to aid computer based search. Google says they don't know what they're doing. I'd trust the search engine vendor to know better. WHATWG is about practical solutions to existing problems, without throwing away what we already have.

Re:Absolutely right (3, Informative)

tolan-b (230077) | more than 5 years ago | (#19926125)

No you're wrong I'm afraid, the HTML5 that W3C is talking about *is* based on WhatWG's HTML5. It supports HTML and XHTML syntaxes to the the same serialisation, so MS supporting XHTML isnt' wasted. They're basically merging HTML and XHTML.

Re:Absolutely right (2, Interesting)

suv4x4 (956391) | more than 5 years ago | (#19926271)

No you're wrong I'm afraid, the HTML5 that W3C is talking about *is* based on WhatWG's HTML5.

It's written "WHATWG" by the way, for the same reason you don't write UspTo. But that's not important.

WHATWG are the group that pitched W3C to consider HTML5. W3C's HTML5 isn't based on anything right now since it doesn't exist yet. It may include in some form some HTML5 features, but don't delude yourself that W3C will beat the heck out of it, until it's a tortured mix of their XHTML2 standard and WHATWG's HTML5.

Re:Absolutely right (5, Informative)

AKAImBatman (238306) | more than 5 years ago | (#19926239)

Who modded this informative? Suv4x4 is incorrect. The W3C came up with their HTML5 standard by taking a dump of the WHATWG HTML5 standard and putting the W3C colors on it. Which isn't surprising as most of the WHATWG members are also W3C members. It was always their intention to make their standard more "legitimate" by submitting it to the W3C once it was ready.

Don't believe me? Here are the two standards. Compare:

WHATWG HTML5 [whatwg.org]
W3C HTML5 [w3.org]

Save for some slight divergences as the WHATWG's standard is updated, they're exactly the same.

Re:Absolutely right (1)

nlogax (709388) | more than 5 years ago | (#19926359)

The W3C came up with their HTML5 standard by taking a dump of the WHATWG HTML5 standard and putting the W3C colors on it.

I misread that as taking a dump on , which made your post both very confusing, and amusing.

Re:Absolutely right (1, Insightful)

Anonymous Coward | more than 5 years ago | (#19926285)

The only problem XHTML has is that it takes effort -- specifically effort to port invalid HTML code. The more invalid the HTML is, the more effort it takes to port it to XHTML. Multiply this by the size of your website.

Otherwise, in my experience, XHTML is definitely the more correct, optimum, eventual solution. I can't imagine how (in programming at least) ambiguity can be more desirable than clean-cut standards.

Re:Absolutely right (5, Insightful)

WED Fan (911325) | more than 5 years ago | (#19926517)

Actually HTML5 is largely a result of work by the main browser makers, except Microsoft I believe. Hixie from Opera is the project lead of the WhatWG which was created to extend HTML to make it more applicable for web applications. It fixes a lot of the problems with both HTML 4 and XHTML, and its backwards compatible with *both*.

Excuse me, but it must be pointed out.

When you start talking standards and you gather a group of browser/client makers to discuss new standards, you really do need to have the giant on the block represented. Otherwise, you get a set of standards that run the real possibility of being ignored, or worse, supplanted by the giant's idea.

When the combined numbers of the "others" don't even come close to trumping the giant's numbers, you are heading to failure. In this case MS, like it or not, is the giant. The easiest way to stop this crazy, "IE only partially implements html x.0/css x.1/xhtml x.x" crap is to involve them.

Of course, this is just crazy talk, right. Oh heavens, we might actually run into the problem of MS taking over the standard. You know what, when you have a formation marching down the street, and 70% are on one heel beat, and the other 30% are out of step with the 70% and aren't even in step with themselves, its the 30% that need to get with the beat.

Failure to accept this is only going to widen the gulf, unless MS, through largesse or coincidence follows the new standard.

Re:Absolutely right (1)

Lumpy (12016) | more than 5 years ago | (#19925673)

Short answer. YES

Long answer. Wc3 is made up of many different represenatives of different companies.

If you could force all those damned scumbags that are still using the old Dreamweaver 8 (2004MX)..

Ohhh how dare they use a old version of our apps that makes prefectly good HTML! DAMN THEM!

as well as force adoption of new software all across the board as HTML changes force upgrades.

Re:Absolutely right (2, Interesting)

ronadams (987516) | more than 5 years ago | (#19925751)

  1. It's made of many people, period. Some of them do not work for any tech firms.
  2. If the primary (or even subsidiary) interest in updating standards was to sell more copies of Dreamweaver and other similar products, then why would there be free updates to Dreamweaver extensions to reflect standards changes? Also, the majority of the industry is not coding in Dreamweaver, so there's no chokehold on the business here.
  3. Sorry, no point-and-click HTML generator makes "perfectly good HTML". Many do a decent job, but it will never be as efficient as straight code and thorough knowledge of the standards.
In closing, if the W3C's purpose was to bolster commercial software sales, they sure are going about it in the most ineffective way possible.

Re:Absolutely right (2, Funny)

Captain Splendid (673276) | more than 5 years ago | (#19926255)

if the W3C's purpose was to bolster commercial software sales, they sure are going about it in the most ineffective way possible.

I dunno, I sure have bought a lot of copies of Notepad in the last ten years!

Re:Absolutely right (1)

vigmeister (1112659) | more than 5 years ago | (#19925787)

I am sure it does not make a difference at all, but at Georgia Tech, we used to have our students make a website as a 1% assignment in the course. Up until around 2006, we used to have them ensure W3C compliance. Afterwards, we just said it must work with any web browser that their TA may choose to use and that W3C was a good way to ensure that. I've met many a web designer who would be stumped for a few seconds if I ever asked them "Is ... W3C compliant?" as if they were evaluating then and there if it was and then would say "I'm not sure". And these guys make wonderful pages which work on most browsers!

Cheers!

Re:Absolutely right (4, Informative)

AKAImBatman (238306) | more than 5 years ago | (#19926079)

Or are the W3C just trying to justify their existence?

That's a bit cynical, don't you think?

HTML5 is the result of the hard work done by the Web Hypertext Application Technology Working Group [whatwg.org] (WHATWG). The WHATWG is composed of members from all browser makers, with the occasional public comment thrown in for good measure. As a result, the group has been removing or reducing the ambiguity about implementing the various standards (especially the parser!) and have added features that bring HTML up to a true application platform. Their work is represented in web browsers every time someone uses the Canvas tag, Audio object, Storage API, and other modern features.

The WHATWG was formed because the W3C was seen as too slow to execute such new technologies. Now that the WHATWG specs are stablizing, the W3C has taken a dump of the WHATWG HTML 5 standard and proposed it for ratification under W3C bylaws. This has several advantages over the WHATWG standardization, not the least of which is extracting patent waivers from companies like Apple who technically "own" some of the technologies behind the WHATWG standards.

Note that the HTML5 group at the W3C is a bit different from most. In an attempt to remain as open as the WHATWG, they are accepting just about anyone as an "invited expert" to provide input and comments on the standards process. This is a huge departure from the way that most W3C standards are handled, and is probably a good choice for a standard as comprehensive and complex as HTML5.

Re:Absolutely right (2, Interesting)

TheRaven64 (641858) | more than 5 years ago | (#19926113)

Some of the WHAT-WG's proposals for HTML5 look fun. The canvas tag (originally from Mozilla, I believe, but now in WebKit and Opera) lets you draw bitmap images via the DOM, but my favourite is client-side storage. This lets you store several KB of data locally, enough for simple documents in a number of formats.

Re:Absolutely right (4, Interesting)

AKAImBatman (238306) | more than 5 years ago | (#19926195)

The canvas tag (originally from Mozilla, I believe, but now in WebKit and Opera)

Actually, it was originally from Apple Safari. Apple invented it for their desktop widget thingys. Opera and Mozilla have both embraced it with open arms. :)

my favourite is client-side storage.

I agree. I absolutely love this feature! Unfortunately, it's only implemented by Firefox at the moment. I was hoping that it would show up in Safari 3.0 so that richer iPhone applications could be written, but it was not to be. The feature request [webkit.org] is still sitting out there with no assigned implementer. I'm tempted to dive into Webkit and maybe see if I can add it.

This one always amuses me.. (1)

Xiph (723935) | more than 5 years ago | (#19925579)

And yet another reason was that HTML was based on the older and more immense SGML language, where as XHTML was to be based on XML, which provided a more simplified rework of SGML.
It appears [coverpages.org] the author doesn't know that xml is a subset of sgml

The Author is Not Completely Wrong (4, Informative)

ronadams (987516) | more than 5 years ago | (#19925629)

There was an interesting discussion about this in the xml-dev mailing list [xml.org]. Rick Jelliffe had this to say:

XML was developed as a subset of SGML. Most of the ISO working group which looked after SGML were also involved with the creation of XML (Clark, Kimber, Bosak, also Goldfarb, Peterson, me, and others). The correction for SGML came out before XML was finally put as a recommendation (AFAIR) so there never was a time when XML was not a true subset of SGML. Where there were differences, ISO8879 was corrected specifically to make sure that XML was indeed a subset. In fact, Charles Goldfarb even said at one stage "XML *is* the revision of SGML" (debate on the revision of ISO 8879 had started years before: XML was the embodyment of that).
XML can be argued as both the revision to and a subset of SGML. Hence my disappointment in anything new that seems to shy away from this path, like HTML 5 instead of XHTML.

Re:The Author is Not Completely Wrong (5, Informative)

tolan-b (230077) | more than 5 years ago | (#19925713)

HTML 5 is also 'XHTML 5'. You can use well-formed XHTML style syntax, and deliver it with an application/xml or application/xhtml+xml mimetype, *or* you can format it HTML style and deliver it with a standard HTML mimetype.

http://blog.whatwg.org/html-vs-xhtml [whatwg.org]

Re:The Author is Not Completely Wrong (2, Interesting)

ronadams (987516) | more than 5 years ago | (#19925807)

Intersting! That makes me a bit more hopeful for the standard. The whole idea is to move towards the "semantic web": say what you want, and render it in the most accessible ways possible. More and more sites and services are being presented in both a standard and mobile format, as well as several handicapped-accessible formats. More choices is a good thing.

What I'm not seeing (perhaps because I haven't read the standard yet, or thought it through enough) is what HTML brings to the table that XHTML can't. Why bother with allowing the HTML mimetype, if it has no advantages other than it's what was done in the past?

Re:The Author is Not Completely Wrong (1)

TapeCutter (624760) | more than 5 years ago | (#19926523)

"Why bother with allowing the HTML mimetype, if it has no advantages other than it's what was done in the past?"

Because what was done in the past will be installed next Friday.

Re:This one always amuses me.. (1)

$1uck (710826) | more than 5 years ago | (#19925687)

I have the joy of working with both (SGML in the Airforce and XML in the army). It was always my understanding that XML was inspired by SGML but it is NOT a subset/sgml standard (HTML is). Xml documents do not require DTD to be valid. I thought SGML did (its been a long time, I think you might be able to specify the dtd inside the sgml document, but you still needed it).

Regress is the New Standard for Progress (4, Insightful)

ronadams (987516) | more than 5 years ago | (#19925595)

TFA makes several great points about how this seeming sentiment of "we'll stick with the HTML we know and love" is more an unwillingness to change than it is to update a standard. The whole idea of XHTML was to provide a segueway into an altogether new way of distributing content. This really seems a regression more than anything. What does XHTML fail to deliver that would cause WC3 to shy away from the previously hardline (and appropriate, IMHO) stance of "this is the new HTML, get used to it"?

Re:Regress is the New Standard for Progress (-1, Troll)

Anonymous Coward | more than 5 years ago | (#19925637)

this seeming sentiment of "we'll stick with the HTML we know and love" is more an unwillingness to change than it is to update a standard. The whole idea of XHTML was to provide a segueway into an altogether new way of distributing content. This really seems a regression more than anything.
Oh my goodness! The irony is rich here boys.

Re:Regress is the New Standard for Progress (1)

Threni (635302) | more than 5 years ago | (#19925645)

Precisely. Are the W3C just bored, or does this solve problems that XHTML can't/causes?

Don't you need power to be hardline? (3, Insightful)

JordanL (886154) | more than 5 years ago | (#19925677)

What does XHTML fail to deliver that would cause WC3 to shy away from the previously hardline (and appropriate, IMHO) stance of "this is the new HTML, get used to it"?
First, having reviewed some of the things in the draft HTML5 standard Opera and Apple have been working on, I have to say that it is indeed worth standardizing.

Second, I wonder about this "hardline" approach. Who made the W3C gods of the internet? I mean, things need to be standardized, but they refused to do their job and standardize, and guess what, the industry got together and made another standardization board which was mentioned in the OP. The W3C can't hardline anything... they just format the direction we're going... they don't choose it, the industry does that.

Go ahead, think I'm wrong, think the W3C should just stick it to all those web developers and browser companies that have spent years working around the group that is supposed to make their lives easier. The W3C is a paper tiger... they are completely at the mercy of everyone else. They can't hardline anything, much less something which was being standardized without them anyway.

Re:Don't you need power to be hardline? (1)

Nimey (114278) | more than 5 years ago | (#19925883)

Second, I wonder about this "hardline" approach.


Yeah, because gods know that we need to have more Web pages that are best viewed with the writer's favorite web browser.

If I want to look at someone's page with elinks, the page should work fine. Ditto if I want to use Konqueror or Opera.

Re:Regress is the New Standard for Progress (4, Insightful)

Anonymous Coward | more than 5 years ago | (#19925721)

Ill tell you why web developers do not adopt XHTML, its not because of reluctance to change, its because XHTML OFFERS NO BENEFITS TO HTML 4.

Why would anyone in their right mind spend time updating from HTML 4 to XHTML 1.1 when there is no visible benefit and a LOT of pain.

HTML 5 FINALLY introduces features that web developers NEED. Things like native client side validation, canvas and menu elements. These are things that we have been crying out for years but W3C disappeared up their own self-validating a**es. If they had introduced these features into XHTML then I am sure it would have been adopted by browsers and developers alike.

The lack of support from a certain vendor would not have mattered because they would have been pressurized into supporting the standard by the >10% share of browsers that would support it.

P.S. Posting in good 'ol plain text :)

Re:Regress is the New Standard for Progress (1)

TheSunborn (68004) | more than 5 years ago | (#19925867)

The reason might also be that Neither IE6 nor IE7 can really show xhtml, and insted treat it either as 'tag soup' or a tree, depending on your content-type header

Re:Regress is the New Standard for Progress (1, Insightful)

Anonymous Coward | more than 5 years ago | (#19925935)

There may be some truth to this, but what if it did? What are the benefits? As TFA suggests there are no real-world benefits to using XHTML. That is starting from a new project. The incentive to change an existing site is negative.

XHTML needed a 'killer tag', but it was just a lame extension to HTML 4. If they had provided these features then it would have been accepted (I think its clear now the industry does not accept XHTML).

No, XForms do not count, the key is backwards compatibility.

Re:Regress is the New Standard for Progress (2, Insightful)

LingNoi (1066278) | more than 5 years ago | (#19926571)

Things like native client side validation, canvas and menu elements. These are things that we have been crying out for years but W3C disappeared up their own self-validating a**es.


Even with client side validation you would still have to validate it server side anyway unless you are a crap developer.

I would rather have xhtml then go back to the mess that html was with its styling embedding directly into the tags and I know that if its allowed its going to happen. Some day I am going to get the tag soup code from the developer working with me, I can feel it.

Give me clean code and forced usage of CSS any day.

hmm. (3, Interesting)

apodyopsis (1048476) | more than 5 years ago | (#19925609)

are they going to enforce all the current browsers to support it fully and correctly as well?

or will some browsers go their own way with "extensions" and "implementations" specific to their own system like last time.

Re:hmm. (2, Funny)

ronadams (987516) | more than 5 years ago | (#19925685)

are they going to enforce all the current browsers to support it fully and correctly as well? or will some browsers go their own way with "extensions" and "implementations" specific to their own system like every time.
Fixed.

No, the W3C has no authority or ability to enforce it. Browsers will do what they do. Hopefully, what they do is at least in the general neighborhood of the standards. Rules were made to be broken, and Web Standards were made to be bastardized by incompatible browsers.

Re:hmm. (1)

LiquidCoooled (634315) | more than 5 years ago | (#19925981)

I saw a glimmer of hope from the worst offender recently.
Is Microsoft learning from Web standards mistakes? [zdnetasia.com]

Re:hmm. (1, Troll)

quanticle (843097) | more than 5 years ago | (#19926189)

Words are cheap. If you look at IE 7 you'll see that its not much more standards compliant than IE 6. In fact, it could be argued that its even less standards compliant, because it breaks with the de facto IE 6 standard.

Re:hmm. (1)

AKAImBatman (238306) | more than 5 years ago | (#19926575)

Amen. Microsoft can talk when they at least have DOM 2 implemented. Until then, their promises of "standards compliance" are nothing more than an insult to the development community at large.

Re:hmm. (0)

Anonymous Coward | more than 5 years ago | (#19925863)

Most of HTML5 was a collaboration between the folks behind mozilla, opera, and safari (you know the browsers that already try to find standards). Everyone knows that extensions are a bad idea at this point without standardization so I would guess that everyone (except MS) would be willing to play along. The forms section itself actually sounds really awesome.

Cry for relevency (3, Insightful)

palladiate (1018086) | more than 5 years ago | (#19925633)

They can't let HTML die. The W3C would become irrelevant quickly if they stopped tweaking the language. Finally, even nomral users and web surfers have started to use HTML in web forums and MySpace (to usually garish effect, but still. XHTML just doesn't have the portability and ease of use that HTML did for things like forums.

Take Fark for instance. After years and years, a critical mass of people are finally learning a, b, u, i, big, super, img, and other standard tags, most of which just don't work the same or at all under XHTML.

Sadly, many useful old tags probably won't work in HTML 5, or not in any useful fashion. The W3C will most certainly mess with the language to bring it in line with XHTML conventions. They've already taken target="_blank" from us, what other useful gizmos are they going to futz with this time, bookmarks? You can pry my octothorpe from my cold, carpel-tunnel hands.

Sure, CSS is damn useful and nobody generally liked frames. However, everything else about HTML was fine circa 1995. Maybe I'm being an old codger who still writes HTML pages without fancy crap like Frontpage, but I'm getting tired of their self-important crap. Breaking useful conventions just makes trying to communicate on the web that much harder. But, every time I tag font or add target="_blank", I do think about the W3C. Maybe that was just their goal all along.

Re:Cry for relevency (1, Insightful)

Anonymous Coward | more than 5 years ago | (#19925857)

They can't let HTML die. The W3C would become irrelevant quickly if they stopped tweaking the language. Finally, even nomral[sic] users and web surfers have started to use HTML in web forums and MySpace (to usually garish effect, but still.
No one said HTML was dieing, you can always use a different doctype and the browser will compensate. That's why you are supposed to always declare one at the top of every page. No one is FORCING you to use any specific doctype.

XHTML just doesn't have the portability and ease of use that HTML did for things like forums.
Do you even know what you are talking about? You can still use all your forms as you did before, the only thing that changed is adding a / on a single line element and make sure you use all lowercase. Whoppdeefreakindoo! Again, this is completely irrelevant if you declare an older doctype. If you think that because you are using XHTML you can't use tables, you are mistaken. You are not required to conform to the WAI and WCAG, however for those with disabilities do appreciate it.

Take Fark for instance. After years and years, a critical mass of people are finally learning a, b, u, i, big, super, img, and other standard tags, most of which just don't work the same or at all under XHTML.
Or /. for that matter, yes most people don't pay attention to these things. In fact most people still use the font tag. But then again, so long as they declare the appropriate doctype its PERFECTLY OK TO DO!

Sure, CSS is damn useful and nobody generally liked frames. However, everything else about HTML was fine circa 1995. Maybe I'm being an old codger who still writes HTML pages without fancy crap like Frontpage, but I'm getting tired of their self-important crap. Breaking useful conventions just makes trying to communicate on the web that much harder. But, every time I tag font or add target="_blank", I do think about the W3C. Maybe that was just their goal all along.
Who says you need to use anything but notepad, vi, or emacs to create CSS or HTML? And as far as the self-important crap, WTF!?! These standards are for increased accessibility or are you completely obliviously to the meaning of self-important?

I hate ACs (0)

palladiate (1018086) | more than 5 years ago | (#19925983)

No one said HTML was dieing, you can always use a different doctype and the browser will compensate.

Umm, the definition of a "dead" language is one that is no longer changing. Pascal is "dead" but may people can still program in it. Heck, C is "dead" but commonly used. But, nobody really needs a C working group to address changes to the language. That's what the W3C is, a group that pushes the direction of the evolution of HTML.

Without changing the language, they no longer need to exist.

In fact most people still use the font tag.

Indeed they do, but in 10 years if every web board declares XHTML strict convention, there's plenty of handy stuff that no longer works, and has no replacement. So, you now have a giant class of web developers that are not going to adopt those changes, and as such go against W3C recommendations. If the W3C doesn't make useful recommendations, they become annoying. Some of us will follow their guidelines, some will ignore them. They aren't standardizing us, which is their job, they are just keeping themselves relevant.

Re:I hate ACs (0)

Anonymous Coward | more than 5 years ago | (#19926259)

Without changing the language, they no longer need to exist.
Hrmm... going by your definition, after 1999 we no longer needed html 4.01 to exist since it hasn't changed since then [w3.org]. RTFA, HTML5 is a new version of xhtml 1.1 as well as html 4.01 [w3.org].

So, you now have a giant class of web developers that are not going to adopt those changes, and as such go against W3C recommendations. If the W3C doesn't make useful recommendations, they become annoying. Some of us will follow their guidelines, some will ignore them. They aren't standardizing us, which is their job, they are just keeping themselves relevant.
Maybe you should RTFA and comply with the rules of the language since it's your job when you develop a webpage. It's not their job to standardize us, it's their job to standardize the language. Last time I checked it wasn't Sun's fault for making crappy java developers.

I still hate you (1)

palladiate (1018086) | more than 5 years ago | (#19926387)

...we no longer needed html 4.01 to exist...

No, I'm saying it doesn't change. Latin is dead too, that doesn't mean it isn't used regularly. It just means that the language no longer changes, and meets the needs of it's users. I'm saying HTML may just not need to change, as it seems to be meeting our needs. The W3C's

Sign up for an account.

Re:I still hate you (1)

palladiate (1018086) | more than 5 years ago | (#19926413)

?! That sentence ended in preview. The W3C is threatening to do what all powerful groups do after a while: make changes to stay relevant.

Re:Cry for relevency (1)

pete-classic (75983) | more than 5 years ago | (#19925937)

It would be trivial to have forum users post their comments with some simplified markup, (like: [b]wow![/b]) and then convert that to something that works with your site's stylesheet on the server side. You gain multiple advantages, and the entire freaking WWW doesn't have to be stuck in the '90s.

Also, every line of my personal website (including the PHP and multiple style sheets) was written in GNU nano and debugged with Firefox and the W3C XHTML and CSS validators. Frontpage was not required!

-Peter

Re:Cry for relevency (1)

palladiate (1018086) | more than 5 years ago | (#19926333)

I do like your suggestion, and yes, that does solve the problem of XHTML. However, I'm going to take issue with this:

It would be trivial to have forum users post their comments with some simplified markup, (like: [b]wow![/b]) and then convert that to something that works with your site's stylesheet on the server side.

That just creates thousands of different implementations of web style languages. The W3C was formed to help steer standards. I find it quite ironic that their method of standardization leaves us with a less standard web. Remember, most activity on the web comes from user-generated content, and hopefully most tagging in the future would be done ON websites, not IN websites. Why should we, as web developers, get the lions share of simplicity, and users get the shaft in usability? Aren't we creating these sites for the user, and their ease of use?

Private implementations of markup scare the shit out of me. If the W3C can't move without making the web less standard, they need to congratulate them selves on a job well done and go home.

Re:Cry for relevency (4, Informative)

HappyHead (11389) | more than 5 years ago | (#19925945)

After years and years, a critical mass of people are finally learning a, b, u, i, big, super, img, and other standard tags, most of which just don't work the same or at all under XHTML.

Um, what? Seriously, the b, u, i and big tags are _exactly the same_ in XHTML. There was never a super element in HTML 4, it's just sup, and it's unchanged. The a tag does everything from HTML 4 the same way in XHTML. The only difference in it is that it's allowed extra attributes.

Out of all of those things, the only one that's changed at all is the img tag, and that's only in two places - first, in XHTML you are required to provide an alt= attribute (instead of just strongly recommended like in HTML 4), and second, you have to close the tag properly, with a /> at the end.

Frames are also still part of the XHTML spec.

The font tag however, is gone and won't be missed any more than the blink tag was, by anyone other than frontpage (which absolutely loves adding thirty or so font tags in a row setting and unsetting the color 'white' from the text.

Re:Cry for relevency (1)

palladiate (1018086) | more than 5 years ago | (#19926253)

The a tag does everything from HTML 4 the same way in XHTML.

Well, there is also that problem with taking away a few attributes, like the target I mentioned. I can provide a list if you like. My point isn't that things are broken yet, just that the W3C will likely pull crap to remain relevant. XHTML just doesn't seem to provide everything some people need, and thus the reason for the continued use of HTML.

Frames are also still part of the XHTML spec.

Yes, in the frames spec, not strict. But, as I said, nobody liked it anyway.

Seriously, the b, u, i and big tags are _exactly the same_ in XHTML. There was never a super element in HTML 4, it's just sup, and it's unchanged.

I know, I'm asking what will change in the future. I don't think XHTML is necessarily a bad thing either, as it's part of a larger standard, and required many changes. However, I don't like them removing perfectly good functionality for reasons of "We don't find it aesthetic."

And I know, it's sup and sub, but since I use them about twice a decade, forgive me for forgetting. I defer to your obviously superior HTML skills. You win the day again, Captain Ad Hominem Tu Quoque! I shall not make a mistake next time!

The font tag however, is gone and won't be missed...

Untrue. Those of us who use HTML enabled web forums rely on font sometimes. Sure, you can do some ugly, crazy stuff with it. However, let me decide how my presentation should look. Sure CSS is wonderful if I'm writing web pages, because I want to enforce a standard look. However, person to person communication sometimes benefits from a finer grain of control. Font can give us that. Target gives us that. That means HTML will still be used in the future.

Until the W3C can enforce websites filling more than 10% of my 24" screen and scale beyond 640x480, prevent idiots from using painful color schemes, or non-intrusive placement of ads, they need to stop making my job of communicating over the web harder, less standard, more fragmented, and less useful. The biggest benefit from their bloviating recently has been with keeping themselves relevent, not useful.

Re:Cry for relevency (3, Insightful)

Derek Pomery (2028) | more than 5 years ago | (#19926655)

The only advantage font gives over using the style attribute (which gives far greater control) is that forum text sometimes disables CSS due to security concerns.
This can be solved with moderately smarter CSS munging (whitelist the font-* stuff) or simply not allowing your users to use HTML in form posts in the first place - use bbcode instead.
That can be munged by the server however it wants.

Rest of what you were saying was kinda silly so I just focused on the one legitimate one.

Oh, and target="_blank" - that's fair. The only alternative is javascript, which often is no alternative at all. On the other hand, I do find that target bloody annoying. Let me decide if I want to open a link in a new window, dammit. I'm not exactly sorry it is gone.

Re:Cry for relevency (1)

Steve001 (955086) | more than 5 years ago | (#19926101)

palladiate wrote:

They can't let HTML die. The W3C would become irrelevant quickly if they stopped tweaking the language. Finally, even nomral users and web surfers have started to use HTML in web forums and MySpace (to usually garish effect, but still. XHTML just doesn't have the portability and ease of use that HTML did for things like forums.

I think a reason that XHTML has not taken off is due to its unforgiving strictness. From what I understand, if you make a single mistake in XHTML the page will not work and for that reason it is not intended to be handwritten. But with HTML you often have different ways of achieving the same effect, such as with centering.

Take Fark for instance. After years and years, a critical mass of people are finally learning a, b, u, i, big, super, img, and other standard tags, most of which just don't work the same or at all under XHTML.

This is the reason for the continuing appeal of HTML: its simplicity. My understanding that XHTML requires is that document formatting be separate from the content of the document. Yet sometimes is so much simpler to use a CENTER tag versus having to mark a section of text with a customized tag and then go into a style sheet to center a single section of text.

Sadly, many useful old tags probably won't work in HTML 5, or not in any useful fashion. The W3C will most certainly mess with the language to bring it in line with XHTML conventions. They've already taken target="_blank" from us, what other useful gizmos are they going to futz with this time, bookmarks? You can pry my octothorpe from my cold, carpel-tunnel hands.

Sure, CSS is damn useful and nobody generally liked frames. However, everything else about HTML was fine circa 1995. Maybe I'm being an old codger who still writes HTML pages without fancy crap like Frontpage, but I'm getting tired of their self-important crap. Breaking useful conventions just makes trying to communicate on the web that much harder. But, every time I tag font or add target="_blank", I do think about the W3C. Maybe that was just their goal all along.

I think what the only way that HTML 5 will succeed is if it continues to allow the use of "depreciated" tags as an option as a recognized part of the standard. It seems like the often the simple-but-works is being tossed away for the complex.

Maybe what is needed are two different forms of HTML. One form would be a basic HTML with the commonly used tags (and designed for easy hand coding), and the second would be a high-level version that is considered "current" (and more appropriate for use of a webpage making tool). Since web browsers already have to handle so many version of HTML, doing this should not be difficult.

Re:Cry for relevency (3, Informative)

mikael_j (106439) | more than 5 years ago | (#19926493)

I think a reason that XHTML has not taken off is due to its unforgiving strictness. From what I understand, if you make a single mistake in XHTML the page will not work and for that reason it is not intended to be handwritten. But with HTML you often have different ways of achieving the same effect, such as with centering.

Actually, one of the reason many people have picked up on XHTML is because it's a lot "cleaner" than "good" ol' HTML 4, the strict rules are one of the reasons for this, in XHTML you're not allowed to do stupid shit like "<i>foo and <b>bar</i> are both words</b>". And writing XHTML by hand is much easier than relying on some horrible WYSIWYG tool's generated code.

This is the reason for the continuing appeal of HTML: its simplicity. My understanding that XHTML requires is that document formatting be separate from the content of the document. Yet sometimes is so much simpler to use a CENTER tag versus having to mark a section of text with a customized tag and then go into a style sheet to center a single section of text.

Actually, formatting should be kept separate from the content for several very good reasons. Maintainability is a biggie as anyone who's ever had to redesign a static HTML website riddled with <font> tags. Extra points if it was made using a WYSIWYG tool that uses three or for tags when you only need one...

Anyway, I for one hope that XHTML is path we stay on. And I think the main problem that XHTML+CSS has had is Internet Explorer and its craptastic handling of CSS (still crappy in IE7 although it's gotten slightly better).

/Mikael

Re:Cry for relevency (1)

AceJohnny (253840) | more than 5 years ago | (#19926177)

The W3C would become irrelevant quickly if they stopped tweaking the language.
That's the essence of where the W3C went wrong: it's supposed to be a technical group existing solely to promote better standards.

If they promote standards just to justify their existence, then they've fallen for the Dark Side of Committees, and should just be brought out back and shot in the head.

It's All About Web 2.0 (1)

Anonymous Coward | more than 5 years ago | (#19925639)

It's all about "Web 2.0". A new source of revenue must be needed, might as well tweak the current HTML spec. No worry that there
isn't a browser that fully supports it, as per spec, just release more bloated crapware.

And here I was happily surfing the web on Lynx.

I'm sure this will add more 'features' to enable revenue generation.

W3C is aggrivating sometimes (1)

webrunner (108849) | more than 5 years ago | (#19925671)

If you look at the docs and stuff, there's just so many stupid things.. like there now being no semantic replacement for like there is with and , and the stupid rules involving
  • s not being allowed in

    s. And the worst part, and I don't know if this is w3c's fault, but using & for html entities is inexcusably broken. URLs have already had & reserved for years, and now you suddenly can't use a & in a link.

Re:W3C is aggrivating sometimes (1)

webrunner (108849) | more than 5 years ago | (#19925689)

Okay, "plain old text" apparently doesnt mean what It's supposed to mean.

If you look at the docs and stuff, there's just so many stupid things.. like there now being no semantic replacement for <u> like there is with <i> and <b>, and the stupid rules involving <ul>s not being allowed in <p>s. And the worst part, and I don't know if this is w3c's fault, but using & for html entities is inexcusably broken. URLs have already had & reserved for years, and now you suddenly can't use a & in a link.

Re:W3C is aggrivating sometimes (2, Informative)

sveard (1076275) | more than 5 years ago | (#19925763)

Isn't the & character forbidden in XHTML links? You have to use the & entity, if I remember correctly. Sure, it's allowed in HTML 4.01, but not in XHTML (again, if I remember correctly)

Re:W3C is aggrivating sometimes (1)

CastrTroy (595695) | more than 5 years ago | (#19925903)

That's because XML expects that all attributes are properly encoded. There's a method behind their madness. It's not like they just said "hey, lets see how we can screw up links in XHTML." No, they took XML, which already didn't allow & or many other characters in attributes without encoding and stuck to that standard. XML was standardized years before we decided to use it for webpage markup, it's not like they could just go ahead and change it.

Re:W3C is aggrivating sometimes (0)

Anonymous Coward | more than 5 years ago | (#19925777)

You've always been supposed to escape your ampersands in all HTML, including links.

Re:W3C is aggrivating sometimes (2, Informative)

Anonymous Coward | more than 5 years ago | (#19925837)

Quickly, and in the order you mentioned them...

First, the italic and bold tags don't have semantic replacements either. You have the em tag, which is supposed to represent emphasised text, and the strong tag, which is supposed to represent strongly emphasised text. Following standard typographic conventions, emphasised text is rendered in italics, and strongly emphasised text is rendered in bold. These are not the same thing as the i and b tags. A screen reader would completely ignore those, but might use the em or strong tags to apply emphasis to the spoken version of a page. A non-graphical user agent might represent them in a different way.

That's why the i, u, and b elements still exist in XHTML 1.1. They're just for italic, bold, and underlined text that has no semantic meaning. When writing something in a foreign language, for example, it's conventional to use italics. That's not the same as emphasised text - a screen reader should not emphasise the italic portion just because it's in italic. So you'd use an i element, or some other element with italic font styling applied to it.

Of course lists aren't allowed in paragraphs. How could they be? If you're writing a paragraph, and you then start writing a list, have you not in fact finished the paragraph first?

The HTML entities thing is from SGML.

Re:W3C is aggrivating sometimes (1, Informative)

Anonymous Coward | more than 5 years ago | (#19925847)

> URLs have already had & reserved for years,

URLs have NEVER reserved & as part of their syntax. Go read the RFC [gbiv.com]. This ampersand business came from the CGI spec, it's been wrong from day 1, and they introduced use of semicolons instead to compensate. Using a bare ampersand in an XML doc will always give you grief, no matter where you put it, unless it's in CDATA. Using &amp; will always result in a URL with an ampersand in it, and if your browser renders that as five characters instead of one, it's broken.

I rather imagine every browser will degrade to a "quirks mode" for any bare ampersands in URLs, so you can continue doing what you do. It just won't be strictly compliant, and it's already going to result in errors in xml-based frameworks like facelets.

Re:W3C is aggrivating sometimes (0)

Anonymous Coward | more than 5 years ago | (#19926011)

Uhhh.. you can still use <u> for underlines [december.com]. Oh, and you can always end your paragraph, start your list, then restart your paragraph. But then again, when people complain that they can't use &, I should probably leave well enough alone since they don't know about entity references [w3.org].

Re:W3C is aggrivating sometimes (2, Funny)

brunascle (994197) | more than 5 years ago | (#19925909)

you, sir, are apparently the last person i should be listening to about HTML.

it's a joke. laugh.

WTF?! (0)

Anonymous Coward | more than 5 years ago | (#19925717)

From TFA: "More funky tags: <p> and <div> are old, so how about more tags for what has become common nature on the web"
Is this a hint at p and div becoming depreciated? This would be even worse then depreciating the tag, which they also did.

On the other hand, it would be nice to be able to tag areas of a page as content and fluff.

<div notice="this is the site menu, google, yahoo, etc, ignore this. there is better stuff on this page to worry about"> ....
</div>
<div notice="this is the meat and potatoes of the page, focus here"> ....
</div>
On the other hand, I probably have other problems since Google likes my menus better then my page contents.

Re:WTF?! (0)

Anonymous Coward | more than 5 years ago | (#19926089)

Oops, didn't escape all the html. take 2.
From TFA: "More funky tags: <p> and <div> are old, so how about more tags for what has become common nature on the web"
Is this a hint at p and div becoming depreciated? This would be even worse then depreciating the <center> tag, which they also did.

On the other hand, it would be nice to be able to tag areas of a page as content and fluff.

<div notice="this is the site menu, google, yahoo, etc, ignore this. there is better stuff on this page to worry about"> ....
</div>
<div notice="this is the meat and potatoes of the page, focus here"> ....
</div>
On the other hand, I probably have other problems since Google likes my menus better then my page contents.

Web Pages (1)

NeoTerra (986979) | more than 5 years ago | (#19925761)

Amazingly, my web pages sucked with HTML 4. They sucked with XHTML. They'll probably suck just as bad in HTML 5.

Just my 2 worth.

Get it on yer CV man! (2, Funny)

Chrisq (894406) | more than 5 years ago | (#19925843)

Or as the CV writers would say: "extensive experience with HTML 4, XHTML, where he was responsible for delivering high quality web pages. Has studied the HTML5 standard and is confident that he will be able to maintain the same quality of delivery with this new technology."

As a standard, HTML4 has failed (3, Interesting)

Nicolas MONNET (4727) | more than 5 years ago | (#19925817)

It's too hard to implement, because there is no default way it should look like. There is no default, standard stylesheet. What height is H1 supposed to look like by default?

Also look how hard and painful it is to implement a 3 column liquid layout with just HTML and CSS. Compare this to XUL's grid, vbox and hbox (yes, I know there are now CSS selectors in Firefox, Opera and Safari to do that)

Fact is, HTML is based on a page/document model, whereas, nowadays, HTML "pages" are most of the time "screens", part of an application. The idea to separate content and layout is nice, but the thing is, most content in pure-ist HTML+CSS is basically a bunch of div's and span's. It isn't much semantically richer than tablesoup.

IMHO, if I were to redesign HTML today, it would look a lot like Xul, with XBL2 and microformats on top.

Re:As a standard, HTML4 has failed (1)

TheRaven64 (641858) | more than 5 years ago | (#19926191)

Also look how hard and painful it is to implement a 3 column liquid layout with just HTML and CSS
It's trivial with CSS3, which includes a set of rules for defining multi-column [w3.org] layouts.

Re:As a standard, HTML4 has failed (1)

mikael_j (106439) | more than 5 years ago | (#19926577)

Also look how hard and painful it is to implement a 3 column liquid layout with just HTML and CSS.

Actually, the regular three-column layout that is popular all over the web really isn't that hard to implement in CSS, you need to have a bit of an understanding of XHTML and CSS to pull it off but it's nowhere near as bad as it was back when people were doing similar designs with just HTML 3/4 and <TABLE> tags..

The idea to separate content and layout is nice, but the thing is, most content in pure-ist HTML+CSS is basically a bunch of div's and span's. It isn't much semantically richer than tablesoup.

This would depend on how the code is written, proper standards-compliant XHTML+CSS without ugly IE-compatibility hacks and unnecessary javascript because the developer didn't know how to do a horizontal <ul>-based menu using CSS is normally a lot nicer than a similar design in old HTML where the design and the content are all mixed up in a big unreadable mess..

/Mikael

HTML 5? Awful. Call it HTML 2.0. (1)

dpbsmith (263124) | more than 5 years ago | (#19925823)

What are these people, engineers or something?

It needs to have a spiffy name like Extreme HTML or HTML-Pro or Sup-R-HTML or HOT!ml.

Or... I have it. Call it HTML 2.0.

Bother the fact that that version number has already been used, everyone knows that the purpose of version numbers is not to identify sequence but to communicate a marketing message and what could be better than an implication that it's "the HTML for Web 2.0?"

Great (1)

ajs318 (655362) | more than 5 years ago | (#19925897)

Let's have HTML5 exactly like XHTML, but make it case-insensitive. Especially ditch the awful <font> tag. And allow "centre" to be spelt correctly!

The thing that ruined XHTML was that it introduced case-sensitivity to a system which had previously been case-insensitive. This is a recipe for breakage. Case-sensitive behaviour is fine in its own right -- after all, just because the dollar sign and the figure 4 come from the same key on the keyboard, they aren't interchangeable, so why should the letter "z" and the letter "Z" be thought of so? -- but not when it's introduced suddenly where it never existed before. That is a blatant contradiction of the Principle of Least Surprise.

It could be argued that removing case-sensitivity which had existed previously would create even more breakage; suddenly, <BR />, <Br />, <bR /> and <br /> would no longer be four different tags; and if they had ever had different meanings, it would have cocked things up. Of course, assigning different meanings to differently-cased versions of the same phrase was itself a Least Surprise Violation in the first place, unless all but one version are considered errors .....

At any rate, capitalised tags make it easier when you're editing HTML on the web server using nano.

Re:Great (0)

Anonymous Coward | more than 5 years ago | (#19925941)

> And allow "centre" to be spelt correctly!

Why do you Brits always insist on using French spellings?

I mean, it's pronounced "sent-err", not "sent-re"

Referrer (1)

pne (93383) | more than 5 years ago | (#19926071)

And allow "centre" to be spelt correctly!

Now what we need is a new version of HTTP that allows "Referrer" to be spelled correctly.

I think you'll find (1)

FoamingToad (904595) | more than 5 years ago | (#19926347)

that "Centre" is in fact spelled correctly. It's "Color" that's wrong ;-)

Perhaps both Centre and Center, and Color and Colour, could be considered syntactically equivalent for the purposes of rendering, to cater for differing regional variants of English?

F_T

Re:Great (1)

jez9999 (618189) | more than 5 years ago | (#19926587)

Case-sensitive behaviour is fine in its own right

Not really, no. Case-sensitivity is only good when you're trying to *avoid* namespace clashes. Passwords and variable names (just about) qualify as good usage. When trying to lower accidental misses, however, it's a terrible idea -- so, it's bad for markup tags, and whoever's hairbrained idea it was to make Unix filesystems case-sensitive should be shot. Actually, I don't think it was because someone thought it was a good idea - they just didn't really think not to do it.

-- after all, just because the dollar sign and the figure 4 come from the same key on the keyboard, they aren't interchangeable, so why should the letter "z" and the letter "Z" be thought of so?

Because $/4 are totally different characters, whereas z/Z are the same character but with only a case difference? Because humans regularly interchange z/Z and would basically understand 'snooze' and 'snooZe' to be the same? Compare that to the difference between 440 and $40.

A clean slate again (0, Troll)

athloi (1075845) | more than 5 years ago | (#19925899)

This is progress, because it's based more on reality than on the usual spacy navel-gazing that defines our standards.

After Mosaic faded out, Netscape was the dominant browser, but around 1997 it fell behind in implementing new features. Because it was more stable (!) and did allow for newer features that weren't in the "official HTML playbook" but were demanded by consumers, Microsoft IE took over as the dominant browser. This was not least of all because those of us earning a living making web pages needed to implement these new features demanded by our customers, and Netscape tried to thwart us, being every bit as controlling as Microsoft is reputed to be. They would not implement necessary innovations in layout and media presentation, and their browser was flaky, so everyone and their dog shifted to IE.

IE took over and "ad hoc" implemented what it could and what corporate politics allowed. It was far from perfect but it was better than any other option. Some years later, after IE had gained dominance, a small team brought us Firefox. This new browser tried to rewrite history by claiming it was the guardian of the "one true standard," the Word of the W3C, et al. It seems deliberately designed to ignore the changes in the world of designing web pages brought about by six years of IE dominance.

The result is a cross-browser coding disaster, and as a web developer of 15 years' experience, I blame Firefox more than IE. Both sides have their own model, and IE can't change, because it must uphold its backward compatibility. Firefox, on the other hand, is a completely incompatible standard that reflects W3C standards written after IE gained market dominance, in some cases. It is needlessly combative and in my view, destructive to those who make pages and the consumer. (Opera, on the other hand, has a saner view: it views IE 5-6 as a de facto standard and adapts, a striking maturity the FireFox developers should find intriguing).

HTML 5 is a chance for both sides to fix their sites on something productive. We can for once develop the standard before the browser, and make it work cross-platform, saving web developers years of frustrating and most of all BORING xbrowser code fixes. Also, we can finally admit to each other that while CSS is neat, the original HTML model made more sense for developers and is still more stable than CSS.

That's my statement, and I'm sticking by it, after being a Gopher administrator, FTP publisher, early Web site creator/server admin and independently employed Website creator for fifteen years.

Re:A clean slate again (2, Insightful)

CastrTroy (595695) | more than 5 years ago | (#19926215)

If the standard is "do whatever IE does" then how would Firefox ever actually be able to implement that standard. There is no published documents on how IE functions, so how is Firefox supposed to keep up with that. If Firefox emulated IE 6 perfectly, and then MS released IE7 and completely changed the markup (like they do all the time with their doc format), then Firefox would have to go through a lot of work, trying to figure out what MS was doing. the W3C standards exist because people want to use operating systems other than windows to access the web. They exist because they want to be able to rely on other vendors to provide a web browser that works. If anything I would blame MS for holding everyone back, when we could be creating beautiful webpages very easily, but instead it ends up taking twice as long because we have to deal with all the quirks in IE. Even if no other browsers existed, it would still take this long, because there is no documentation or definition of what IE will do with any give HTML or CSS code.

Re:A clean slate again (3, Insightful)

HappyHead (11389) | more than 5 years ago | (#19926433)

After Mosaic faded out, Netscape was the dominant browser, . . . Microsoft IE took over as the dominant browser.

The funny part of that is, Netscape was a re-write of Mosaic by the people who made it in the first place. They did Mosaic as a school project, and then said to themselves, "You know, we could probably make money with this, if we fixed all the things we did wrong!" Mosaic was kept by the University it was written at, then spun off to a company named spyglass, which was bought by Microsoft, and re-named to IE. Thus, Mosaic started the web revolution, Netscape was a side-track, and then Mosaic came back under a different name, with much wealthier owners who could afford more coders to work on it. Netscape of course, tried to keep up with the feature creep, but with less financial backing, and less people working on it, their code soon turned into an un-manageable mess (which is why it was completely scrapped and re-written from scratch for Firefox) - just goes to show that for large projects, maybe those project managers really do serve a purpose.

That of course, is where the problem with browser compatibility really came in - Microsoft wanted more more more features, and they wanted them now now now! So they pushed their developers for speed instead of sanity/security/stability, and that resulted in dumbness like allowing ActiveX to be embedded inside of web pages, and the completely screwball syntax for adding filters to CSS code. Admittedly, some of the things that were added were good, and some were useful (the BGSOUND tag for example, is much easier to control from javascript than the EMBED tag), but the vast majority of the "new features" introduced to IE this way were either pointless, needlessly convoluted for the developer, or just plain harmful. (As the many people who had their bank accounts raided by ActiveX malware, or their computer's power turned off by visiting a prank site will agree.)

Since IE was windows-only for the most part, Microsoft was free to include as many proprietary things as they wanted, slap copywrites, patents, and all sorts of other protections on them, and basically make it impossible for people on other platforms to add those features to their browsers. It's important to remember that in the early days of the internet (when Mosaic and Netscape first came out, and thus when the actual mindset regarding their feature paths was determined), Windows only barely supported internet access at all, and was in the extreme minority of systems on the internet, which were mostly Unix based. (Yes, Microsoft's browser did technically originate on a Unix system, I've used the original first version of Mosaic when it was first released, on a black-and-white X Terminal attached to an SGI Challenge system.) That meant that while Microsoft was free to make things that worked only on their system and call it good, nobody else could get away with it, as most of their userbase would be left behind.

Besides, adding a new spec like HTML 5 will not fix the browser gap - even now, as new technologies are coming out and new standards and specs are being released, the browser developers are still putting their own unique and incompatible spins on how things work. Ever tried to embed video in a web page and have it be completely XHTML compliant? You can do it in Firefox. You can do it in IE too. You just can't do it in both with the same code, because they interpret the specs differently. That has nothing to do with IE needing to support backwards compatibility at all, since backwards compatibility relies on a different set of tags completely. It also has nothing to do with Firefox's developers being immature and combative, since they took the simpler and saner route of the two, which didn't involve ActiveX, or embedding the Microsoft Media Player. (Yes, ActiveX in web pages is still bad, even if it can't get at your bank software or power off register anymore.)

Just what we need (4, Funny)

Anonymous Coward | more than 5 years ago | (#19925925)

Another web standard for microsoft to ignore.

Client side include please! (3, Interesting)

apathy maybe (922212) | more than 5 years ago | (#19926007)

Can I have a client side include this time around?

Server side includes are very nice, except that they require a server!

Client side includes have the potential to be much nicer! Two quick reasons: the first is when (X)HTML is used on (for example) CDs or similar, there isn't a server, and trying to make each page the same either requires fucking around with templates and software, or else using forms...; the second is it would work the same was as having external CSS, saves on download time, allows parts of the page to be downloaded only once and so on. (This second point would also make it really easy to offer different versions of the same page, include header and footer, and don't for example.)

I know that JavaScript client side includes exist. They, however, are a kludge. They need JavaScript for one!, they might not work on all browsers, they might not be standard and so on. No thanks.

A simple client side include that worked on the client side the same way the PHP include does, and I'll be happy.

Re:Client side include please! (1)

CastrTroy (595695) | more than 5 years ago | (#19926303)

I can't for the life of me understand why this type of stuff doesn't exist. If you can pull down images, video, and all that other stuff and display it inline, then surely you should be able to do the same with HTML content. There's been a lot of kludges made in Javascript and the use of iFrames and other wonderful things, but personally, I think that client side includes has been the most glaring omission. The only problem that I could think of, is whether or not the urls from the href,src, and others should be relative to the original document, or the location from which they are being pulled.

Re:Client side include please! (1)

Bonker (243350) | more than 5 years ago | (#19926393)

Client Side Includes, while enabling a certain range of features, would also make an excellent backdoor to information theft.

Imagine something like:

input type=hidden name=allyourccnumbersarebelongtous value=

include c:\windows\well_known_app's_buggy_config_that_cont ains_your_credit_card_numbers.txt

input type=submit value="Refresh Page"

Re:Client side include please! (2, Interesting)

apathy maybe (922212) | more than 5 years ago | (#19926601)

While that is a possibility, you could easily implement have it implemented so that the standard says that only things from the same place could be included (this way you couldn't include local documents in external documents and vis versa). Or you could just build a secure fucking browser that didn't do that sort of thing...

What is wrong with XHTML? (1)

jonwil (467024) | more than 5 years ago | (#19926073)

Clearly XHTML is inferior to HTML otherwise the people behind this push for HTML 5.0 would be pushing for XHTML 2.0 instead. But why is XHTML worse than HTML?

Re:What is wrong with XHTML? (1)

IBBoard (1128019) | more than 5 years ago | (#19926149)

Because it has a required structure and is more XML-like, so people can't be lazy and miss closing tags etc?

Alternatively, it's because XHTML is semantic, where as HTML is either not semantic (, , etc in HTML4 have no real meaning) or that it's buzzword-semantic (, and the others mentioned are apparently possible parts of HTML5). Why make people think semantically when it doesn't involve buzzwords and 'oooo, leet blog'-ness?

Re:What is wrong with XHTML? (1)

IBBoard (1128019) | more than 5 years ago | (#19926219)

Yargh, damnit, just like a previous poster I got caught out by the posting format.

Real parent post:

Because it has a required structure and is more XML-like, so people can't be lazy and miss closing tags etc?

Alternatively, it's because XHTML is semantic, where as HTML is either not semantic (<b>, <i>, <u> etc in HTML4 have no real meaning) or that it's buzzword-semantic (<article>, <video>, <progress> and the others mentioned are apparently possible parts of HTML5). Why make people think semantically when it doesn't involve buzzwords and 'oooo, leet blog'-ness?

---

Addendum: See, this is why HTML is bad. I put in an unclosed tag and it parses it ;)
Addendum 2: Damned posting limit making my correction follow-up slow!

What things? (1)

IBBoard (1128019) | more than 5 years ago | (#19926093)

...things don't always develop the way we expect
Huh? What things? I found nothing in TFA (well, the first one, don't quite want to read an entire working draft ;) ) that mentioned something that hadn't developed as expected.

date tag? (4, Interesting)

ngunton (460215) | more than 5 years ago | (#19926249)

I have suggested this before and always got shouted down for it... but as a web developer, I really wish they had simply implemented tags like 'date', which the browser would automatically know about as a date field and have its own built-in popup calendar for browsing dates, rather than having to either rely on plain text, lame dropdown menus, or else implementing yet another date popup javascript library (or including yet another javascript library which slows down the user experience even more).

There are so many things that could be included in the html language if it weren't for the purists - dates, columns, real collapsable tree controls, counters, AJAXified controls that work without all the crap you have to do today to detect browsers... but no, the purists say "you can do it in this (incredible convoluted) css" or "you can implement this in javascript" (cue long convoluted "obvious" solution).

Geeks are notorious for generalising and making everything nice and orthogonal, but they often forget that sometimes it's worth having something that makes life easier 90% of the time, even if it's technically possible to reduce it to a set of other constructs that already exist.

Remember lisp, nobody uses it for real-world programming even though it's incredibly powerful. No, we use other languages that have lots of useless and redundant and inflexible syntax that makes the act of everyday programming easier and more straightforward most of the time. Are these inferior languages as powerful, expressive and all-encompassing as lisp? No. Are they easier for 99% of mere mortals to comprehend and use? Yes. If we had tags for controls that reflected the more dynamic nature of the Web today, even if many of those tags could be implemented in javascript, it would make pages smaller and faster 90% of the time (you could still implement it yourself if you really needed additional functionality).

But, as usual, the purists are in control. We're not supposed to use tables for arranging pages; no, we have to use CSS to do that. So now we have a bunch of pages that don't render properly. But do they admit that it was a bad idea? No, it's the browsers' faults for crappy implementations. I don't get it, this religious mindset that says "You must do it one way, our way is the only way". "The TABLE tag is for tabular data only, don't use it for arranging the page". What crap. The table tag is amazingly useful, it works in all browsers, and no I don't mind in the least typing TR and TD everywhere. It's simple and it works. Yes, it's more verbose perhaps than the CSS version but at least it works in all browsers and doesn't end up with overlapping crappy text all over the place.

One thing that's always irritated me about XML... (0, Offtopic)

jez9999 (618189) | more than 5 years ago | (#19926491)

... is that its tags are case-sensitive. This doesn't make any friggin' sense. I've never seen a case where they define 2 tags named identically but cased differently, and indeed it would be silly and confusing, yet XML behaves as if this is the case. XHTML inherits this limitation. I like my HTML tags in uppercase, damnit, to make them more obviously separated from the content! Are XML parsers too lazy to do something like "lc(string1) == lc(string2)"?

Re:One thing that's always irritated me about XML. (1)

Crimsonjade (1011329) | more than 5 years ago | (#19926611)

I actually like this feature. I hate when I am reading HTML and all the tags are capitalized. It looks horrible and it usually means I can expect to see some php right smack in the middle of it all.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...