Is It Time for a 'Kinder, Gentler HTML'? 382
jg21 writes "Via the Web 2.0 Journal, a worthy link to Yahoo! Architect and JSON inventor Douglas Crockford's latest ideas to fix HTML. He's categorically not a fan of HTML 5, which is still just an Editor's Draft and not endorsed by W3C yet. Crock puts forward ten ideas that in his view would provide extensibility without complexity, adding that the simplification of HTML he is proposing would reduce the cost of training of web developers and incorporates the best practices of AJAX development. From the article: 'The problems with HTML will not be solved by making it bigger and more complicated. I think instead we should generalize what it does well, while excising features that are problematic. HTML can be made into a general application delivery format without disrupting its original role as a document format.'"
XML has some benefits. (Score:5, Interesting)
This sounds great, but I feel that by turning HTML into a more well-formed document (i.e., XML instead of SGML), the W3C did browser writers and developers a service. Please, let's not go back to the "guess if there's a closing tag" game. I don't mind the script, frame, module, CSS, encoding, and entity changes, but the custom tags/attributes and looser format limits (quoting, ending tags) seem bad.
Re:Not Impressed (Score:5, Interesting)
Re:Not Impressed (Score:5, Interesting)
When will HTML 5 be finished?
It is estimated that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004.
http://wiki.whatwg.org/wiki/FAQ#When_will_HTML_5_be_finished.3F [whatwg.org]
That seems like a really long time for something like this to go through, even for something as massive as the web standard.
Re:Not Impressed (Score:4, Interesting)
Looks to me like you only read for one minute ;-)
To give the limited amount of credit due, he does go on to some decent sounding suggestions. Nothing in there is actually unreasonable, some things sound like a good idea (UTF-8, browsers stop trying to correct for crap pages if version>=5). I'm still reading the stuff on Modules, or will be when the server responds :(
Perhaps someone else can try to fix the other things you mention.
Justin.
Re:Not Impressed (Score:4, Interesting)
Re:"Kinder Gentler," What the Hell Is That? (Score:4, Interesting)
GHWB (not to be confused with GHB, which can be metabolized from certain toy paints) was made fun of a lot for one of his campaign mottos, which was "It's time for a kindler, gentler America." Dana Carvey made gravy from spoofing GHWB on SNL, and the "kindler, gentler America" bit was an instant classic.
And this brings me around to my point. That's a separate problem. Admittedly, I'm not a web developer, but it's rather obvious to me that there are very useful changes in HTML5, and ignoring the possibility of improving web standards in favor of attacking non-compliant browsers is not smart. Far better to address both problems -- besides, how constructive is "attacking" non-compliant browsers? In my experience, attacking others is usually not constructive.
In short, I feel like you're making a big statement about best policy with a limited understanding of what's going on. I know for certain that I don't have full knowledge here -- but I'd never claim I know the answer.
But, you know, it's always nice to karma-whore by ripping IE. Sure, IE development may make extra work for you -- but then again, you're being paid for that work. Why not be happy that "that cowboy Internet Explorer" helped you find gainful employment?
Why not just... (Score:5, Interesting)
Without breaking Slashdot tradition and reading TFA, why not:
Re:Not Impressed (Score:5, Interesting)
Actually, he's proposing MORE problems. Here's my take...
Why? Adding a "version" attribute it just going to break compatibility. The "web" has enough problems with compatibility, lets not inject MORE. Doctypes work fine. Sure, it's long and doesn't appear to make much sense reading it, but... if it's not broke, don't 'fix' it.
I'm sorry but the auther hasn't presented any compelling reason why this is a 'good idea'(tm) and I can think of several reasons this is a 'bad idea'(tm). Do have I have to mention active X, proprietary languages, and 'broken' sites because of it? Then the need for Web.Devs. job skills increase significantly and become much more cumbersome.
Hmmm... I don't like frames per say. I don't use them. Though, I don't see how modules are going to make things better or easier but more complex. A frame was simple. A window in a window. That's simple. If Developers abused them, it's the developers fault, not the language for having it. With "AJAX" and Flash video, I'm game to just remove frames all together.
It already can be done and this is not the responsibility of HTML. This is as annoying as forcing ones religion on someone else. I'm not going to tell Microsoft they have to use Mozilla's default CSS. Or Apple to stop using their pretty buttons in Safari. Forget it. It's a non-issue. CSS RESET already exists, and developers need to just be educated. Design topics don't have a place in HTML.
While I want to say "I agree with that" because that's what I do, I think, again, "only" is not the right choice. Can we predict the future? Will UTF-8 be suitable 'forever'? Funny, computers original "only" supported latin characters. That wasn't a good idea. "only" supporting UTF-8 is also a bad idea, but I would like to see it used a default.
I agree with this.
I 100% disagree. Standards are standards. If we don't want browsers to "perform heroics" on correcting 'bad code' then lets not give people confusing "standards" of "it's ok to it like this... or like this... or this is 'ok' too!". No.
and . Tags are tags and they have a function. There are no "special" children. But I do think [script] needs empty tag support.
Agree.
What's wrong with "display:block"? If you want a [div] tag use one. If you want to make your own tag name, then don't try to make it a [div]. Div's are "block" elements. If you want a block element then "display:block".
I agree. But are we talking about HTML or JavaScript now? And why are you talking about JavaScript when you already said you don't want to support JavaScript? I'm confused as to your intentions.
Kudos for trying, but I think you missed the target.
Cheers,
Fozzy
Why do Yahoo developers think they know it all? (Score:4, Interesting)
Yet the Yahoo developers keep on trying to tell the rest of the world how to create web sites, or how HTML should look, etc.
The Yahoo developers should first build credibility by getting their own house in order before they try to instruct others how to do their job.
Re:Not Impressed (Score:4, Interesting)
In particular, their treatment of some Asian glyphs has some folks absolutely up in arms (cf. Han unification [wikipedia.org]) and it falls short of what I'd call truly 'universal.'
Start mandating UTF-8 and you're going to have people breaking the standard in favor of national charsets faster than you can say "cultural imperialist."
Agreed...HTML5 is a step backwards in many ways (Score:4, Interesting)
HTML5 seems to be doing a lot to make sure mediocre developers can stay in their comfort zone and to perpetuate many of the more serious problems we still face today. The HTML5 FAQ makes me cringe in many places!
* "no DOCTYPE. You may include one if you wish, though this is not recommended as they are only relevant when using a validating parser which web browsers do not have." - This is the wrong recommendation and a really stupid rationale. One cannot assume that web browsers will be the only clients to read your document, nor that all clients will lack validating parsers. This saves a small bit of work for lazy HTML authors at the expense of making
* "HTML 5 is being developed with IE compatibility in mind." - This is a backwards way to move forward with proper standards. You design applications towards standards, not standards towards applications. IE is already mostly compatible with existing standards--the solution is to make sure IE8 tows the line, not to bend over for IE developers. In the automation industry, there is a massive, complicated 8-headed beast of a standard called IEC 61158 that is a good example of what happens when applications drive standards. The IEC was somewhat stuck here however because they got into the game late, when all these battling vendor-developed systems were already established. With the Internet, though the situation is not perfect, existing standards hold a fair and increasing amount of influence. I believe the philosophies behind HTML5 don't do enough to prevent the perpetuation of tag soup and loose vendor-driven application of standards.
* "The details are still being worked out, but the plan is to indicate the maturity level on a per-section basis." - This puzzles me: They seem to be abandoning the "modules" approach being sought by XHTML in the interests of simplicity, however it is intended that user-agent developers will be implementing the standard "on a per-section basis" as they figure everything out along the way? And they expect this process to take TWICE AS LONG as XHTML did to establish itself as a ratified standard? I sense a lack of vision here--something along the lines of "lets look at what we've got, put Bondo on the dents and holes then spray it with Tremclad to make it look pretty". Not only that, they've decided that they'll work on the right fender and the left door this year, then the rear bumper next year and so on. There's nothing wrong with incrementally ratifying standards, but how about some VISION and PLANNING? Define some modules and their scopes then set teams upon them to tackle them individually and have them ratified as they reach maturity, and do so in a logical fashion (some sort of "core", then forms, then scripting, etc)
* "Void elements in HTML (the new name for empty elements) do not require a trailing slash...However, due to the widespread attempts to use XHTML 1.0, there are a significant number of pages using the trailing slash"--yet ANOTHER wrong recommendation and faulty reasoning. Lazy HTML authors are annoyed by the slash, but it's been part of XHTML for years so there are a lot of web documents that use it, so HTML5 parsers will have to continue to parse tag soup and do the "guess if there's a closing t
Re:Not Impressed (Score:3, Interesting)
What I am arguing for is a styling language that doesn't suck balls. I've been doing CSS since forever, and I'm finally completely fed up with it. It solves a few important-to-solve problems, but causes multitudes of problems of every degree of severity.
Re:Not Impressed (Score:3, Interesting)
Don't bother reading this article (Score:1, Interesting)
1 use fewer characters by eliminating robustness (one attribute instead of a whole doctype, one meta tag instead of specifying each script language)
2 eliminate features that tend to lead to vulnerabilities
The author forgets, doesn't know, or doesn't realize, or doesn't care that each of these things translates into real power when one uses them correctly. He also doesn't understand that if you allow for dummer developers, there will be more exploits not fewer.
He outright eliminates document.write and frames saying that they are insecure. And he outright says that frames are to be rebuilt into modules. Sir, I'm glad that you have devised solutions to your struggles, but please do not push them onto the rest of us who enjoy certain levels of power through the use of multiple script languages and weird frame power.
Incidentally, for your education Sir, I think you've forgotten a very import part of programming and computers in general. You can't simply say that all web pages should be in UTF-8. First, good job thinking that UTF-8 is the last ultimate character set. Second, good job completely destroying every existing page out there. Third, good job making every single english-only page twice the size it needs to be. You've eliminated optimization completely. I'd have rather gone the other way and allowed the developer to define a character set -- I don't know, maybe through the doctype that you've blown away.
Meanwhile, you haven't added the one thing that I've been wanting ever since IE kind of lost it -- embedded fonts. A quick and easy way to eliminate 95% of graphics used to present navigation text and teeny tiny little wingding icons.
I've got no problem making things easy by granting additional power, or abstracting power to developers. But to eliminate complexity with the goal of eliminating features is just, well, it smacks of someone who's never managed to find a use for that power.
Having built HTA applications that flex three script languages, javascript domains, and at least a dozen iframes on each "page", I can say for certain that your changes (i.e. restrictions) would have rendered my applications impossible to build.
All of that said, I can't argue with making custom tags and attributes first class, except to say that it would be nice if FireFox supported custom (read expando) attributes in the first place, and that custom tags and custom attributes would be a much greater source of vulnerabilities due to parsing errors than incomplete attributes ever were.
Umm, JSON inventor? (Score:3, Interesting)
doctypes, frames, and learning html (Score:2, Interesting)
DOCTYPES:
Doctypes aren't implemented correctly on probably 98% of the documents on the web because none of noob web designers fucking understand them - so anything 20 years from now won't be able to trust them, we might as well eliminate them and replace them a simple version #.
UTF8: YES YES YES!!! OMFG
LEGACY SUPPORT + FRAMES/IFRAMES:
I agree browsers aren't going to drop fields like iFrames, etc. BUT as an administrator I could turn it off for my clueless users who might be mislead, hurrah! I have no problem if they can't access their mutual funds/bank account from company computers. I might turn it off for my parents so they don't get h4xx0r3d, eventually norton and mcafee can warn people who are visiting sites using pre version 5 that it is "less safe"
LEGACY SUPPORT = "Not more secure"
Not true -- first off HTML 5 only can be an option if users need to access a subset of intranet sites. I think marketing HTML 5 as "simple, more secure" might get CIO types to mandate more use of it in their organizations.
Furthermore older browsers could (when possible) use a translation engine to convert HTML 4 to HTML 5
Keeping the ecma-script + dom engine further from the "quirky" content makes a ton of sense to me. Anybody who doesn't believe that separating phases adds security need only look at apps like Qmail, etc.
RE: HTML IS NOT BROKEN
HTML 1.0, 2.0 were easy to learn - and THEY are the reason HTML is successful. Anybody could pick up a book and in a few hours be building HTML pages.
HTML 4.0 / XHTML was clearly defined by a committee of people who don't actually work in the "real" world try to support users.
The more complicated you make it, the less people can/will use it. I realize slashdot does not necessarily cater to that audience, but most people think they are dumb and don't like learning/a challenge -- and I personally hate troubleshooting their X-HTML documents.
NEED PROOF HTML IS BROKEN = LEARN WIKI:
The reason we see so many systems switching to WIKI content management versus HTML is because of all the issues and learning curve associated with HTML, and how easy it is to break HTML.
In fact the majority of the new original **content** being added to the web these days is probably in WIKI simply because HTML is broken.
You have to admit that nobody would have invented WIKI if we were still using HTML v1 or v2.
Re:Not Impressed (Score:3, Interesting)
Amen!
CSS3 will hopefully help a bit with the mess but I'm not positive that it will bring us back
to the days of straightforward table-hacking. Yes, tables were ugly, non-semantic and introduced
quite some maintenance nightmares. But they worked consistently across browsers and the pattern
was so trivial (need a split? nest!) that even complicated layouts could be prototyped in no time.
Now fast forward to today. Hands up anyone who has gotten a CSS layout of moderate complexity
to work without spending an ungodly amount of time on trial & error, css- and browser-hacks?
The separation of code and layout is indeed a holy grail worth aiming for.
But the implementation we're looking at, namely CSS, is horrible.
So horrible that the people who really need to get anything done with it
are nowadays resorting to CSS frameworks. Which, by pure coincidence,
simply do away with all the semantics, em-sizes and quite a few
other selling points of CSS. In favor of something that looks
strikingly similar to what we have all been doing until a
few years ago: A truckload of nested div's imitating the
plain old table markup that CSS was supposed extinguish.
Welcome back to 720px fixed-width tables, only that nowadays
it's called the 960px YUI grid and that nowadays you need
to either use a code-generator or learn a proprietary
meta-language (css classnames) to get started.
I dare to say that CSS, in it's current incarnation,
is a failure. Sure, it works for really simple layouts,
the "one floating menu bar and not much else" kind
of layouts. But it falls hard on it's nose once you
enter the world of multi-column layouts or anything
involving forms.
It doesn't cease to amaze me how CSS and the box-model could
go so wrong on a problem that has already been solved better
by just about any windowing toolkit in existence.
It's really not hard to come up with a working concept and
syntax of a grid (yes, a real grid, not the css hackery),
full relative positioning (put this box *below* that box),
inheritance (make this box as wide as *that* box) and
all the other elements needed to describe any imaginable
layout in a sane syntax.
It's not hard at all once you clear the failure that is
CSS from your mind and start again.
"Not hard" as in a qualified design team could do
it in under a year.