Bloaty Parts Of The WHATWG HTML5 Specification That Should Be Removed
February 19th, 2008
I like many of the features of HTML5, and I think the spec is well written. However, I would like to finish faster. Thus, I have made a list of things that should be moved into new documents or postponed indefinitely. Many of these aren’t particularly useful, or aren’t particularly stable, so it’s not like throwing away finished work.
- 3.4.6 The irrelevant attribute
- 3.18.2 The datagrid element
- 3.19 Data Templates
- 4.4 User prompts
- 4.5 Browser state
- 4.6 Offline Web applications
- 4.9 Determining the type of a new resource in a browsing context
- 4.10 Client-side session and persistent storage of name/value pairs
- 4.11 Client-side database storage
- 4.12.3 Link types
- 5.3.2 The DragEvent and DataTransfer interfaces
- 5.4 Undo history
- 6. Communication (even section 6.3.6.3., Peer-to-peer connections over IrDA)
- 7. Repetition templates
- 9. WYSIWYG editors
- 10. Rendering
- 11. Things that you can’t do with this specification because they are better handled using other technologies that are further described herein
February 19th, 2008 at 9:49 pm
I am shocked — shocked! — that there is no API for modem access. What if my web page wants to make a booty call?
February 19th, 2008 at 10:27 pm
Hello Rob,
Regarding moving section 4.12.3 or postponing it indefinitely, I totally disagree with you. Some link rel attribute values may not be well known or often used but a wide majority of them are useful, very helpful (in particular if you use Site Navigation Toolbar in Firefox, Opera, Seamonkey, etc) if not absolutely necessary to support for some features to work. E.g. prefetch, sidebar, feed.
Regards, Gérard
February 20th, 2008 at 12:59 am
Anything that will improve the web’s craphouse ability to allow users to input text is a extremely overdue feature. Expecting web authors to re-create even something as simple as Notepad that outputs standards compliant HTML is a NIGHTMARE.
Just look at this summary of the options us web developers have to pick from:
http://www.geniisoft.com/showcase.nsf/WebEditors
most of it is a nightmare of hacks and potions and in the end it’s still a nightmare in terms of dealing with character set issues with content pasted from Word.
PLEASE do not pretend this is not a massive requirement. It’s not ‘bloat’ in the age of weblogs on the supposedly ‘interactive’ web to expect a browser to provide a textarea as ‘rich’ as at least Notepad. The web as a desktop? Pah lease!
February 20th, 2008 at 2:25 am
I do not agree. You haven’t really provided rational arguments as to why the sections you listed should be removed from the specification.
The sections “offline Web applications” and those about client-side (database) storage are fundamental to HTML5, in my opinion. What you suggest is actually damaging to HTML5.
Or … this blog post is just FUD, flamebait, and/or a joke.
February 20th, 2008 at 2:31 am
I can see why you want to drop most of these for now, but surely at least local storage will be very important in the near future. If HTML 5 is to have a serious change to make web apps more useful without resorting to proprietary alternatives, it needs this…
February 20th, 2008 at 6:04 am
Coding semantic, accessible and standard compliant XHTML caused me erectile dysfunction.
February 20th, 2008 at 6:45 am
I am already autogenerating html and soon js, using one of the popular scripting languages. Later I will add caching of content and a human-readable restful API (sounds like buzzwords, but in actuality this all makes life easier for a developer AND humans)
In this regard I dont care much how HTML5 will gonna look because I can adapt its stuff quickly.
But i TOTALLY agree with you on a general simplification – the more there is to read and implement, the longer it will take me to do so, and thus I have a natural interest to strive for simplicity.
February 20th, 2008 at 7:17 am
“You haven’t really provided rational arguments”
Ah, this type of argument is very typical in HTML5-land. I do not have to count skin cells on the elephant to complain about its size. Most of the things I’m complaining about aren’t even HTML elements!
“The sections ‘offline Web applications’ and those about client-side (database) storage are fundamental to HTML5″
They’re neat features, and work on them does not have to stop, but I think HTML elements are fundamental to HTML5.
February 20th, 2008 at 8:28 am
If you do not provide arguments why they should be removed then a simple “nuh uh” should suffice as counter-argument.
February 20th, 2008 at 11:27 am
WYSIWYG editors are bloat? Wasn’t the reason they were included because all modern browsers support them in some way, so it should be standardized to make things work across browsers? Wasn’t that the goal of HTML5?
February 20th, 2008 at 11:38 am
Jared,
I don’t think SQL and TCP sockets belong in the HTML spec, just like they don’t belong in the CSS spec. It’s possible to rationalize any inclusion, but that doesn’t make it a good idea. Besides, it’s not like I’m proposing cutting the spec to the bone. It would still be huge.
Dan,
WYSIWYG editors obviously provide valuable features. But I’m a conservative guy, and I think it would be best to define the syntax they edit before defining the editing APIs themselves.
February 20th, 2008 at 6:13 pm
I totally agree with carving down the ambitions to some small implementable subset.
Sorry you picked my fave feature, repetition templates. It’s basically the whole reason I care about HTML 5. Needing a variable number of input form fields often is the only reason for having javascript on a page. RTs make it possible to eliminate that javascript and for the first time accurately model real world forms.
Sigh. Just like everyone, I have to defend my pet feature. I imagine there’s a blogostorm brewing out there.
February 20th, 2008 at 9:37 pm
If anyone wants to volunteer to edit any of these things or any of the other specs that need an editor:
http://wiki.whatwg.org/wiki/Companion_specifications
…then please do let me know, I can help get you set up. Until someone volunteers, though, I’ll keep those sections in the HTML5 spec where they can make progress. There’s no point delaying progress on the Web just because it makes a spec a bit bloated.
February 20th, 2008 at 9:44 pm
I don’t think those specifications are very related to the parts of the HTML5 spec I objected to.
I don’t see a huge, unstable document with no change control procedures as “progress”.
It used to be a smaller document that worked on defining /HTML/. I really liked that document and I want it back.
February 21st, 2008 at 12:08 am
Given the pathetic rate of standards support by the largest browser vendor in the market, I think we are going to be better off waiting, getting the full spec worked out and then advocating for it’s implementation.
If CSS is anything to go by, a cut down HTML 5 might be implemented by MS in IE9 and then following HTML 5.1 by IE 10 which is going to like 2012? sigh
February 21st, 2008 at 3:46 am
Fwiw, the last time I tried to raise an issue on the HTML5 spec, I get an answer back something like 7 months later, which is completely useless to me at least.
February 21st, 2008 at 7:34 am
If you don’t think parts of the HTML5 spec belong there and you can’t find a companion spec where they belong, feel free to
(a) decide which existing spec would be the least-bad place for them, or
(b) propose the creation of yet another spec for them
…but just saying “I don’t care where they wind up as long as they’re not in HTML5″ leads me back to Ian’s response– I’d rather see these proposals moving forward than abandoned, especially when your rationale for removing them from HTML5 seems to be “I don’t care about them”.
February 21st, 2008 at 10:29 am
Peter, that’s quite intellectually dishonest. I’m claiming the spec is way too big to make useful progress, and you’re claiming that I must take responsibility for every vendor’s pet feature if I want that to change. No thanks.
February 21st, 2008 at 8:10 pm
[...] the question of HTML5’s ridiculous scope creep is broached, Hixie changes the subject. I don’t think we need to agree on everything, but I appreciate straightforward [...]
March 6th, 2008 at 6:37 pm
Rob, I think your irresponsible call to remove IrDA support from Web browsers will only cement Microsoft’s continued dominance of the Internet. What can you be thinking?
Oh, and little puppies die every time you type.