Apps

HTML 5: A change in course... straight for the iceberg

Justin James explains why the recently released working draft of HTML 5 is the worst specification he's ever read.

The W3C recently released a working draft specification for HTML 5. In its current iteration, this is the worst specification I have ever read. In comparison to HTML 5, I take back everything that I said about SMTP -- at least SMTP knows its role and sticks to it. HTML 5 is a 15 year leap backwards; it's also a transparent attempt to pander to the current tool vendors, in a format that is so incredibly "right here and now" that it is not a durable standard to carry us through to the future.

HTML 4 had an obvious and clear goal. The HTML standard started out as being extremely screen specific and lacking in styling ability. Tags such as <i> (italic) and <b> (bold) were specifically presentation items that carried no context. In other words, "Is that phrase italicized for emphasis, or because it is the title of a magazine?" The HTML standard has not kept up with the pace of browser development, and Netscape and Internet Explorer have introduced a variety of new tags and features that are helpful to Web developers and designers. HTML 4 pushed hard to make sure the HTML specification is a standard that provides context for text with the assistance of a dash of non-text resources such as images. It was up to CSS to transform the context into presentation. As a result, Web designers suddenly had much more granular control over design; Web developers had a way of extracting real meaning from HTML; and users could view HTML on a wide variety of devices and systems, and those viewers could render (with or without CSS) the pages as appropriate for that scenario. (The W3C has provided a helpful document that compares HTML 5 to HTML 4 and XHTML 1.)

HTML 5 takes this smart direction, locks it in a warehouse full of gasoline and ball bearings, and throws a match inside. Instead of taking a bold stand against the tool vendors, framework providers, and other vested interests and furthering the cause of device and software independence, the W3C decides to wed the HTML standard to the current trends in Web development.

The biggest example of this is in section 1.1.3. Relationship to XUL, Flash, Silverlight, and other proprietary UI languages: "This specification is independent of the various proprietary UI languages that various vendors provide. As an open, vender-neutral language, HTML provides for a solution to the same problems without the risk of vendor lock-in." Since when is HTML supposed to be a "solution" for the issues that those technologies try to solve? Do we really want HTML to become difficult for the disabled, hard for search engines to parse, and impossible to print? HTML 4 finally provided a good mechanism for dealing with issues like printing, and how to display content on devices that do not fit standard desktop monitor sizes. HTML 5 works hard to undo that progress.

Another good example of the sudden browser-intensive focus of HTML 5 is in the dependency disclaimer: "This specification does not require support of any particular network transport protocols, style sheet language, scripting language, or any of the DOM and WebAPI specifications beyond those described above. However, the language described by this specification is biased towards CSS as the styling language, ECMAScript as the scripting language, and HTTP as the network protocol, and several features assume that those languages and protocols are in use." So, what happens when I view HTML 5 that is stored as a file on a network server? What happens to systems that do not use ECMAScript (e.g., my printer) or a locked down Web browser or a search engine? Should the page fail to render properly, or should it just stop working?

To say that HTML 5 is trying to displace things like Flash and Silverlight and make AJAX the dogmatically pure method of client-side interactivity is putting it mildly. HTML 5 introduces a slew of new elements that play right into the hands of vendors looking to give us even more kludgy tools. Instead of writing hacked up ECMAScript to perform client-side validation (backed by server-side validation), we now have methods to "enforce" validation on the client side. I'm sure that hackers will ensure their scripts follow the input restrictions; meanwhile, less savvy developers will think their code is protected from bad input. I bet Sun and Microsoft are champing at the bit to introduce new versions of J2EE and ASP.NET that specifically generate the new HTML 5 "datagrid" element; or to introduce the new attributes for the "input" element that let the developer specify if a text box is for an e-mail address, date/time, and so on. We don't need a version of HTML that is tightly bound to both client-side scripting and server-side programming. And can anyone explain to me why: HTML 5 has APIs and, specifically, APIs for persistent storage; a "draggable" attribute for use with a drag-and-drop API; or APIs that address something as specific as the "Back" button?

I know why the writers felt these things were needed, but they are not necessary in the HTML specification. The writers made efforts to address the weaknesses of the currently in vogue AJAX methodology (which exists to address the weaknesses of the HTML-as-an-application-framework concept).The HTML standard is compensating for a problem with the things used to compensate for HTML's perceived "problems." The "problem" with HTML is not that it is lousy as a method for defining GUIs -- it's that people are using HTML to do what Flash, Silverlight, XUL, etc. are for. This is sheer idiocy on the part of the W3C. The HTML standard is a document standard -- not an application framework standard.

There are some good items in HTML 5. The draft continues to reverse the frameset mess (iframes still exist, which is fine with me). There is a new tag for "audio" and one for "video", which makes more sense than having to embed a reference to a media handler object or a Flash player; this is something that I have supported for a while. But these few bright spots are simply not enough to redeem to draft.

The only people and institutions I see benefiting from this draft of HTML 5 are tool vendors. For years, the tool market has been fairly stagnant when it comes to HTML editors. The real focus has been on a multitude of frameworks to do things like compile static, server-side code into client-side JavaScript, work with the client with AJAX frameworks, and so on. These have been nearly impossible to bake into the HTML editors because all of their functionality was outside of the spec. But with the HTML 5 draft, I am sure that tool vendors are drooling at the opportunity to make "new and improved" HTML 5-compliant editors that combine their proprietary backend of choice and their proprietary client-side framework of choice and use the new HTML 5 features as a bridge between the two.

Am I being paranoid about the motivations behind the HTML 5 draft? Probably. The stated reason for the direction of the changes is to bring HTML 5 inline with the current state of the art. This is the entire problem. I think the current state of the art is an unwieldy kludge and bringing the HTML standard into collusion is simply aiding and abetting.

The final irony in all of this is that the HTML 5 draft makes the vision of Web applications displacing desktop applications all the more likely. After all, the inclusion of Flash/Silverlight/XUL-like UI functionality in the HTML spec itself can do nothing but help spread Web applications. It's a shame that the true goals and principles of HTML have been thrown by the wayside. This UI-centric draft is ripe for vendor-specific add-ons, extensions, and hacks -- this will send us to the bad old days of "this site best viewed with..." logos. HTML 4 has been great for the industry and has been good because it allowed HTML writers to learn it, let the tools to catch up, and the browsers had a chance to become extremely compliant (some better than others).

The current HTML 5 is the wrong draft at the wrong time. I hope the W3C wakes up before it's too late and redrafts HTML 5 to continue the good work of HTML 4 instead of trying to become a "me too" attempt at UI abstraction.

J.Ja

About

Justin James is the Lead Architect for Conigent.

63 comments
cgarcia109
cgarcia109

HTML was designed as a way to define documents. Dynamic Html was not bad as it helps to reinforce the presentation of the document. But this... HTML 5 is not a markup language but an complete API to write applications, making HTML Viewers some kind of Virtual Machine to run HTML 5 apps. Whats next, they will write some kind of sub HTML spec so their HTML5 api can define documents. And that thing about making direct TCP connections is just ridiculous. even more ridiculous W3C havent refused this spec straight. Seems most of the ppl back of this spec was google ppl, like if web designers come to write specficications with their designer pens. This is specification is good, but this has nothing to be with HTML. For this just write a direrent specification for web applications. But dont use HTML name, that doesnt have a point.

sinema_86
sinema_86

hi ay think A~A~A~A~A~A~A~A~A~A ay dont no A~A~A cool's

seanferd
seanferd

I remember my first beer... ;) So, how is HTML5 being received in Armenia? Side note: You may wish to avoid posting your e-mail address in the wild. Spammers can find you that way.

techrepublic.com.com
techrepublic.com.com

Hello -- I'm the editor of the HTML5 spec. I thought I'd respond to some of your comments. You ask: "Since when is HTML supposed to be a ???solution??? for the issues that those technologies try to solve?" Since the early 2000s, when Web applications became really common. Even this very Web page, with its comment form, is an example of this. On the other extreme we have Web-based graphical games like voidwars.com, we have applications like Google Calendar, and so on. HTML has been a solution for application authors for years, HTML5 merely fixes some of the problems this has caused. "Do we really want HTML to become difficult for the disabled, hard for search engines to parse, and impossible to print?" The Web is already difficult for the disabled, search engines are already having troubles with Ajax-like sites, and printing has been an issue with scripted HTML for years. HTML5 actually tries to address these problems (especially the accessibility issue). Many parts of HTML5 are entirely aimed at fixing these problems. If you have specific concerns with areas of the specification that actually make practical accessibility measurably worse, please don't hesitate to let the working group know. For details on how to join the W3C HTML working group, please see: http://www.w3.org/html/wg/ Anyone can join, and all are welcome. Regarding your other concerns, they seem mostly based on misunderstandings of the spec. For example, the spec doesn't require JS, it just points out the reality that the Web uses JavaScript, and that therefore that was an assumption when the spec was written. By the way, the spec used to be called "Web Applications 1.0". That may help explain why it addresses the needs of Web Applications. I think if you want HTML to not address Web Applications, you may be too late -- the Web has moved in that direction already, we're just filling in the wholes to prevent the Web app developers from moving to proprietary platforms. It's better for everyone if the Web keeps being open and free.

lcosma
lcosma

Ok, to all of you who say: "let's have a new standard for web apps, and leave HTML for its original purpose". 1. Can anyone imagine any new standard being embraced by the zillion web developers out there with enough vigor that browser makers would include that in their browsers and it would thus become ready for practical use? 2. Today it's Web 2.0 (whatever that is). Tomorrow it will be Web 3.0 (whatever that may be). You don't have a standard for putting it on the shelf. If many % of the zillion web developers use HTML for a purpose that was not intended what do you want to do? I prefer to have an adjusted HTML standard that follows (and standardizes) the trend AND would like to see the browsers evolve to provide more powerful UI controls. If you DON'T have these, THEN you'll end up with proprietary MS Silverlight and Adobe AIR and so on. 3. Is there any problem in having an enlarged standard? Nobody must use the new APIs or controls if they don't need them. Or if you fear that these may make your page less accessible for search engines. But dynamic web apps (the kind that cannot be created with xml/xslt/XHTML & CSS and without JavaScript today) are not meant for search engines. So I'm looking forward to HTML 5 being finished. That is: "The HTML 5 specification will not be considered finished before there are at least two complete implementations of the specification." :)

lcosma
lcosma

Well, maybe I'm wrong in assuming that there are so many web developers who would like the standards and browser support evolve in the specific direction I mentioned. Maybe HTML 5 doesn't even go in the direction I thought it would, and I'll not be satisfied either :). Absolutely - you are maybe right about Dreamweaver and Frontpage users (I wouldn't know about that); still, browser makers would need to include support for that standard. "On the shelf" - I meant like "some object you have but don't really use" (sorry if the expression was confusing). "follow trends and standardize" - I believe this is what HTML 3.2 and HTML 4.0 did (inspiring from Mosaic, Netscape and IE). "what kind of controls" - I meant the standard "input", "select" etc., and new, more powerful browser-supplied standard controls. GWB - no comment (I remember though I used to like WJC :D ). "Calibrating standards to average performance, instead of to excellence, is a terrible idea, with terrible results." - couldn't agree more. It's just that, IMHO, the HTML standards should always consider the trends in web development, because these in turn come from users' needs. At the same time, they obviously should be high standards :).

lunakid
lunakid

"What ''new, more powerful browser-supplied standard controls'' are needed, specifically? I just don't see a real shortcoming in the existing standard's ability to accommodate good programming." Uhh-ohh... Perhaps you should ask just about any of the poor souls sitting around "programming" all those horrid, crippled, annoying and disgustingly malfunctioning "100% [W3C] compliant" interactive web sites around. Last time I checked, one could not even save/restore a cursor position on going back to an edit box after activating a Save button. Not to mention the W3C-incompatible evil idea of using Tab in a multi-line editor for the purpose it was invented for (i.e. indenting text). And a *million* of such incredible omissions that make it virtually impossible (= unreasonably hard and error-prone) to create reasonable GUIs on top of pure HTML. Certainly not funny using just the raw HTML(4) widgets! -- This (improving, amending the raw ones) is most likely what that guy (you are arguing with) referred to. Others might add more details -- I'm not even a web developer (mind you: partly for the EXACT reason of the incapable HTML UI model (yes, with CSSx and even adding JS), and all the kludging hell of this whole "industry"). Certainly, It's *not impossible* to work around most of the shortcomings of HTML: that's exactly what Flash, ActiveX, Java, AJAX, Silverlight etc. etc. have been doing. (GWT is almost a miracle, and still is far from being a smooth, light, streamline GUI experience. But you can at least get used to and appreciate it compared to most others.) So, good luck advocating "well-programmed" platform independent, sophisticated GUIs (anything more than "My TEXTAREA Example" sites) built on the existing features offered by the HTML-compliant browsing platform. Even empowered with JS, it is tremendously more difficult than it sould be (telling it as an experienced application developer). That being sad, I do agree with J. Ja.: HTML5 should not try to be a miracle cure for every illness of the web. Not even if those are mostly caused by its previous versions. (Yeah, I can also sense this flanging between the odd/even versions, with the "guilt" of previous version distorting the "fixes" in the next ones... ;) ) And, as any HTML versions fell short of any kind of "state of the art" GUI techniques (always straggling to define some still-useful-minimum for the widest of platforms), even the current shift of HTML5 will not even near be enough (especially by the ~2020 target ;) ) to suddenly becoming an innovator in GUI ergonomics. To sum it up: HTML4 and XHTML being flexible doc standards are fantastic. HTML5, however, is getting overly complex as such, while as an app standard it will still remain notoriously lacking. However much HTML5 is said to be a "balancing act", combining both (and many other contradicting aspects), it is, as my father used to say, just not possible to fuck and to remain virgin at the same time.

Absolutely
Absolutely

[i]Well, maybe I'm wrong in assuming that there are so many web developers who would like the standards and browser support evolve in the specific direction I mentioned.[/i] I'm sure there are business interests in doing more transactions, and selling more advertising, on the web. I don't believe that the web developers who do the work coding the pages are enthusiastic about a new set of standards, and even less about the particular, current standards draft for HTML 5.0. [i]"what kind of controls" - I meant the standard "input", "select" etc., [b]and new, more powerful browser-supplied standard controls[/b].[/i] This is what I'd like you to describe in as much detail as possible. What "new, more powerful browser-supplied standard controls" are needed, specifically? I just don't see a real shortcoming in the existing standard's ability to accommodate good programming. [i]It's just that, IMHO, the HTML standards should always consider the trends in web development, because these in turn come from users' needs.[/i] I'll get back to that, depending on your reply to the type of controls that should be added. PS. re: "on the shelf," that is actually a familiar expression, I just didn't recognize it in that context. Thanks for explaining.

Absolutely
Absolutely

[i]1. Can anyone imagine any new standard being embraced by the zillion web developers out there with enough vigor that browser makers would include that in their browsers and it would thus become ready for practical use?[/i] You're talking about FrontPage & Dreamweaver users. They will embrace a new standard when that standard is included in the next version of their chosen software. They will also embrace a host of competing, automated "conversion" software products, most of which will require employment of specialized, actual coders to re-write the "converted" code to be usable. [i]2. Today it's Web 2.0 (whatever that is). Tomorrow it will be Web 3.0 (whatever that may be). You don't have a standard for putting it on the shelf.[/i] What? "On the shelf?" I think that's either a Romanian, or European expression that isn't used in the 'States. I know I don't know what you mean. [i]If many % of the zillion web developers use HTML for a purpose that was not intended what do you want to do? I prefer to have an adjusted HTML standard that follows (and standardizes) the trend[/i] Pick one; it is not possible to follow trends and standardize. It is an either/or proposition. [i]...AND would like to see the browsers evolve to provide more powerful UI controls. [/i] Why? What kind of controls? It's like people are not even paying attention to the fact of computer viruses. Sending a command using an insecure medium, such as the Internet, is inherently risky. Sending [b]an important command[/b] over such medium is inherently stupid. Publishing "standards" for them implies -- falsely -- that transactions performed using those controls are handled in a "standard" way. You and I know that there is more to it, but the end users who do not learn to program only hear that there are "standards," and are misled. [i]If you DON'T have these, THEN you'll end up with proprietary MS Silverlight and Adobe AIR and so on.[/i] Are you suggesting we can avert or get rid of those? [i]3. Is there any problem in having an enlarged standard? Nobody must use the new APIs or controls if they don't need them. Or if you fear that these may make your page less accessible for search engines.[/i] The Scholastic Aptitude Tests administered to United States high school students have been "dumbed down" progressively, making higher scores less challenging, every year since before I took them. The result: an electorate that put GWB in power, and thought he was a great guy, for several years. Calibrating standards to average performance, instead of to excellence, is a terrible idea, with terrible results.

Justin James
Justin James

"Calibrating standards to average performance, instead of to excellence, is a terrible idea, with terrible results." You nailed it. Ratifying *current* state-of-the-art is never the way to create a lasting, durable standard. J.Ja

Tony Hopkinson
Tony Hopkinson

are already making a p1ss poor job of designing static web pages. There's too many options for them now, most can't even get them in the right order. Now a better and richer set of standard control implementations in browsers, would destroy a lot of the so called reasoning behind web apps. People didn't start using applets and activeX for avoiding deployment issues, they did it because they wanted a blue button with rounded corners and icons that changed based on it's state.

Justin James
Justin James

Thanks for the response. It's good to know that the W3C is keeping their ears open to feedback, and not operating in a total vacuum. I do have some rresponses to some points you brought up, though. "Since the early 2000s, when Web applications became really common. Even this very Web page, with its comment form, is an example of this. On the other extreme we have Web-based graphical games like voidwars.com, we have applications like Google Calendar, and so on. HTML has been a solution for application authors for years, HTML5 merely fixes some of the problems this has caused." I beg to differ. There is a gulf of functionality between what I term a "dynamic Web site" (which this forum form is) and a "Web application" (which Outlook Web Access is a great example of). I beleive that HTML should stop at the near border of "dynamic Web site" and that something else (which should be a standard as well, I may add) should be doing "Web applications". The nature of the HTTP protocol makes the replication of traditional GUI functionality extraordinarily difficult, regardless of the presentation abstraction involved, whether it be XUL, Silverlight/XAML, Flash, etc. "Many parts of HTML5 are entirely aimed at fixing these problems." Sadly, too much of that work is reverse by trying to MIG weld HTMl to the concept of "application". The moment an HTML document requires user input to function properly, you've lost all accessibility. The current state of affairs is no reason to accelerate the issue. "If you have specific concerns with areas of the specification that actually make practical accessibility measurably worse, please don't hesitate to let the working group know. For details on how to join the W3C HTML working group, please see: http://www.w3.org/html/wg/ Anyone can join, and all are welcome." According to the site, it seems that the *only* way to participate in the HTML 5 process is as an "invited expert". I may be mistaken. I would be delighted to participate in the process. Please let me know if I must be invited. If I do not need to be, I will gladly join. If I do need to be, I will be happy to accept an invitation if one is offered. "Regarding your other concerns, they seem mostly based on misunderstandings of the spec. For example, the spec doesn't require JS, it just points out the reality that the Web uses JavaScript, and that therefore that was an assumption when the spec was written." It really does *not* sound like I misunderstood this portion of it. If there is the assumption that a JavaScript interpreter is present, then it means that the spec is, in a nutshell, saying, "this document has the right to not work properly without JavaScript being interpreted". In other words, "search engines, those with accessibility concerns, printers, cell phones, etc. need not bother". "It's better for everyone if the Web keeps being open and free." This is *precisely* the reason why the current direction of HTML is a bad idea. HTML needs to remain strictly devoted to being a document system (not an application system) for dozens of reasons. Trying to turn HTML into an application definition system re-opens the Pandora's Box that HTML 4 closed, the one opened in HTML 2 and HTML 3, but this time its filled with vendor "embrace and extend" from the programmatic view and last time it was the presentation view. HTML 4 was the first time that browser vendors universally worked towards closer adherence, not vendor specific divergence from the standard. Let's not encourage them to cease that just to be the first to market with "dumb UI widget 0.2 beta" and fancy new user-interaction tag. Does anyone else remember VRML? If they want to make applications, why don't they glom onto that standard instead? One could argue that a MUCH better alternative to the current "solution" to these issues would simply be to tunnel HTTP through a "wrapper" protocol which WOULD handle session information, force the issuance/receipt of requests in a sequential order within the session, and so on, and simply append the session identifier to the application server. This would eliminate the current mess of trying to bolt on sessions and statefulness to the HTML/HTTP combination. Again, I would love to formally participate in the HTML 5 spec process. Please let me know if I am able to or not. Thanks again! J.Ja

zcorpan
zcorpan

> There is a gulf of functionality between what I term a "dynamic Web site" (which this forum form is) and a "Web application" (which Outlook Web Access is a great example of). There's a gray area. I think the spec refers to to "dynamic Web site" as a "Web application". HTML5 probably doesn't solve all problems that Outlook Web Access faces. But it probably solves many problems that dynamic Web sites face when trying to use HTML4+CSS+JavaScript (like making the dynamic parts accessible when HTML4 doesn't have a concept for what you're trying to do). > According to the site, it seems that the *only* way to participate in the HTML 5 process is as an "invited expert". Self-invited... http://ln.hixie.ch/?start=1173385976&count=1 Or you can join the WHATWG which is easier: http://www.whatwg.org/mailing-list#specs Or join the forums if you hate mailing lists: http://forums.whatwg.org/ etc... there are many ways to participate. > If there is the assumption that a JavaScript interpreter is present, ... The assumption is that most Web browsers have JavaScript as their scripting language. This means that the APIs have to work together with JavaScript well. It does not mean that documents have a reason to go "Oh I refuse to work if you don't have javascript". Javascript is optional and as you say, e.g. search engines don't have it. It's quite possible to write documents that work without javascript (both with HTML4 and with HTML5).

techrepublic.com.com
techrepublic.com.com

Many developers seem to forget that not everyone looking at their site has access to Javascript. And it's not just limited to those who would fall under ADA, but also the myriad of browsers that are being embedded into all kinds of devices. Not all of them have a javascript interpreter.

apotheon
apotheon

"[i]The top four browsers -- IE, Firefox, Safari, and Opera -- have javascript as their scripting language. Not acknowledging this would be silly.[/i]" Fact: A browser that includes a JavaScript interpreter can still render pages that don't have JavaScript embedded in them. Fact: A browser that does not include a JavaScript interpreter cannot interpret the JavaScript. Probable: Producing a replacement for HTML 4 that incorporates JavaScript in the standard will almost certainly encourage people to produce more web pages that [b]require[/b] JavaScript. Key point: Accessibility matters. "[i]I don't understand your point.[/i]" That's obvious. Perhaps you're not familiar with accessibility as an important concern of web development. "[i]It appears that people don't have a problem with assuming this without HTML5.[/i]" Many people [b]do[/b] seem to have this problem. Many [b]more[/b] will probably have this problem when JavaScript becomes an integral part of the new HTML "standard". "[i]Regardless, HTML5 doesn't require browsers to have javascript, nor does it in any way encourage authors to assume that it is present -- quite the contrary.[/i]" Your claim strikes me as counterintuitive, especially given the difficulty people [b]already[/b] have remembering that many text-mode browsers, search engine spiders, and screen readers for the disabled cannot parse JavaScript effectively. "[i]It is not [part of the HTML spec].[/i]" Please join the current discussion about HTML 5. "[i]Indeed, and this is exactly what is being done.[/i]" You're going to have to explain that one.

zcorpan
zcorpan

The top four browsers -- IE, Firefox, Safari, and Opera -- have javascript as their scripting language. Not acknowledging this would be silly. > I actually use one that doesn't have a JavaScript interpreter buried in it, semi-regularly. So? Should HTML5 *not* be designed so that it fits together with javascript just because you use a browser that doesn't support javascript semi-regularly? I don't understand your point. > Now imagine that people start using HTML 5 with an assumption that all browsers have JavaScript interpreters built in. It appears that people don't have a problem with assuming this without HTML5. Regardless, HTML5 doesn't require browsers to have javascript, nor does it in any way encourage authors to assume that it is present -- quite the contrary. > JavaScript is not HTML. And DOM APIs are not javascript. > Why should we treat it as though it's part of the HTML spec? It is not. > There's nothing that says we cannot combine the technologies described and defined by more than one standard without having to have one of the standards incorporate the other in any way. Indeed, and this is exactly what is being done.

apotheon
apotheon

> "[i]The assumption is that most Web browsers have JavaScript as their scripting language.[/i]" I actually use one that doesn't have a JavaScript interpreter buried in it, semi-regularly. I pretty much never have all my Firefox tabs cleared when it's time to shut down the browser before switching to a new location (and thus a new network) with my laptop. I then reopen Firefox with all tabs opened again as they were when I shut it down, so I can pick up where I left off. Since some networks do some kind of asinine browser-based "you're connected to our network" redirect, requiring one to accept a cookie before talking to the Internet, I need to use a secondary browser sometimes. If I just open Firefox right away, it'll replace all those webpages I was previously viewing with a bunch of duplicates of the redirect target, thus losing all the websites I had in tabs. If I open Lynx first, I can do the stupid cookie-accept there, then open Firefox without having to worry about losing those websites. Now imagine that people start using HTML 5 with an assumption that all browsers have JavaScript interpreters built in. Suddenly, I'll probably have problems using Lynx to get around that cookie problem. JavaScript is not HTML. Why should we treat it as though it's part of the HTML spec? If you want a JavaScript standard, write one. In fact, we've already got an ECMAScript standard. Leave well enough alone, please. There's nothing that says we cannot combine the technologies described and defined by more than one standard without having to have one of the standards incorporate the other in any way.

apotheon
apotheon

"[i]Does anyone else remember VRML? If they want to make applications, why don't they glom onto that standard instead?[/i]" VRML isn't an application development markup language; it's a 3D interactive modeling language. Basically, it's for the same thing as HTML, but in 3D.

apotheon
apotheon

HTML4 and XHTML are interactive in much the same sense.

Justin James
Justin James

Yeah, it's the "interactive" part that led me to that comment. I haven't seen anyone use VRML since the does when IE had an add-on to interpret it, but my memory was that the handling of stuff like clicking around was supposed to be part of the spec. Then again, the spec was also written when everyone was trying really hard to replicate "Neuromancer". See what happens when you try to write a spec around "what everyone is already doing"? ;) J.Ja

Tony Hopkinson
Tony Hopkinson

platforms. No may be about that one, you are too late. About a decade or so. Adrresses the needs of web applications, or merely endorses vendor specific extensions to HTML4?

Jaqui
Jaqui

and effort by the W3C. They should have just stuck with the XHTML specification, moving it from XHTML1.1 to XHTML2. Those new points that are appropriate for a document MARKUP language specification could just as easily been added to it. Plain old HTML should be buried with the garbage from January 2000, when XHTML was released. edited to add: Since XHTML adds the flexibility of the XML specification to the Hypertext Markup, and XHTML1.1 makes it even more modular, so you don't have dtd data for sections not being used in that document it is poised to be the definitive standard to meet the curent treds in website design and development, more than HTML can ever do.

Justin James
Justin James

If I read HTML 5 correctly, they merged XHTML and HTML in the HTML 5 document, so that it is essentially a syntax swap to go from one to the other (like added a doctype in one vs. a DTD reference in the other). So while I am inclined to agree with you, the HTML 5 spec makes that even less likely to happen. :( In other words, no XHTML 2, just an XML representation of HTML 5. Bleh. J.Ja

Jaqui
Jaqui

XHTML was a better start at an application language spec than HTML could ever be. though, since html5 i just a draft, it is still malleable, they could fix most of the problems with it.

Pentagear
Pentagear

If your client doesn't want any of that but they want some super awesome web app. What's the point? The technology exists for a reason. Just because they can't wrap their head around some bad experience from hiring a halfwit designer, doesn't mean the rest of us should have to suffer such a degradation of our livelihood. Ditch the client IMO. Not worth it to industry in the long run. Plus, if the client or even you as a developer can't understand that those technologies should only be used in a display capacity, the they or you shouldn't be in the web app industry to begin with.

Tony Hopkinson
Tony Hopkinson

will be doing the bulk of the work. So as usual you sign onto their site to give them your business and you pay for the privilige with your resources and your security. Good 'ere in it.

Absolutely
Absolutely

[i]... the turd, I was referring to was rich GUI web application with the currently abused tech.[/i] I'd probably have more fun exchanging insults with you, ya pinko queer, but I have no problem with any of that. What bother me more are servers that "script" operations on my processor that belong on theirs. Which side of that problem, generally, does the current html 5.0 draft favor, in your worthless opinion -- rich or poor clients?

Tony Hopkinson
Tony Hopkinson

the turd, I was referring to was rich GUI web application with the currently abused tech. My original subject line was Abs - the turd. Open to misinterpretation that was. :D

Tony Hopkinson
Tony Hopkinson

It's great as long as all the functionality you require is there. What usually happens is you get more than you need or less. So you are back to clunky square windows 3.1 textbox, or something like MSFlexgrid. You choose not to use clientside stuff for at least to me perfectly acceptable reasons, but you do give up what you can appear to do within a web app in recompense. You can't get the advantages of statefull with stateless. HTML5, is yet another futile attempt to do so in my opinion.

Absolutely
Absolutely

That's just not the purpose of html, as Justin said. Instead of making it a crappy document standard in the interests of making it an easier, but also crappy, application language for lazy programmers, maybe something else needs to be built from the ground up. It would still be possible to use the parts of HTML 4.0 that work just fine for these intended purposes, but remove the parts that aren't and replace them, creating a specification that's really suited to web apps, without crapping all over HTML's intended function.

Jaqui
Jaqui

the majority of it can be done without using active clientside scripting, for the ui. a nice example of the major element for the user interface like that: http://www.cssplay.co.uk/menus/fly_drop.html maintaining state, well I wouldn't want to do it with a cookies based method, ssl sessions would be better for reliability, but even slower. :D danged typos

Tony Hopkinson
Tony Hopkinson

with cookies. :D You'd have to give them a medal or consign them to a mental institution. At Client Server Hold on. Stop wiggling your mouse. Can't you see I'm busy. ffs..... So you miss some mouse moves how many, what state chnages were never triggered because the move was never processed by the server. An extreme example but this sort of thing is known to be flakey inside the windows message queue, firing them off to www.youngladiesinuniform.com hosted in Ghana is seriously not going to work, unless it's very very very sloooooow. Like you'll be finished and asleep before she takes her cap off. State small word, big place. It's wanting to do this on web pages that gave us activeX.....

apotheon
apotheon

State can be maintained via cookies or session IDs and server-side code like closures, global variables, et cetera (depending on the server-side language used). edit: It's not ideal, but it works.

Tony Hopkinson
Tony Hopkinson

Stateful communications? At a certain point of complexity without running alien code, you can't. HTTP is stateless, the standard UI controls are badly dated arse. At that point you make the decision to to crap on your customer's security and steal their resources, it's all in their best interest of course. It's not web apps are a bad idea it's that the technology over which they are implemented sucks in terms of the need. Adding more tags to HTML is just polishing the turd.

Jaqui
Jaqui

xml/xslt/XHTML & CSS. you don't need to use clientside scripting for the functionality.

Jaqui
Jaqui

are going backwards, and losing the functionality they are trying to obtain.

lcosma
lcosma

So... suppose I'm developing complex and very interactive web apps, and my client wants all the features that are expected from a desktop application, and fully bans the use of any component (ActiveX, Java, Flash etc)... Where am I left?

Justin James
Justin James

But since it is pretty clear what direction they are going in, I do not have high hopes. :( J.Ja

nvrtis
nvrtis

I can't figure out what you would want to add to 4 in order to come out with the 5 that you want. As a guy who ends up doing maintenance to sites after the consultants leave, it sure would be nice to have a "Date" input type field instead of trying to dig through a dozen javascript includes to learn the one they used "this time". Same with numbers, currency, phone number, email, etc. Actually, the same with the 'back' button. The number of hours spent trying to prevent people from resubmitting an order is a waste. Yes, hackers will get around it. But I don't have to code 'nice' to hackers. I can simply swallow the request without even a 'sorry'. Now I've got try to be nice to the user and tell them 'sorry, but you can't do that'. Nick

techrepublic.com.com
techrepublic.com.com

As part of my job, I help other developers find and fix issues in their apps. A common theme is that these developers dont understand how i was able to change the value of their hidden input or inject some data into their select element that wasnt one of the options. Or bypass some of their javascript data validation checks. I havent read the entire HTML5 spec, but somehow i doubt the W3X is removing javascript's ability to manipulate the DOM. So while a Date input type might be convenient, I fear that it will only increase the number of people who RELY on that data check and then dont do any checking on the back-end. Web application security is already a major concern/problem. Why give people the ability to make it even worse? As for having to deal with some consultant's Javascript, you should check out Firebug. It makes debugging/tracing javascript much easier. It has full support for stepping through the code, watches, breakpoints, etc. IMO, I would be happiest if the W3 went farther with the XHTML spec and pushed it father towards XML+XSLT+CSS. Have the data be in XML, transform that data to the requested format with XSLT and then use CSS to make it look pretty. Win, win WIN!

Pentagear
Pentagear

I hand code for a living. Adding all the tag soup non-sense in HTML5 is as the article put "a backwards step 15 years". I'm a serious advocate for XHTML 1.0 Strict doctype. Yes, I'm even so seasoned that the wrap element of textareas being missed in this DOCTYPE saddens me. I've seen the power of XML / XSLT / CSS before, dabbled in it myself even. But I think what the core of this is that even XSLT has to output in a specific HTML version / mode / what-have-you. That should be XHTML 2.0. Stripping out tags that directly relate to tech vendors, leaving only structural, and context sensitive tags intact.

Tony Hopkinson
Tony Hopkinson

Markup with mark up Transform with transforms and Present with presentation? You must be some sort of loon! W3C, sold out, might as well move to Redmond.

Justin James
Justin James

"So while a Date input type might be convenient, I fear that it will only increase the number of people who RELY on that data check and then dont do any checking on the back-end. Web application security is already a major concern/problem. Why give people the ability to make it even worse?" Exactly my fear as well. Far too manmy programmers are already relying on client-side JavaScript to protect their application. The last thing I want is for it to be even easier to forget to validate input on the server side! J.Ja

Tony Hopkinson
Tony Hopkinson

Most of these 'highly' paid 'consultants' are as likely to make an arse of the user's data as spot when it's not right. Personally I don't trust any of 'em and validate everything server side anyway. Clientside validation is a usability issue, not a data integrity one. Only total muppets assume that user entered data is ok and when I'm server side, the browser is the user. As for your functions there are shed loads of them. Also you have to remember that 12/31/2008 is a valid date on a client with US regional settings. You send that to my UK server though.... If one side did n't deal with it or better yet agreed to transfer dates in a common format, validated at both ends, well you get where we are today...

apotheon
apotheon

You need input format verification, in addition to simple type checking. Sure, in Ruby (for instance) you can always do something like this: [b]foo.integer?[/b] . . . but you should also do something like this: [b]foo.verify_format[/b] . . . where you define the verify_format method to ensure that you only have values within expected ranges of character lengths, et cetera. This becomes especially important when working with technologies that are subject to problems like buffer overflows in C/C++.

techrepublic.com.com
techrepublic.com.com

Which are you going to believe in more. 1) The input field that comes from this complex Javascript that was put there by a high paid consultant? 2) The input field that comes raw from the browser? none of them, as the data from a client/user can never, under any circumstance, be trusted. From the usability side, it would be helpful to give the user some quick feedback that they fat fingered a number instead of waiting for the server to tell them. with today's javascript frameworks, it is VERY easy to do exactly that. All of the apps I build give the user immediate feedback. If the logic isnt too complex, I build it in Javascript. If it is more complex, then I create an XHR and have the server parse the data and return any errors back to the user. The ONLY thing that adding the additional input types will do is make the client-side javascript development a bit easier. But the server-side of things wont be affected at all, as, again, data from the client/user can never be trusted. If you want to help security on the server side, start creating some standard language constructs that make it easy... function shouldBeDate() shouldBeNumeric, etc. Almost all server-side scripting languages *DO* have those functions (checkdate(), is_numeric(), is_float(), is_int(), etc.). Or did you mean creating standard JAVASCRIPT functions for checking data? Again, almost all of the js frameworks have those built in.

nvrtis
nvrtis

I disagree that they will be more likely to rely on the browser. Which are you going to believe in more. 1) The input field that comes from this complex Javascript that was put there by a high paid consultant? 2) The input field that comes raw from the browser? When you add the javascript 'editing', it is easier to forget that what really comes back to the browser is just a simple POST string, and in fact might have been crafted outside your nice little javascript sandbox. From the usability side, it would be helpful to give the user some quick feedback that they fat fingered a number instead of waiting for the server to tell them. If you want to help security on the server side, start creating some standard language constructs that make it easy... function shouldBeDate() shouldBeNumeric, etc.

Justin James
Justin James

I think there maybe actually be something to this odd-number theory. Each HTML version seems to swing in the opposite direction from its predecesor, like they are reactions against themselves or something. Our maybe they let different people into the process on each version's draft. HTML 3 and HTML 5 were clearly attempts to take all of the non-standard stuff that vendors do and put them into the standard to force ALL vendors to do it. HTML 4 (I can't speak to HTML 2 since I barely remember it) was more like, "wow, we really screwed up, let's get back to basics". J.Ja

apotheon
apotheon

"[i]Note that the features in HTML 4 stood the test of time, while HTML 3's features mostly died before HTML 4 even came out.[/i]" I guess we should just skip odd-numbered HTML versions, then! It's kinda like the bit about how the even-numbered Star Trek movies are always better than the odd-numbered Star Trek movies.

apotheon
apotheon

"[i]The last thing I want is for it to be even easier to forget to validate input on the server side![/i]" Do you mean "client side"?

Justin James
Justin James

I wrote a bit on that from a slightly different angle a while back. I was basically saying, "hey, don't embed stuff from outside of your domain because you have no idea if you'll be getting your viewers into trouble." In other words, someone comes to site A, which embeds content from site B. The user knows site A is OK and that the IT department monitors users accessing site B, but the user has no way of knowing until it is too late that site A pulled content from site B, so now it looks like the user is trying to get to site B. This is what happens when a standard designed within academia for academic uses suddenly gets adopted by the greater world. HTML doesn't meet the needs of the average business programmer because it was never meant to be used for business purposes. Now we have this conflict where HTML 4 tried to reassert the original academic use, and HTML 5 is sharply pulling towards what the business people want, which is back to HTML 3, but with special input fields and datagrid fields instead of marquee and blink tags. Note that the features in HTML 4 stood the test of time, while HTML 3's features mostly died before HTML 4 even came out. J.Ja

seanferd
seanferd

I found this to be interesting: Cross-site request forgery, apparently a "feature" of HTTP. Exploit Could Taint Forensics

Justin James
Justin James

My whole point is that I really didn't want anything *added* to 4, other than the audio/video tags (I feel that the addition of these two is a much lesser evil that the mess we currently have; at least it would make the thing plugin-neutral). I wanted the currently deprecated tags to be removed entirely, and a few more tags deprecated. I understand your pain entirely. But I have always beleived that if we weren't trying to use a bicyle to run in the Indy 500, we would not have difficulties with the rocket boosters being unsafe. In other words, HTML is a document specification for use on a wide variety of devices. It is not a GUI definition system. To try to add on to HTML to make it into a GUI definition system can only lead to disaster. J.Ja

Tante Waileka
Tante Waileka

I think you folks have forgotten that HTML is just a DTD within SGML. As an original SGML writer and template designer, I suggest you 'html'ers' get over yourselves. As it is, most people don't correctly tag with HTML most of the newer browsers have a lot of built-in fuzzy logic anyway. If w3c wants to modify the DTD of HTML, so what? It's still just a mini-'readers digest' version of SGML. (BTW, XML is a subset of SGML.) I can handcode html pages with both hands tied behind my back and typing with my nose. So can any SGML writer or template designer. You have 'issues' with expanding HTML? ha ha ha... try SGML.

Tante Waileka
Tante Waileka

I think you folks have forgotten that HTML is just a DTD within SGML. As an original SGML writer and template designer, I suggest you 'html'ers' get over yourselves. As it is, most people don't correctly tag with HTML most of the newer browsers have a lot of built-in fuzzy logic anyway. If w3c wants to modify the DTD of HTML, so what? It's still just a mini-'readers digest' version of SGML. (BTW, XML is a subset of SGML.) I can handcode html pages with both hands tied behind my back and typing with my nose. So can any SGML writer or template designer. You have 'issues' with expanding HTML? ha ha ha... try SGML,

apotheon
apotheon

1. HTML has a more limited purpose than the whole of SGML, so extensions to HTML that seem inappropriate for that document type's purpose are a valid concern. 2. HTML is not a DTD. A DTD is a "document type declaration". HTML is not a "declaration" of anything. It is a document type. One can declare a document type of HTML, but that makes HTML the document type -- not the document type declaration. This is just a minor, grammatical quibble with your phrasing.

Editor's Picks