Huzzah, so all the cruft already there and any cruft that happens to get added can never be removed.
I’m not talking about the name, when dispute rises. I’m talking about the “living” nature of the spec, making it impossible for me to ever be sure if my point is a definitive one.
If you don’t use version control, you’re, in fact, slowing and then stopping the evolution. I mean, just read this. They start by saying: “we want the change, if nothing is changing”:
As parts of the specification mature, and implementations ship, we stop making changes to those sections for all but the most critical of reasons, such as security problems
and then they go “we will contradict our self every other phrase”:
The specification is never complete, since the Web is continuously evolving.
Moronic, really. I mean, at some point, all sections must complete, all parts of the spec mature. What then? What about “is never complete part”? I’ll tell you what about it: cheap philosophy.
WHATWG is destined to fail. Their ideas and their specs are moronic and amateuresc.
How do you deal with disputes about the English language? How can you be sure that your point is a definitive one when the English language is changing over time? (I’ll give you that it doesn’t change at the same pace as HTML.)
We use version control. The spec is currently at revision 5836. So just consider the name to be HTML5836.
WHATWG slowing and stopping the evolution? That’s a new one; we’ve rather been blamed (or praised) about the opposite. 
Hmm. Yeah, the FAQ is a bit bluntly written as opposed to entirely accurately. I’ve updated the FAQ with a more accurate statement for the “stop making changes”.
What about browsers? At some point, all bugs must be fixed and there are no new features to add. What then? Or are there always going to be bugs and new features to add? I think so, for so long as the Web is not replaced by something better and dies, at which point the HTML spec will die with it.
It’ll be complete when it is obsolete because the Web has been replaced with something else.
You’re entitled to your opinion of course, but I must say your argument doesn’t convince me. (But that’s hardly surprising since I’ve been involved in this for longer than my professional career. :))
Right. The bad part of backwards compatibility. Just look at the <plaintext> element, which was obsoleted in the very first HTML spec, but is still supported by browsers and thus specified in the current spec. (It’s invalid to use, though; we can always declare bad features invalid while browsers still have to support them.)
Well, the English language is not the only one that suffers from modernisation. Which is not the point here. Since we talk about oranges and apples.
I would, but then again they said just HTML. Another oxyMORONIC.
Neh, neh, neh, neh, nehhhh… Mind you, I said the lack of versioning will do that. You… politician, you
You… politician, you
That’s pretty far fetched, to think WHATWG and its specs will last that long.
True. That’s why I’m saying: WHATWG are children let loose. They will be soon smacked down by reality. And, my guess, these are the muddy waters from which something else will emerge. Something serious, and HTML (5 or Fred) will remain a hox.
We’re definitely on the same page here. Top to bottom this disaster of a ‘specification’ they are pushing reeks of ‘gee ain’t it neat’ bull, bandwidth hogging nonsense sold in the name of reducing bandwidth, and seems to exist for the sole purpose of placating the people who don’t write their HTML properly in the first place. You know, the people who wrap DIV around EVERYTHING whether it’s needed or not, endless pointless redundant classes, can’t be bothered to learn to use the numbered heading tags properly, and still vomit up HTML 3.2 any old way, slap a tranny doctype on it and call it HTML 4… Literally that seems to be who it’s for.
It is PAINFULLY obvious that everyone behind it failed to even understand the point of the STRICT versions of the 4/X1 specs, and in an age where most people STILL fail to use semantic markup and can’t be bothered to learn more than 2/3rds the tags in the specification, adding more tags and attributes is NOT the answer! More than anything it’s undoing all the progress of STRICT is what truly grinds my gears. This sleaze code together and let’s blend all the rules into a giant hodge-podge of possibilities (where you can mix 3.2, 4 tranny, 4 strict, x1 tranny and x1 strict together any old way) is just promoting more bad habits that will result in more confusing poorly coded pages.
Of course mind you I’m a Wirth language fan, so I like rules, guidelines, and restrictions on how code should be built instead of the slap together needlessly cryptic garbage any old way attitude that goes with your C family languages.
Much of the problem with HTML5 also comes from them slapping underneath the umbrella a bunch of stuff that has NOTHING to do with markup. HTML 5 doesn’t just refer to the actual HTML – but a whole bunch of other “API” that really have no business being put under the HTML name. Even some of the tags have no business even existing AS tags… Take CANVAS for example… an element that exists SOLELY for javascript, in which case shouldn’t said javascript just be able to be applied to ANY element? There is zero reason for that to even warrant the use of a new tag! (and frankly it would be a hell of a lot more useful if canvas was just a sub-element on the DOM of every element)
Likewise there’s the outright redundancies – many of the tags that were deprecated (and were supposed to be obsoleted eventually) were removed NOT because they were non-semantic, but because they were redundant to existing tags – with some tags modified to replace the functionality of proprietary tags… MENU and DIR for example were pulled as redundant to UL… now MENU is back in a form that has SOMETHING to do with forms (!?!) that I still can’t figure out what that’s even for… APPLET was dropped for OBJECT, which was also supposed to replace the proprietary BGSOUND and EMBED elements, with even IMG on the chopping block for it too was redundant to OBJECT… so naturally do they attach all those nice new scripting controls to OBJECT, the element that allows you to add and remove support for file formats on the fly? OF COURSE NOT. No, they add AUDIO and VIDEO in such a manner that you’re pretty much stuck using whatever formats each browser maker bothers to hard-code into their software. Oh yeah, some improvement there. Sure, rather than ride the browser makers asses on fixing the existing element and making it behave consistently cross browser, let’s give them the tools to implement vendor lock-in for each browser makers favorite pet codec. That’ll make EVERYTHING better.
NOT!!!
Of course I get a laugh how all the people who usually kvetch about all the “bloated” features hardcoded into Opera are the first to get in line to support AUDIO and VIDEO.
Off Topic:
Oh, and here’s a tip – if the browser is roughly the same memory footprint, size and speed as everyone else’s baseline WITH the extra functionality already built it, It’s not bloated, the competition is!
Even the new allegedly semantic elements are rubbish… SECTION for example… What’s a DIV? It means “division” – it exists to divide the content into SECTIONS… making SECTION a redundant tag! Other elements like “HEADER” apply meanings you shouldn’t even need on elements if you bother understanding how numbered headings are supposed to work – but of course with pretty much EVERYONE failing to grasp the simplest of concepts by way of skipping over numbers, increasing the number when it’s not a subsection of the one preceeding it, and in general barfing up code any old way, it’s no surprise to see such idiocy added to the spec… even NAV is useless garbage, seeming to exist for the sole purpose of people who didn’t get the point of accesskeys, fail to grasp what makes .jumpto menus superior, or just plain feel the overwhelming need to wrap an element around their UL’s for NO GOOD REASON. I swear every time I see <div class=“nav”><ul> I feel the need to backhand somebody, so <nav><ul> is just more pointless bloat!
Top to bottom HTML5 makes me ask “and the advantage of this is what exactly?!?”
… and the answer appears to be “Well now you can sleaze out your code any old way”… yeah, some improvement… Though I suspect that’s why they started slapping all the other API’s under it’s name – at least SOME of those introduce something useful.
Hi ds60, long time no see. Good to see you back, we’ve missed you here.
The problem that I see with HTML5 and the pretending it brings along: as you said, 'till now nobody stopped you to “sleaze out your code any old way”. BUT… you had, if asked, opinions on it as a bad code practice that needs improvements. All backed up by solid specs.
With HTML5 it seems that you are legitimate going around your code any weird way possible. Even more so since, in order to push HTML5, all rules are broken by UA makers.
And this encourages bad attitude like: “it’s OK to use JS to simulate HTML5”. They have opened the doors to promiscuity but they wanted to open the door to easiness. Well, guess what, people’s minds are dirty!
The team lead and I were talking about this an hour ago 
I’'ll get a shirt that says “JS + jQuery = My savior” lmao
I think the point is that removing versioning steals a valuable tool for us to use when we talk with each other. When IE sat on version 6 for all those years, we had a standard that it was failing, CSS2.1. The fact that we had a standard allowed people much smarter than me to create the ACID2 test, and we could say that this group of browsers were ACID2 compliant, but IE6 was not. Then MS finally came out with IE7. Was that the end? No, people fired it up and that didn’t pass ACID2 either, so less than a year later we had IE8 which finally passed the ACID2 test. None of this would have happened without a standard, worse, if HTML floats around and means one thing today and another tomorrow, there’s no fixed point that you can hold browser vendors to. You can’t create an ACID5 test, if there’s no standard to base it on.
I would say this hits one of the key nails on the head. Do you want to program in English? Or Spanish? Or Urdu? Or Mandarin? Do you want to have to write programs that don’t just “do” what they’re supposed to do, but which have to interpret the linguistic gymnastics of spoken language? Human languages are changing all the time and they “human” languages because we’re the only machines on the planet with hardware and firmware that’s sophisticated enough to make sense of these complex and changing grammars. Can you imagine trying to get your computer not only to understand them on any given day, but to make sure they work for more than a few days as new idioms and conventions are introduced, and THEN… oh by the way, actually try to address your problem domain with it? This is the entire reason that we have AGREED UPON STANDARDS. And a “standard” that changes all the time defeats the entire purpose of having a common point of reference because I don’t know if any particular item in the standard will still be there tomorrow.
I think you’re getting things confused
Think of HTML as a dictionary; how HTML should be used right now. Let’s face it, some people and HTML generators are never going to self-close their img tags or put quotes around attributes - but all browsers cope if they don’t, so you might as well say “You don’t need to put quotes around attributes” in the spec. If you want to use quotes religiously, that’s your choice, that’s also fine by the spec
They can’t take out the bit which makes it less strict because like it or not, there’s already websites out there which don’t have quotes. That’s the backwards compatible bit: like you can’t remove a word from the dictionary just because you don’t like it anymore. You can mark it as obsolete (as some HTML tags and attributes are marked as obsolete), but you can never really delete them: because they’re used
So think of it as “how browsers behave and how you should use HTML” (just like a dictionary is “How you should use this language” rather than “a spec that browsers must do” - because let’s face it, I doubt any browser has or will ever follow the whole of HTML to the letter - this was even before the time of WHATWG
And instead of asking “Does browser x support HTML5?”, shouldn’t the better question be “Does browser x support h.264 video?”? Because at the time I might want to make a video site, so don’t care if Internet Explorer has canvas support
(Oh, and the English language changes very often)
The English language has changed very little in the past 400 years. Documents that were written in the 1600s are still mostly understandable today although a few words that are no longer used are often misinterpreted (eg. wherefore is an obsolete synonym for why).
It was in the 1500s that the English language last changed at any significant rate and only specialists are able to read documents written in English from before that change. Effectively there was a full version number shift in English during that period with many words being completely dropped from the language (not just marked obsolete) and the pronunciation of many of the surviving words changing (eg. before that there were no silent letters in the word ‘knight’).
To relate this back to HTML - the sorts of changes that are being proposed for HTML5 (or whatever you want to call it) are more of the order where they ought to be called 4.1, 4.2 et). Of course if they were being done as XHTML rather than HTML then each could be done as a separate eXtension.
Have you read Shakespeare? It’s understandable, but to say “The English language has changed very little” is a vast understatement.
It is when you compare it to the amount that the English language changed in the 50 years before Shakespeare which Shakespeare would have had little chance of understanding. In that 50 years the language changed by many many many times the amount that it has changed by in the hundreds of years since.
Anyway if you don’t understand Shakespeare then you don’t know English all that well since Shakespeare is taught as standard English Literature texts in schools. Shakespeare wrote in what we currently call Modern English.
For those of use who understand the importance of semantic code, yet have to deal with the realities of technology constraints many of the new tags such as; nav, article, section, header offer a more specific, solution to solving common problems. In that respect I am happy to see them introduced into the language. Certain patterns have been established and those tags do a good job providing a level of semantic meaning other than a div. A div is a good generic element but nav, section, article provide a increased level of semantic meaning for common problems that normally require some type of generic element such as; division or list.
Furthermore, dealing dynamic content I am very happy to see headings relative to layout elements rather than the entire document. I can’t say how many times I have pondered the correct heading level taking into consideration possible changes or moving things around. This is especially a problem with modular architecture where a list may be displayed on several pages with the same code, reducing replication and sticking to the dry principle. Headings relative to specific elements will make future content management system development more semantic in respect to things being able to be moved around such as; blocks while the headings for the block remain relative to the block area.
As with anything adding a level of complexity always increases room for error. However, I don’t think that is grounds for dismissing ideas that can improve the approach of solving common patterns as many newly proposed elements do. Many new elements seem to exist for the purpose of providing meaning for common patterns and that I am happy to see. I mean if something is a nav than why shouldn’t it be placed in a nav element, that kinda makes sense and also provides a extra semantic element for applying styling. Some may look at that as a bad thing but I think its positive given the practical reality of the technology alongside client, designer expectations.
The problem the way I see it is that many HTML elements such as; div provide to generic of a meaning. Common patterns have been defined and “HTML5” is an attempt to provide solutions to those problems using a more specific means than the current specification can provide. To me that is heading in the right direction, moving past this “caveman” language and something more concrete based on the problems faced throughout the entire web based paradigm.
Acid2 could have been written the same even if CSS had been a living standard. Acid5 can also be written against the HTML spec just fine. Just choose parts of the spec that are stable when writing the test. Acid2 and Acid3 required thought and coordination anyway, and needed bug fixing afterwards. Case study: http://ln.hixie.ch/?start=1137799947&count=1
So I’m not at all convinced that frozen snapshots are at all helpful in writing Acid tests. (You are aware that it’s the same person who edits the HTML spec as who wrote Acid2 and Acid3, right?)
HTML is not a programming language.
Exactly. HTML is a markup language and there is a standard for defining markup languages called SGML. If following standards is important (as those who developed HTML2, 3.2, and 4 considered it to be) then that standard should be followed in developing the markup language.
The benefits from using XHTML are mostly unknown, even to those using it. Ask anyone why they are using it, and you would get the usual myths around accessibility on mobile phones, cleaner code, and even SEO related benefits.
You may find the following interesting, posted by Ian Hickson on the WHATWG mailing list.
> 7. The XHTML 5 spec says that “generally speaking, authors are
> discouraged from trying to use XML on the Web”. Why write an XML spec
> like XHTML 5 and then discourage authors from using it? Why not just
> drop support for XML (XHTML 5)?
Some people are going to use XML with HTML5 whatever we do. It’s a simple
thing to do – XML is a metalanguage for describing tree structures, HTML5
is a tree structure, it’s obvious that XML can be used to describe HTML5.
The problem is that if we don’t specify it, then everyone who thinks it is
obvious and goes ahead and does it will do it in a slightly different way,
and we’ll have an interoperability nightmare. So instead we bite the
bullet and define how it must work if people do it.
source: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-February/009517.html
The main benefits from using XHTML is, as i understand, the ability for web designers to combine XHTML with other XML based languages, such as svg. But now that HTML integrates some of this extendibility, the need to use XHTML stands out even less.
As for what the future holds… Well i strongly believe in living standards, and i think they will, for the most part, replace the old version models.
I apologize for using incorrect vocabulary, but I think Stephen has succinctly restated a key issue. In 1997, we had developers marking up their pages in HTML 3.2. In Dec. 1997, HTML 4.0 was released. Each of these standards defined a set of features. Developers sitting around having a beer had a shorthand way of talking about a large scale feature set. Developer one can say something to developer two who responds “You’re wrong, because of XYZ.” Developer one responds “Oh no. I’m talking about HTML 4.0”. Developer two concedes “Oh. Well, of course in HTML 4.0, I thought you were talking about 3.2.”
-
When the standard changes everyday, we can no longer use it as a communication tool like this. This is the entire point of a STANDARD.
-
I see no way in which version numbers had any impact on the speed with which WHATWG or W3C did anything. Removing them will certainly not speed anything up (in fact, if this is simply a way of masking how little progress has been made, it will slow the development of HTML.
-
Carrying this idea through, in what way was HTML less “living” and growing and advancing with version numbers then it is without them?
-
If verions numbers are so detrimental to advancement, why isn’t anyone else dropping versioning? If unversioned standards “live” in some way that versioned ones don’t, why do Intel and Motorola chips have model numbers? That’s just holding them back from making incremental progress and changing the chip architecture every day/week. Why don’t Windows and Mac drop version numbers? Isn’t it more fun to buy software for “Mac OS” or “Windows” and just hope that it will run on your computer? Versioning is a communications tool and is used by all good “living” projects. WHATWG is doing nothing to make the standard any more living than it always has been. They’re only dropping the version number that people need as a point of reference.
ACID2 could have been written the same, but who would care. ACID2 unquestionably played a roll in finally driving MS to update their browser to versions IE7 and 8. It was THE benchmark for CSS2.1 compliance.
ACID5 can only check for “HTML compliance as of Thursday Oct. 5th 2012 at 2pm” or something similar. By 3pm, when a new change is released… Who cares.
There won’t be a need to refer to HTML as a certain number, since HTML also deals with old supported elements, and describe how they should behave, (while still encouraging the separation of content from style for new pages).
If you ever felt you had a “need” to refer to section’(s) of HTML as “HTML5”, then you may not even need to talk about these features in the first place. You could effectively refer to the sections in the spec, that is however not common practice by strangers to the spec.
Are you on the hype wagon, or the practical uses wagon? You could refer to such features as simply “new features of HTML”, arguing that its easier to say “HTML5” is subject of a fundamental change to the English language, I.e shorting of phrases. Which also occurs all the time, (whether officially recognized by dictionaries or not). Such eventually ends up with their own listing anyway, so whats the problem?
You could look at things from a marketing view. Inventing a new, shorter phrase for “new features of x” could potentially make you famous.
Developers are usually interested in specific features, such as the manifest file, the ability to use client-side localStorage etc.
Someone has to make a first step, and what may work well for software and hardware, may not work that well for web standards, which often consists of smaller edits over time. It would be hilarious if people used same argument about other innovative ideas.
The changes applied to standards can potentially be minor changes. For example, we don’t want to increase the version number just because we add or remove a element. Rather potential new elements are often just silently supported by browsers, while we would otherwise be stuck waiting for the W3C to pull them self together.
You could also look at the sections, or individual features as “patch IDs”, where each element has its own section, describing how its used, and how it should behave. Some patches are removed, others are added, etc…
Another important argument, is that you often hear web-designers talk of the new features like, “I can’t wait until HTML5 becomes recommendation”, when in fact many features can already be safely implemented, (often including the very features that people are waiting for).
Hopefully that cleans up a few things in this thread, because its largely a mess. :mad: 
Perhaps it could be FrED: Frantic Electronic Data
On a more related note:
I’ve never combined an XML document to an HTML document, probably because I was never shown for what reasons I would do so. (read: the need wasn’t apparent)
It’s probably also because I tend to render things using a prehypertextprocessing language 