Hard Truths About HTML5

snydeq writes "Peter Wayner discusses a number of hard truths Web developers must accept in making the most of HTML5 — especially those who are looking to leverage HTML5 in hopes of unseating native apps. 'The truth is, despite its powerful capabilities, HTML5 isn't the solution for every problem. Its additional features are compelling and will help make Web apps formidable competitors for native apps, but security issues, limitations of local data storage, synchronization challenges, and politics should have us all scaling back our expectations for the spec.'"

Comments

On no. 1 & 3: Never trust the client

[mikael_j]

Seriously, how is this hard? Don't trust the client, store things like geolocation data and other such things server-side.

Sure, not everything can be stored server-side but something like coordinates can easily be stored server-side (preferably linked to your current session in case you are logged in from more than one location so posts from your cellphone don't show up as posts from your home and vice-versa).

Re:On no. 1 & 3: Never trust the client

[Anonymous Coward]

Seriously, how is this hard? Don't trust the client, store things like geolocation data and other such things server-side.

You say that as if it's not creepy.

Re:On no. 1 & 3: Never trust the client

[Anonymous Coward]

The 'point' they make in no. 1 is totally backwards also. The ability to see what code your computer is running is by far a lesser security problem.
Without the ability to audit or filter code before you execute it on the client side would be a true nightmare.

Re:On no. 1 & 3: Never trust the client

[XDirtypunkX]

That doesn't stop the client very easily spoofing their own location coordinates, before it is ever stored on the server, which is the problem the article is highlighting. The geo-locations API in HTML5 is called by clientside code, it then exists in an intermediate form before being passed to the server to store. With easily available debugging tools, you can stop the code and change that intermediate data before it gets sent off to the server. Of course, most of this is possible with native applications, it is just considerably harder to do.

Re:On no. 1 & 3: Never trust the client

[mikael_j]

True, I'm just saying that if geolocation is truly important to you then maybe you should at least attempt to verify it server-side (by looking up the IP address of the user, if it shows the user in Germany while the client is reporting that it's in Egypt then maybe there's a problem somewhere).

My point was that as long as you don't blindly trust the client you won't have these problems. Of course, it used to be worse, I remember the good old days of the late 90s when it wasn't uncommon for websites to use JavaScript to verify logins on the client (I have no idea who thought that was a good idea but it seemed to spread like wildfire).

Re:On no. 1 & 3: Never trust the client

[gerumato]

It's hard to pay the rent, and a flaming book about a new technology seems to be the solution to Peter's financial problems.

Re:On no. 1 & 3: Never trust the client

[dokc]

His post is purely solution driven. You have a software problem - there is a solution. It has nothing to do with morality.

Re:On no. 1 & 3: Never trust the client

[moberry]

I try to work my web-apps in the MVC style -- or at least the "VC" style. The browser is the view, the only thing it gets sent is data to display. It is fairly simple to through a debugger up and see exactly how the server API works, but it's also fairly simple to ensure your API is only servicing valid requests and all data is being validdated/escaped/etc.

Re:On no. 1 & 3: Never trust the client

[Dog-Cow]

A problem somewhere... like maybe he's using a VPN. That's the problem here... nothing is reliable.

Re:On no. 1 & 3: Never trust the client

[BenoitRen]

That doesn't stop the client very easily spoofing their own location coordinates

Why is this a problem in the first place?

Re:On no. 1 & 3: Never trust the client

[mcvos]

The other points aren't all that great either. Most of them are either irrelevant or apply equally to native apps as they do to web apps. If anything, this article seems to point towards relying more on the server and less on the client.

Re:On no. 1 & 3: Never trust the client

[ciderbrew]

It would be a DRM issue for streaming content. If you can't trust the location how do you know what to block.
OR ... HA HA.

Re:On no. 1 & 3: Never trust the client

[heathen_01]

There was no solution posted though. If you don't trust the client it doesn't matter if you store the data client side or server side.

Re:On no. 1 & 3: Never trust the client

[Rigrig]

Don't trust the client, store things like geolocation data and other such things server-side.

Uhm, where do you think you got those coordinates from in the first place?
TFA isn't talking about sending geoip data back to browsers to store it in a cookie, it's about getting GPS data from visitors, who will want to lie about it, e.g. to get free beers for logging in at a specific spot several days in a row.

Re:On no. 1 & 3: Never trust the client

[dokc]

This is /. Of course nobody will post a solution.
If you don't trust the client a desktop application with hardware dongle and insane obfuscation and encryption wouldn't be enough for you.
If the client invest enough energy all your protection will be for nothing.

Re:On no. 1 & 3: Never trust the client

[tlhIngan]

True, I'm just saying that if geolocation is truly important to you then maybe you should at least attempt to verify it server-side (by looking up the IP address of the user, if it shows the user in Germany while the client is reporting that it's in Egypt then maybe there's a problem somewhere).

That breaks a very common case where you have geolocation data - mobile data. Specifically, data roaming. Data roaming works because the roaming carrier forwards packets your phone sense out to your carrier, who then uses their gateway to connect you to the Internet. As far as anyone is concerned, your IP is wherever your carrier is.

And since phones are basically the main reason to get geolocation data...

Re:On no. 1 & 3: Never trust the client

[arjan_t]

He means geolocate by the IP and not by what the client says.

Indeed. It doesn't matter much where the data is stored, since the original number originates from the client anyway. If the client wouldn't store the geolocation, someone could still send any location they like to the server.

Re:On no. 1 & 3: Never trust the client

[Synerg1y]

You can have all that client side for the spyware app to process for you, and I'll post the disclaimer releasing my website of liability? :P

ex. come to my website, I won't protect your data.

Re:On no. 1 & 3: Never trust the client

[mikael_j]

Where you get the coordinates varies. For a mobile client with GPS, yes you'll probably want to use the client-supplied data a lot of times. But it can make sense to do a server-side check against the IP address, if it's a supposedly static IP somewhere completely different from where the client claims to be the client may be lying...

Re:On no. 1 & 3: Never trust the client

[mikael_j]

Of course, I merely pointed out that if you approach the problem from the "never trust the client" angle you will generally be able to avoid a lot of the problems that may crop up. In this case you should obviously not rely on client-supplied coordinates for security or anything involving money unless you have also separately verified that the client is trusted (i.e. a large company giving phones on-campus access to certain services only if the client has logged in with a company-supplied account first).

Re:On no. 1 & 3: Never trust the client

[grcumb]

There was no solution posted though. If you don't trust the client it doesn't matter if you store the data client side or server side.

That's a remarkably naive thing to say.

In any data-driven app, you never, ever trust the client. You do, however, trust the rules you've put into place to ensure data integrity and the logic you use to enforce them. (Well, 'trust' in the sense that you've tested the hell out of your software.) That way, even if you do have a malicious client, they can't do more harm than you're willing to allow.

Re:On no. 1 & 3: Never trust the client

[mikael_j]

So you're suggesting that everyone just ignore security concerns in favor of the "ooh, shiny!" factor? Or just what is it you are trying to say?

Re:HAHA !! WEB APPS ARE FOR LOOZERS !!

[Joce640k]

I'm going to wait for HTML 6.

Nothing

[Whuffo]

Yes, I read TFA. It wasn't very illuminating; the author essentially says that since the client side can alter the transactions, HTML5 has security problems.

That's kind of stupid; whose security are we talking about here, anyway? Clearly not the end user - and I'll feel free to use various add-ons to alter the web pages I visit to improve my security and privacy

Re:Nothing

[Danse]

Yes, I read TFA. It wasn't very illuminating; the author essentially says that since the client side can alter the transactions, HTML5 has security problems. That's kind of stupid; whose security are we talking about here, anyway? Clearly not the end user - and I'll feel free to use various add-ons to alter the web pages I visit to improve my security and privacy

Apparently you didn't get past number one in the article's list. I thought the article was pretty clear about who's security it was talking about. Namely the security of the app, and by extension, the security of the person or organization that writes their app using HTML5. I have no idea why you would think otherwise based on the topic of the article.

Re:Nothing

[mjwx]

Yes, I read TFA. It wasn't very illuminating; the author essentially says that since the client side can alter the transactions, HTML5 has security problems.

Since when has security issues stopped anyone?

Somewhere around point 9 the author gets to the actual problems, HTML5 isn't one standard, it's a bunch of competing standards. MS, Apple and Google have their own ideas about HTML 5 and are implementing them independently from each other. MS and Apple are trying to lock people into their platforms. Not being able to agree in a video codec alone will kill HTML 5 viablity as an application platform and ensure that Flash remains relevant. Lets not get into interactive web applications, what's the point of having to write one for 3 or more HTML 5 browsers when you can just it in Flash and have it run on all browsers with that plugin.

Can I have an "Ahmen!" or at least a "well duh!"?

[erroneus]

Despite the power and awesomeness that is the growing new web environment, the browser is the client and the application runs on the server.

Rich, exciting, thrilling and awesome experiences on the client side be damned, the server, the data and the application should never trust the client. I always thought this was a fundamental reality of the web that everyone knew. But recently, with all this version number craziness we have been seeing of Firefox lately, I have come to realize that there are a lot of lessons that have to be re-learned "the hard way" along the way.

Hard Lesson #1 (for Firefox), don't screw with your users or you won't have them long.

Hard Lesson #2, it's a "browser" and a "standards compliant browser" at that. This will mean it is very replaceable or interchangeable. Don't overestimate your worth to the user. Whatever it takes to see the truth, "the browser is not the thing" ; it's how you get to the thing.

Throughout computer history, we have seen patterns emerge. The computer is too over-loaded, so move computing outward to the desktop. The desktop is too overloaded, so move computing back to the server. The desktop and the server are too overloaded and the IT departments are too burdened and expensive, so move computing "to the cloud!" (aka, someone else's servers) All these changes over time indicate a behavior of aversion -- seeking to avoid a problem. That's all well and good, but it doesn't seem to address the problem on the merits of the situation and is certainly not accepting of reality. That reality is that the data and the services are "the things." There are costs associated with those things and they must be managed. But "the things" are the things and they must be valued and handled appropriately and all the things surrounding "the things" need to be held in perspective.

HTML numbering scheme

[dokc]

I'm going to wait for HTML 6.

You didn't hear? Numbering is "out".
It will be just HTML in the future and the version numbers will be hidden from average users.

Re:HTML numbering scheme

[Canazza]

They're not dropping numbers.

Mozilla just stole them.

Naivety

[localman]

"HTML5 isn't the solution for every problem."

And anyone who thought it was has not been programming for very long, or simply doesn't learn from history.

On the plus side, HTML5 should make some aspects of life a bit easier, and hopefully introduce only a small number of new challenges.

Cheers.

Re:Naivety

[AwesomeMcgee]

"HTML5 isn't the solution for every problem."

And anyone who thought it was has not been programming for very long, or simply doesn't learn from history.

On the plus side, HTML5 should make some aspects of life a bit easier, and hopefully introduce only a small number of new challenges.

Cheers.

Chiefly among those new challenges is that annoying fanboy you work with who will zealously tout it as the cure for polio with such zest and excitement, management will believe him. Then when he implements something that only cures a working computer of it's health, you'll be the one expected to fix the anti-polio HTML5 web app (which will surely have many more buzzword terms attached to it by then increasing how much people expect you to do with it).

Re:Naivety

[aztracker1]

I really hate that HTML5 is just lumped together as some abstract term for modern web development techniques. Most of which doesn't use the new tahgs (audio, video, canvas) and other tags are used in place of div.class which is nice enough, and does give some context... To my CSS3+ is the key here. JavaScript libraries have come a long way, and a few nice features are now native.

Re:Naivety

[Darinbob]

Well the idiots often end up in charge. The actual experts are just trying to earn a salary. It's like the dotcom snafu all over again, lots of idiots with a stupid idea getting funded who hire people to implement their dump ideas for no money and the promise of riches in the future. Maybe not that insane today but I don't doubt we have many many software engineers all implementing bad ideas that they disagree with because they want to get paid.

Holding off using it for other reasons

[Xest]

Frankly, the spec is a bit of a joke.

The semantic tags are out of date before the spec has even finalised, because it doesn't cover thing like comments tags which are prominent in todays sites, illustrating what a dumb decision it was to add a bunch of random semantic tags based on an arbitrary web survey carried out years ago. Semantics should be applied to classes just like styles are using a semantic definition language. This would of course have the advantage of allowing 3rd parties to produce semantic definition archives for no longer maintained sites etc. that browser could look up but well, there you go, that's what happens when people who apparently don't have even the slightest grasp of separation of concerns get their hands on something as fundamental as an HTML spec. It's like they didn't even realise why it's better to not have all your styles embedded in your document structure markup - i.e. your HTML and hence why CSS was developed the way it was.

Thus far it seems to have taken the web backwards in terms of compatibility, many of the new features work differently in different browsers, harking back to the days of HTML3/4 and Netscape/IE battles.

XML syntax seems discouraged which means you'll run into more people using the SGML syntax which seems to be pushed more than XML which makes the web more of a ballache to work with- no more of a push towards simple XSLT to trivially move data around and into and out of web displayable formats and instead a push away from that. I don't really care if it's served as XML or not, the point is that if it's not well formed XML it becomes a massive ballache to deal with, because XML tools and libraries are so prevalent.

The ethos surrounding HTML5 is that well, lots of old sites didn't follow newer standards, so lets make those web sites standard by taking everything they did shit, and making that standard. So great, yes, let's make shit, the standard. No, that's not how standards work- standards define a high quality that allows maximum compatibility which developers should strive to adhere to, if some don't then don't cater to them- just point out they're shit because they're not standards compliant.

Really, I don't think I'll touch it unless it gets to the point where you can't avoid it. I think I'll wait for a spec that's written by adults than a bunch of PHP kiddies who don't have the first clue about how to right good web software, and instead prefer to bung any old shit into the mix and call it a standard. Not to mention the drama about it being a living standard- good standards don't need to be living, good standards are generic and flexible enough to be future proof for a good number of years - you know, like, say, the XML spec.

It's not that I don't like some of the new features proposed in HTML5 like canvas etc., I think they're great ideas. It's just a shame the rest of it is just so painfully amateurish from a software development perspective. The net result is a spec that basically takes the web back to where it was 10 years ago- a messy inconsistent mess of arbitrary tags that needlessly duplicate functionality, causing annoying ambiguity with a dash of incompatibility chucked in to boot.

I'm hoping for a quick iteration to XHTML6, run by people who actually know what they're doing so we can just bypass the mess that is HTML5, but that's probably a bit much to hope for.

Re:Holding off using it for other reasons

[sydneyfong]

Another sad case of a XML brainwashed believer....

XSLT, trivial? Have you ever tried doing anything useful with it?

XML/XHTML was written for the parsers. HTML5 was written for web developers. You may say the standard is "shit", the practices are "amateurish" (when benchmarked against what they teach you in the textbooks), but all that counts is what people are able to do with the stuff.

Theoretical aesthetic purity is not an ends in itself. The "separation of concerns", "removal of arbitrary tags/duplicate functionality", "future proof" stuffs actually make the XML/XHTML spec more useless, harder to work with, and decreases productivity. You may marvel at its aesthetic beauty, but for people like us who actually need to do things on a schedule, those restrictions hinder our productivity when there's no way to opt out of it.

For example, if people use bold text all the time, then why shouldn't we be able to <b>bold-text</b>? Why should we have to <span style="text-weight: bold">, or worse, write up a crazy "semantic" document and then add the XLST? Isn't that overkill?

The HTML spec people took 10 years to realize the mistake of going the XML way. It seems that you still have yet to make that realization.

Re:Holding off using it for other reasons

[mwvdlee]

XML syntax seems discouraged

Can you give an example of non-XML-compliant HTML5?

Re:Holding off using it for other reasons

[Bogtha]

XML syntax seems discouraged which means you'll run into more people using the SGML syntax

It's not even SGML syntax any more, it's pseudo-SGML that is reverse-engineered from browser implementations. Some SGML features have been dropped, some alterations have been made to compensate for common syntax errors, and error handling has been defined.

Re:Holding off using it for other reasons

[mikael_j]

For example, if people use bold text all the time, then why shouldn't we be able to bold-text? Why should we have to , or worse, write up a crazy "semantic" document and then add the XLST? Isn't that overkill?

Maybe it's just me but I'd rather do <span class="bold">. Using <b>, <center> and so on may work fine but overall using CSS to style your page is the way to go anyway.

Basically, you'll still end up with css for b, center and all those other elements because you don't want the default look of them.

Re:Holding off using it for other reasons

[kiddygrinder]

the lack of xml compatibility is a bit of a pain but it makes almost no difference, everyone has been dealing with that for years. saying that it's like the old ie/netscape days is pants on head retarded. good luck with the self flagellation, but html5 is a massive step up even with it's flaws; oh and by the way, html 5 isn't even a standard yet, so don't bother even wondering about (x)html 6

Re:Holding off using it for other reasons

[Anonymous Coward]

I agree with your points.

Coward post, but I just spent the past nine months building a WPF application. I find Wpf to be very nice, and I have to think if the HTML standard was recreated today, it would look much more like WPF. Does anyone else agree? I believe most of HTML seems old, redundant, and exist for lagecy support.

Re:Holding off using it for other reasons

[Xest]

"Another sad case of a XML brainwashed believer...."

Believer? that implies I merely believe XML is useful. No, sorry, many of us in the real world actually find XML useful. We develop large systems where XML helps no end. I'm sorry that you've never worked on a project where XML has come in useful, but some of us are competent enought o actually use the right tool for the job.

"XSLT, trivial? Have you ever tried doing anything useful with it?"

Yes thanks. We had an old black box system that we needed to integrate with a new web based system, it produced web pages that were thankfully at least XHTML1 compliant. Because we couldn't yet get rid of this system we were fortunately able to XSLT transform the output into useful data, and feed back inputs to it to transparently integrate it with the new system. If it had only adhered to HTML5's bastardised SGML syntax then it would've been a nightmare to integrate with this legacy system.

"XML/XHTML was written for the parsers. HTML5 was written for web developers. You may say the standard is "shit", the practices are "amateurish" (when benchmarked against what they teach you in the textbooks), but all that counts is what people are able to do with the stuff."

Right, and this is the problem. Too many developers haven't come from a professional background. They write code that would make old school C++ developers, and high end Java developers alike cry themselves to sleep at night. They managed to get a basic site working in PHP once, and have moved on from their, they don't understand what MVC or OOP is and don't see why they should because they never needed it so just carry on as normal. The problem is, they're also the ones who are responsible for sites that are always falling over, getting hacked, miserably hopeless in terms of scalability. Stuff isn't put into textbooks for a laugh, or to give you something to study, it's put in there base on experience, it's put in there so that you don't repeat the mistakes made by others before you - and there's the problem, too many web developers do repeat those mistakes time and time again, which is why things like SQL injection and XSS attacks are some of the most common to this day, despite solutions to them being long available and known, well, if you read the textbooks that is.

"Theoretical aesthetic purity is not an ends in itself. The "separation of concerns", "removal of arbitrary tags/duplicate functionality", "future proof" stuffs actually make the XML/XHTML spec more useless, harder to work with, and decreases productivity. You may marvel at its aesthetic beauty, but for people like us who actually need to do things on a schedule, those restrictions hinder our productivity when there's no way to opt out of it."

You are a terribly developer. Sorry, it needs to be said. You've basically admitted you're writing terrible code just to get something working. Your code is the type of code responsible for nightmarish maintainability, horrendous bugs and security exploits. Please, get the fuck out of the software development industry now. We don't need more bad software. I understand that in some places the constraints are such that speed of development and hence reduced cost is put well over and above quality but that's not the same everywhere. Please don't assume your complete lack of focus on quality is universal.

"For example, if people use bold text all the time, then why shouldn't we be able to bold-text? Why should we have to , or worse, write up a crazy "semantic" document and then add the XLST? Isn't that overkill?"

It depends. Sure it might take you an extra 5 minutes today, but that's 5 hours saved tommorrow when you have to come back and fix things. Separating off semantics means that for larger software teams you can even have people dedicated to looking after just that, so the developers can focus on developing, without getting in each other's way.

"The HTML spec people took 10 years to realize the mistake of going the XML way. It seems that you still

Re:Holding off using it for other reasons

[brunes69]

"XML/XHTML was written for the parsers. HTML5 was written for web developers"

You seem to be completely glossing over / forgetting the fact that in order for the "web developer"'s site to be farmed out, it needs to be served up by an engine, written by a software developer - one who has a metric crapton of libraries and tools all geared toward working with XML.

This is of course also completely glossing over the fact that there is basically no one in the industry anymore who is simply a "web developer". Try getting a job in a real workplace with nothing in your skillset but HTML and script, and you will be laughed out of the building. All companies want real software developers nowadays - and those developers appreciate well-formed syntax sets.

Re:Holding off using it for other reasons

[Xest]

There isn't a lack of XML compatibility, HTML5 still has it's XHTML5 mode, which still fully supports XML markup. The problem is that the HTML route not only exists, but seems encouraged, which means that rather than a push towards the much better XML syntax that we've had over the last 10 years, we're now in danger of seeing a backwards trend to the much worse syntax such that we run the risk of being back where we were 10 years ago.

You may think it's no big deal but it really is. Thanks to XML's tools that are prevalent in just about every language, it's trivial to take markup and automatically manipulate it in whatever way is needed. You may still be thinking so what? well, in this mobile era, where screens are changing form and size all the time, where we may well soon even see wristwatch computing become a much more interesting reality, then the ability to trivially and efficiently transform content on the fly to suit the display device, or program that's manipulating the content is kind of important.

Computers just aren't good at ambiguity, and whilst you can often work around ambiguity, it's inevitable there will be issues, cases where the developer didn't think this or that might happen. Sometimes ambiguity is important and even useful, but web content is not one of those cases. HTML5 vastly increases ambiguity, whereas XML removes it, and this is one reason why HTML5 is bad, and is a backwards step for the web. We can work around HTML5's issues, and if HTML5 grows and grows and grows, we'll have to, and we probably will. But why are we even having to when the solution already exists? - just write better markup in the first place with XML syntax.

Re:Holding off using it for other reasons

[snoyberg]

<html>
<head>
<title>Not XML</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<img src="not-xml.png">
</body>
</html>

Re:Holding off using it for other reasons

[StripedCow]

If the spec is a jungle for web-developers it must be hell for browser-vendors. Honestly, I don't have much faith in this whole process: the spec is so difficult that no vendor will ever get it right anymore.

I'm just waiting for the day when google's NaCl is more mature and we can just send native instructions to an accelerated virtual-machine-like browser. I'm feeling it's about time for that old "keep it simple" mantra. And it's time web-developers got back into control actually.

Re:Holding off using it for other reasons

[Xest]

I think there's a fair bit of mileage in what you've said.

Let's be honest the web wasn't designed for interactive applications and I think there's a fair question as to whether if that's what we want, then shouldn't we build a tool for just that rather than mangling HTML to try and do it, and do it badly?

It'll take a brave soul to define the next generation of web standards to replace HTML, something that's geared to proper interactive applications rather than mere content display as is the case with HTML. But I don't think you're far wrong in suggesting that that's the real, true solution to the problem. It'll be difficult if not only because it'd mean getting the browser manufacturers on board, and they couldn't even get the relatively trivial task of implementing proper XML display engines in place- something which you quite righly note, the likes of Microsoft with WPF, and many other such manufacturers have done with ease in their technologies.

Whether it's WPF or something else (probably something else, because I doubt people want a Microsoft technology becoming dominant on the web!), that sort of solution is certainly optimal.

Re:Holding off using it for other reasons

[Chris Mattern]

You seem to be completely glossing over / forgetting the fact that in order for the "web developer"'s site to be farmed out, it needs to be served up by an engine, written by a software developer - one who has a metric crapton of libraries and tools all geared toward working with XML.

The web engine gets high re-use; people don't write their own, they use one that's already available. Web developer's sites are written custom, and are written constantly. Therefore the standard should be built for the convenience of the web developer, not the engine developer.

Re:Holding off using it for other reasons

[adamrut]

XSLT, trivial? Have you ever tried doing anything useful with it?

I agree, XSLT didn't turn out to be as good as what it promised, although I find XSL-FO alright for generating PDFs. These days I find JSON a lot more useful than XML.

The HTML spec people took 10 years to realize the mistake of going the XML way. It seems that you still have yet to make that realization.

I quite like the progress of HTML5/CSS3 so far too, hopefully the browsers will keep up and include more of the specs.

Re:Holding off using it for other reasons

[ozbon]

XSLT, trivial? Have you ever tried doing anything useful with it?

XSLT can be useful? Surely that's a Slashdot Story all in itself?

Re:Holding off using it for other reasons

[BenoitRen]

Maybe it's just me but I'd rather do <span class="bold">.

Class names should never reference style, though. True, you're still mixing content and style when using the b element, but at least there the intent is clear semantically as "something that was possibly arbitrarily made bold, often by contributors".

Re:Holding off using it for other reasons

[BenoitRen]

WHATWG hijacked the web standards process, and primarily folks behind Safari and Firefox.

You're guilty of revisionism there. The truth is that the XHTML 2.0 spec writers hijacked the web standards process, locking out everyone from commenting and contributing to the process. The spec was becoming a nightmare with things like making every element a possible anchor.

That is the whole reason the WHATWG was formed. To open up the web standards process again and make a spec that reflects today's reality instead of the delusion you preach.

No, it's not to make old pages automagically standards compliant, it's to give the web developer the tools that he has been missing for years, like more elements to mark up diverse content and allow for different kinds of validating input (like dates). For example, there's no semantic meaning to be gained from <div class="article">. Introducing the article element does add semantic meaning.

Re:Holding off using it for other reasons

[mcvos]

XSLT, trivial? Have you ever tried doing anything useful with it?

I have. As long as you use it for its intended purpose, and don't try to calculate a square root with it (as a co-worker once did as an exercise), it's pretty easy. Trivial even, if you do it right.

Re:Holding off using it for other reasons

[mcvos]

Does at at least accept the XML-valid structure too? Or is HTML5 just intended to give web developers more tedious work?

Almost every single tool in the world spits out valid XML nowadays. Browsers expecting non-XML is going to be really frustrating.

Re:Holding off using it for other reasons

[BenoitRen]

It's perfectly possible to work with an XML engine and have it serve HTML data to the client. They're not mutually exclusive.

Re:Holding off using it for other reasons

[Xest]

"You're guilty of revisionism there. The truth is that the XHTML 2.0 spec writers hijacked the web standards process, locking out everyone from commenting and contributing to the process. The spec was becoming a nightmare with things like making every element a possible anchor."

What utter tosh. The HTML specification process was managed by the W3C whose members comprise just about every single industry sector under the sun and number in the hundreds. Are you seriously saying this is a less balanced process than a couple of browser manufacturers going their own way and riding a way of populism and ignorance to push their spec? I'm not sure how the current situation is better where sure comments are allowed, but they're ignored by grand dicator Hixie et al. I suggest you check the W3C's member list and see how many varied the input into XHTML2 actually was. No, what WHATWG mean when they say people were left out is "We threw our teddy out the pram, because the other firms wouldn't let us have our own way". THAT is preciely what it was all about, now they have their own way, and they're proving what a shit job they can do. It seems there was good reason no one was listening to them before.

The spec was taking time because it takes time to make sure things are done properly, and to make sure raised issues are examined, and, if need be, correct. WHATWG still don't get this to this day, which is why they've declared HTML5 a living spec, ready for use, rather than just waiting for W3C to ratify it when it's been confirmed acceptable.

But even then, since when was everyone a standards expert? standards aren't designed so that everyone can insert whatever the fuck idea they want, they're designed to support interoperability above all else. HTML5 is an epic fail at this, particularly with it's backwards move away from XML, and it's "live" spec ideology. It was far far better having thousands of experts from hundreds of varied companies running the process, than a select bunch of dictators pretending to listen, but not actually caring. Further, at least the W3C had proper accountability processes, again WHATWG is more like a monarchy with grand dicator hixie at the top, and his court closing rank around him when any criticism arises of his plans.

"it's to give the web developer the tools that he has been missing for years"

Right, so why does introducing new and important features require taking a backwards step, like pushing SGML-esque markup up the long proven beneficial XML markup? That isn't about giving developers tools they need, that's about a select group who never quite got why XML etc. were important pushing their view on the rest of the world.

"For example, there's no semantic meaning to be gained from <div class="article">. Introducing the article element does add semantic meaning."

No but there is semantic meaning to be gained by adding something akin to CSS where you can either do it inline with semantic= or with a sheet declaring semantics which are applied to the relevant classes. In contrast, there's only partial semantic meaning to be gained from:

<article>
</article>
<div id="comments">
<div class="comment">
</div>
</div>

It's a half arsed solution, it only helps an arbitrary set of components of a page, it's not a full solution. It's 100% useless for applying semantics to many elements of modern pages because the list of sections that got their own tags is based on an arbitrary and already long outdated study of prominent tags. In this context it's easy to question whether it was ever about semantics at all, or simply about being able to write yet more sloppy markup- skip the classes, just chuck some arbitrary one word tags in, but only in some places, because the list is necessarily finite, and rapidly out of date. Again, this sort of proposed solution I mention has all the benefits of CSS too- spread separation of concerns amongst a de

Re:Holding off using it for other reasons

[Excors]

I don't really care if it's served as XML or not, the point is that if it's not well formed XML it becomes a massive ballache to deal with, because XML tools and libraries are so prevalent.

It's only syntax, it shouldn't be a big deal. There's plenty of XML-based tools that are useful, and HTML5 goes to some lengths to define the text/html (i.e. non-XML) syntax so you can still use those tools and just translate the syntax at the edges.

The text/html and XML syntaxes are based on exactly the same underlying conceptual model (the DOM tree), so you can switch without any radical changes. E.g. the validator.nu HTML5 parser implements the same APIs as standard XML parsers - drop it in front of your existing XML tools and libraries, stick an HTML serialiser on the other end, and your system can work pretty much the same as before (with the bonus of working for any arbitrary page on the web, not just the tiny fraction that are well-formed XML).

The ethos surrounding HTML5 is that well, lots of old sites didn't follow newer standards, so lets make those web sites standard by taking everything they did shit, and making that standard.

Who is helped by a standard that almost everybody ignores? If you, say, want to write code to parse HTML pages, and you try to implement what HTML4 specifies (based on SGML), your code will be pretty useless because HTML4 is incompatible with reality and you'll get incorrect output most of the time (stray characters, incorrectly nested elements, half the page text disappearing inside a misparsed script element, etc). Similarly if you implement what XHTML specifies, you'll fail since most pages aren't well-formed XML. You can declare that those pages are broken and non-standard but that doesn't stop them from existing and being a serious problem for anybody writing software that interacts with the web.

Nowadays you can just implement what HTML5 specifies (or find a library that already does it), and your parser will work identically to the current or near-future versions of all major browsers - it's defined in enough detail that there's no ambiguity in how to process any stream of bytes. That's never been possible before, when the standards were focused on some vision of a simple coherent syntax and refused to deal with the messy details that are critical in real life.

If you want to document a set of best practices for writing HTML, with rules for lowercase names and closing tags and quoting attributes and for indentation etc, that's fine and would be nice (especially if you could find a way to motivate people to follow the best practices - a decade of promoting XHTML doesn't seem to have stopped people writing terrible code so we need a better way). Meanwhile, HTML5 is solving the harder problem of how to cope with people who ignore those rules.

Re:Holding off using it for other reasons

[itsdapead]

XSLT, trivial? Have you ever tried doing anything useful with it?

For simple cases, you can always use CSS to style your XML, which can work rather better than using CSS to make tweaks to an unknown set of default styles that may vary from browser to browser. However, in cases where you need to transform the order/nesting of elements in the source document to display it, CSS is stuffed anyway - most non-trivial CSS-based layouts require the HTML to be formatted just so with all the elements in the right order and correctly nested.

With the increasing use of Content Management Systems it is probably more sensible for the server to pull the content out of a database and mark it up in a page description language (doing things like generating TOCs and cross-references on the fly) based on the clients' stated preferences. That can be done using your server-side language of choice (which might include XML and XSLT tools if they are suitable).

For example, if people use bold text all the time, then why shouldn't we be able to [b]bold-text[/b]?

What you do is choose an XML schema and stylesheet - be it custom or off-the-shelf - that suits your application. The schema you're looking for is XHTML which is just as easy to write as HTML (especially if you have a syntax-aware editor to keep you on the straight and narrow and ignore the purists moaning about tag soup).

Why should we have to [span style="text-weight: bold"]

If that's what you're doing then yes, you might as well use [b] tags. The problem comes when you use bold for more than one purpose and later decide, e.g. that you want "definitions" to be in italics but to keep bold when you want it for emphasis. Then you can write [span style="emphasis"], [span style="definition"], [span style="citation"] and re-map them to different font styles at will. That's overkill if you just want (e.g.) to format individual blog posts, but if you're assembling any substantial volume of documents and want to be remotely consistent about style then this sort of situation will occur.

Or, you can choose/create an XML schema which has [citation] [emphasis] [definition] [keyword].... whatever tags. Of course, HTML5 has added a few of those for you, but with XML schemas you could potentially select an off-the-peg custom schema for playwriting, software documentation, encyclopedias, legal documents, LOLcats etc... rather than hope that W3C will add the tags you need in some future version, and that Microsoft will support them.

Or you would be able to, if browser support for XML+XSLT+FO or XML+CSS had been more forthcoming more quickly.

XML/XHTML was written for the parsers. HTML5 was written for web developers.

Which doesn't make sense when, increasingly, web developers are likely to be using authoring tools which minimise the amount of actual HTML they have to write or using server-side scripts to generate their markup. For these, XML or XHTML make much more sense because (as you said) they're easier to parse.

Re:Holding off using it for other reasons

[sydneyfong]

It depends. Sure it might take you an extra 5 minutes today, but that's 5 hours saved tommorrow when you have to come back and fix things. Separating off semantics means that for larger software teams you can even have people dedicated to looking after just that, so the developers can focus on developing, without getting in each other's way.

The problem with your argument is that there really are many instances where that 5 hours tomorrow never come. Adopting "XHTML6" in your interpretation would mean that nobody could save those 5 minutes, even if I'm just writing a hello world page.

By adopting universal standards that are so strict and unforgiving to "sloppy" code, you're raising the overhead of development without necessarily gaining back the benefits. In fact, nobody's stopping you from using your own XHTML6 -- if the XML tools are really so easy to use as you say, then surely it is trivial to write a "XHTML6" to HTML5 compiler?

You seem to think I spit out bad, hackish, sloppy code on a daily basis -- I don't. There are projects where I allow myself to be quick and sloppy because they are one off small things. There are projects where I handle your precious "separation of concerns", "future proof" things with care. But I've always been very skeptical of grandiose projects where it tries to be everything to everyone at the same time, boosting great architecture and proclaiming to be the savior of the world, best thing since sliced bread etc.

The truly worst code I've seen are the ones that try to be "future proof", "encapsulate functions", "pluggable", "modular", whatever. They make code that perform trivial functions look like a huge mess of spaghetti code. Sometimes over-engineering is as bad as none.

I never assumed quantity over quality is universal. I just wanted to stress that quality is relative to the requirements. Requirements of perfection (i.e. "separation of concerns", "lack of duplicate features", etc) is *not* universal, and you seem to be demanding it in one of the most widely used standards in the world.

Solutions only need to be as complicated as the problem itself. One thing that XML failed miserably is keeping simple things simple. SGML is simple. XML (particularly the latter versions) is anything but that.

Re:Holding off using it for other reasons

[gsnedders]

A large part of the reason HTML 5 was written at all was to standardize large parts of the behaviour in web browsers that the web relies upon --- until a few years ago, huge parts of the budgets for browsers were spent on reverse-engineering other browsers (latterly IE6, before than NN4, etc.), which resulted in a hugely anti-competitive environment. When work on HTML5 started, it was incredibly hard to write a browser that worked with the vast amount of already deployed content, and what specs there were were practically useless, in part because the vast majority of content on the web doesn't follow them. Sure, you could refuse to support anything that isn't conforming, and "point out they're shit" as you so eloquently put it, but when Google doesn't work, nobody would care about your browser, and use one that does support invalid content.

HTML5's raison d'Ãtre is implementation interoperability, and when you have interoperability between implementations, you then have a hard time defining what should be conforming content and what shouldn't be --- both types of content are processed interoperably. As it is, what is conforming and what isn't has been based largely upon use-cases provided to the WG. If you think something should be changed in the spec, send feedback! mailto:public-html-comments@w3.org is the address! If you do send feedback, do make sure to include justification for whatever change you propose.

Also, what are these comment tags you refer to? ? Supported by old versions of a single-browser (IE is the parser used by both http://validator.nu/ and (through a programmatic transformation to C++) Gecko, and provides support for SAX, DOM, and XOM APIs. provide a Python implementation that offers a drop-in replacement for XML parsers in most Python XML toolchains.

Such tools, that finally offer good compatibility with existing content, combined with changes in the spec to try and unify HTML and XHTML further (if the XML syntax were so discouraged, why would there be efforts put into unifying them?), such as HTML parsing HTML elements into the HTML namespace, should make it entirely feasible for toolchains based upon XSLT and the like to use HTML input/output.

The whole living standard debate is one where I think many have missed the point: the a look at something like CSS, especially Level 3. Many drafts have multiple implementations, and implementations will continue to evolve over time, and move on to Level 4 drafts as soon as they appear, so what meaning does whatever you call "Level 3" have when people are only interested in implementing the latest drafts?

Re:Holding off using it for other reasons

[jalefkowit]

XML/XHTML was written for the parsers. HTML5 was written for web developers.

I'm a web developer who was also a member of the W3C's HTML Working Group (the group where the HTML5 spec was hammered out) during the development of HTML5, and I can tell you that if you believe that HTML5 was written for web developers, you are wrong. HTML5 was written by and for browser vendors -- Google, Apple, Mozilla, Opera, and (somewhat) Microsoft. The opinions of other Web stakeholders were of minimal concern. Concerns about the spec raised in the WG by anyone who wasn't a browser implementer were routinely shouted down with threats to withdraw from the W3C process completely by those who were. Some who advanced concerns, like accessibility professionals, were actually derided in quite personal terms by representatives of the browser vendors, both in official WG communications and in their own private back channels (like IRC), which invariably leaked. (Here's a good writeup of some of the friction that existed in the WG between browser vendors and everybody else.)

There are a lot of things in HTML5 that I'm looking forward to being able to use, but if you're a web developer you shouldn't kid yourself into thinking that HTML5 was written for you. It wasn't. Almost every decision made in the development of HTML5 was made to make Google's life easier, not yours.

Re:Holding off using it for other reasons

[tuffy]

The ethos surrounding HTML5 is that well, lots of old sites didn't follow newer standards, so lets make those web sites standard by taking everything they did shit, and making that standard. So great, yes, let's make shit, the standard. No, that's not how standards work- standards define a high quality that allows maximum compatibility which developers should strive to adhere to, if some don't then don't cater to them- just point out they're shit because they're not standards compliant.

Features browsers implement and people use are the standard. If browsers add the <foo> tag and sites decide it's the greatest thing since sliced bread, then it should be folded into the standard. That way the next guy who writes a browser or a site can know how the tag is supposed to behave. Rough consensus and running code.

Trying to define a "high quality" standard first and handing it down from the ivory tower for browsers to implement isn't going to work. It'll be XHTML or Perl 6 all over again.

Re:Holding off using it for other reasons

[sgt scrub]

It sounds to me you've just run into the dipshits that write articles about XML and basically make it as difficult as humanly possible so they sound smart. If your a C++ programmer try this. Write a DTD (make up your own XML). Then use the dtd to xsd script from here to create an xsd. Then use this to create C++ templates from the xsd.

If your working on a really big complex project that needs to have the ability to manipulate the output using C++, or even javascript in a browser, you will see how much of a time saver XML can be.

Re:Holding off using it for other reasons

[sydneyfong]

I see it differently. Your example shows how complex XML can be.

Forcing it down the throats of everyone (as my original parent seems to advocate) seems a bit drastic. Particularly as a lot of people writing (X)HTML don't work on "big complex projects".

Re:Holding off using it for other reasons

[sydneyfong]

No one forced you to do that, you could always serve HTML4. Just because some nutters online thought it would nice to go ultra-semantic didn't mean you had to join in the fun.

Hah. Everyone seems to think I'm against XML.

I'm not against XML. I'm against the GGP's attitude of "forcing everybody to abandon HTML and use XHTML/XML".

If your stance is that I shouldn't have fed the troll, then sorry, I was bored.

Re:Holding off using it for other reasons

[BitZtream]

Yes, and you end up with less HTML being sent to the client as well.

They are functionally the same, only your way is more bloated and uglier since you're still going to have the exact same CSS behind it, your way is rather stupid.

Re:Holding off using it for other reasons

[m50d]

some of us are competent enought o actually use the right tool for the job.

XML is never the right tool for the job, it's a perfect example of trying to be all things to all people. It's not really human-readable and certainly not human-writable, but at the same time it has too much parsing overhead for a useful machine format. If you wanted the right tool for the job you'd use either a lightweight, actually-human-editable format like json or yaml, or an efficient binary format.

If it had only adhered to HTML5's bastardised SGML syntax then it would've been a nightmare to integrate with this legacy system.

HTML is a nightmare to parse - but browsers are always going to have to parse it (even if we switched to something else today there's too much legacy web for them not to support it), and as such there are plenty of libraries available to handle it. And once you've parsed it, manipulating a document in a real programming language is far more efficient and effective than using XSLT. I was once a big fan of XSLT, but having worked on systems that use it, no.

this is the problem. Too many developers haven't come from a professional background

And yet somehow they've produced a far more successful platform than any "professional" effort. The web grew based on browsers and site writers implementing whatever they needed; if you look at its history, formal standardization of the web coincides with a huge stagnation in functionality.

HTML is and always has been a presentational format; it isn't and shouldn't be a semantic format. Browsers don't want or need semantic information, and couldn't trust it if it was there. Look at the img alt=... attribute; it's come to specify "mouseover text", regardless of its supposed semantic meaning, because that's the presentation browsers give it so that's how site authors have used it. So now you have some sites that use it with its original intended semantic meaning and some with another semantic meaning, and there's no way for a browser to distinguish between the two; the only meaningful semantics that html has are display semantics, because that's the only thing browsers provide and the only thing site authors test. You may have a need or desire for a semantic markup format, but the solution to that is to make one, not try and turn html into one.

The "HTML spec people" actually preferred the XML route, and genuinely still seem to to this day. The problem is the "HTML spec people" have now had the web standards agenda hijacked by a bunch of inept cowboys, who have now become the new "HTML spec people".

The original spec people spent about a decade coming up with nothing useful. In fact as far as I can see every major choice the spec people made was wrong - the stupid CSS box model, the treatment of iframes, object vs. embed... HTML4 (the only actual standard version AFAIK) has zero advantage over HTML3.2 (the name for what MS and Netscape implemented on their own). CSS is a classic case of design-by-committee; it's not expressive enough to replace programmatic generation of html, but it's still so complex that not only has the full standard never been implemented, I've heard serious doubts that it's even possible to implement.

The guys now in charge of the standards are the ones who wrote the software we all use daily to browse the web, rather than the ones who sat in endless discussions and produced nothing. I think you've got the wrong notion of who's inept.

Re:Holding off using it for other reasons

[yuhong]

Yes, it does. In fact, you can develop polyglot documents that can be interpreted as both HTML5 and XHTML5.

Re:Holding off using it for other reasons

[yuhong]

HTML4 (the only actual standard version AFAIK) has zero advantage over HTML3.2 (the name for what MS and Netscape implemented on their own).

Huh?

Re:Holding off using it for other reasons

[yuhong]

They do have a "web developer" edition with only the stuff important to web developers.

Re:Holding off using it for other reasons

[yuhong]

Agreed that XHTML2 was stupid, but if I was there in 2004 I would have suggested a new version of XHTML that is backward compatible with XHTML1 and HTML4 using Appendix C (which XHTML2 wasn't).

Re:Holding off using it for other reasons

[JDG1980]

You're ignoring some very important facts: (1) Lots of markup needs to be written. (2) It needs to be written fast. (3) It needs to be written cheap. Whether academic computer scientists cry over poor aesthetics or design practices is irrelevant. This is the real world. The Web is a major part of the world economy, and it isn't going to stop because you say so. And it isn't going to be written entirely by XML experts earning $100,000 a year. Furthermore, the entire point of HTML was that it was supposed to be easy and forgiving enough for ordinary people to use, even if they don't have a programming background. Many web pages are written with people who have no programming skills at all! And this is not going to change, nor should it.

Re:Holding off using it for other reasons

[BenoitRen]

That's funny. I'm an independant web developer and I have had the opposite experience. Considering the friction between the WHATWG and the HTML Working Group, you're most likely biased.

Re:Holding off using it for other reasons

[arevos]

The semantic tags are out of date before the spec has even finalised

Presumably things like this is why they dropped the version number and moved to a "Living Standard". The HTML specification will be continually updated, so there's always going to be time to extend the spec to meet changes in the web.

Thus far it seems to have taken the web backwards in terms of compatibility, many of the new features work differently in different browsers, harking back to the days of HTML3/4 and Netscape/IE battles.

The very minor incompatibilities between today's browsers are nothing like the incompatibilities of the Netscape/IE battles.

In the past, the two browsers had different box models, and entirely different syntaxes for DHTML. Modern incompatibilities tend to revolve around the best way to render rounded corners.

XML syntax seems discouraged which means you'll run into more people using the SGML syntax which seems to be pushed more than XML which makes the web more of a ballache to work with- no more of a push towards simple XSLT

Good! XSLTs are absolutely horrible.

Whilst XML is somewhat easier to parse than SGML, it's not like there's a shortage of good HTML parsers.

Also, unless you're screen-scraping data, a lot of the time you'll be using a JSON or XML RESTful API to pull data from websites.

It's not that I don't like some of the new features proposed in HTML5 like canvas etc., I think they're great ideas. It's just a shame the rest of it is just so painfully amateurish from a software development perspective... I'm hoping for a quick iteration to XHTML6, run by people who actually know what they're doing so we can just bypass the mess that is HTML5, but that's probably a bit much to hope for.

HTML may not be perfect, but it has one big advantage over other solutions: it's actually being implemented.

Re:Holding off using it for other reasons

[colinrichardday]

The ethos surrounding HTML5 is that well, lots of old sites didn't follow newer standards, so lets make those web sites standard by taking everything they did shit, and making that standard. So great, yes, let's make shit, the standard. No, that's not how standards work- standards define a high quality that allows maximum compatibility which developers should strive to adhere to, if some don't then don't cater to them- just point out they're shit because they're not standards compliant.

Even O'Reilly's HTML: Up and Running complains that XHTML's error handling was "draconian".

Re:Holding off using it for other reasons

[tepples]

Then you can write [span style="emphasis"], [span style="definition"], [span style="citation"] and re-map them to different font styles at will.

The advantage of using a well-known schema as opposed to using <div> and <span> for everything is that user agents will come with styles for these elements, even for obscure non-visual media. For example, speech already come with voice styles for the <em> element. And the advantage of the HTML5 schema over other schemas is that the HTML5 schema's pre-made styles are already available to your users.

For these, XML or XHTML make much more sense because (as you said) they're easier to parse.

Say you have an XML parser library and an HTML5 parser library. Both generate DOM trees. So what makes you say one is easier to parse than the other? Is it that one library is far smaller in code size than the other?

Re:Holding off using it for other reasons

[sgt scrub]

I guess it is important to remember, "complexity is relative to the individual". I've worked with XML enough for it to be just another format. To me writing an XSLT for an XML document and using a scripting language to manipulate the file is as normal as writing a CSS file for an HTML document and using javascript to manipulate the file. Well. They are literally the same exact thing but for some reason not immediately apparent to web developers.

Re:Holding off using it for other reasons

[tixxit]

Well, for instance, this comment is a valid HTML5 page.

Re:Holding off using it for other reasons

[BitZtream]

If you want to document a set of best practices for writing HTML, with rules for lowercase names and closing tags and quoting attributes and for indentation etc, that's fine and would be nice (especially if you could find a way to motivate people to follow the best practices - a decade of promoting XHTML doesn't seem to have stopped people writing terrible code so we need a better way). Meanwhile, HTML5 is solving the harder problem of how to cope with people who ignore those rules.

... So you recognize that XHTML does exactly what you said, defines the rules for making things sanely parsable ... and you ignore that and say HTML5 is solving the harder problem of how to cope with shitty 'web developers'.

Another ... is in order here ...

YOU BREAK THEIR FUCKING WEB PAGES SO THEY DON'T RENDER PROPERLY. They will then learn how to make pages that do render properly.

Not everyone needs to know how to make web pages in notepad, there are plenty of tools that will give you a GUI and let you design a layout purely by pointy and clicky. No one needs to know its an actual standards compliant xml document that is easy to parse without a parser written SPECIFICALLY FOR WEB BROWSERS that offers not advantages and adds another layer of compatibility issues .... mean while ... you're completely ignoring the fact that XML in fact does EXACTLY what you want to make HTML5 into.

XML is all about semantics. HTML isn't. You utterly fail to understand that you're saying we should replace this thing over here called XML that is built to do EXACTLY WHAT WE WANT with this other thing over here that some douche bags with existing BROKEN parsers they don't want to change say we should use.

HTML at this point should simply be an XML dialect, you're an idiot if you think it should be anything else.

Idiots will still write shitty, unparsable HTML5, you're completely clueless if you think HTML5 is going to naturally result in higher quality and accuracy output just because its different. I'd guess you've got no software development experience or user interface design experience at all since you seem to think you can take the lazy out of people by designing something easier for existing lazy people ... they just get lazier and cut more corners than before.

Re:Holding off using it for other reasons

[m50d]

The HTML 3.2 "standard" was a retroactive "standardization" of what was already implemented by IE and Netscape Navigator. So to the best of my knowledge the only HTML standard that was developed under the W3C standards process is HTML4 (and XHTML1 if you want to count it)

Re:Holding off using it for other reasons

[jetboy 70]

Something like polyglot markup? http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html This relies on the fact that XHTML markup is actually valid in HTML5. It may have taken them seven years to catch up with you, but they're there now. ;)

Re:Holding off using it for other reasons

[Firehed]

Which is the subtle difference between the "b" and "strong" tags, and "i" vs "em". The former in each pair indicates the desired style, where the latter indicates a style-agnostic level of content emphasis.

It's important to remember that most people (especially non-programmers) don't think about what they're trying to accomplish, just what they've done in the past to replicate the desired outcome. As such, it's very important as a programmer to not blindly give people what they ask for. "Make this open in a new window" often translates into "make a certain piece of information available on a different page accessible to me in a way that won't interrupt my current workflow", so a better solution is may be to just display that information on the first page. The same applies for text styles applied by content producers and editors. They don't want bold text, they want strong emphasis and the way they're most used to seeing that accomplished is via bold text. So semantically, <strong> is a better choice - and it gives you the ability to do a better job (maybe red, underlined text at at standard weight gets the message of emphasis across better based on the page's other styles).

That being said, whoever stated in this comment chain that the new HTML5 tag semantics are poorly thought-out was right. section and div are logically the same (you divide stuff into sections, yes?), aside is frequently misinterpreted to be a sidebar (it's closer to an inline details section, not entirely unlike the title attribute on an abbr tag), etc. audio and video tags are conceptually great, but the format/codec clusterfuck makes them all but useless. The new input types are decent; most of the interesting stuff is really in newer JS functionality and CSS3 attributes. One of the biggest issues is that most of the new semantic tags were based around content publushing, and designed to supersede microformats; there's a very weird overlap when building web applications.

Re:Holding off using it for other reasons

[BenoitRen]

What utter tosh. The HTML specification process was managed by the W3C whose members comprise just about every single industry sector under the sun and number in the hundreds.

I know. But their input wasn't welcomed by the XHTML Working Group while they were drafting XHTML2.

Are you seriously saying this is a less balanced process than a couple of browser manufacturers going their own way and riding a way of populism and ignorance to push their spec? I'm not sure how the current situation is better where sure comments are allowed, but they're ignored by grand dicator Hixie et al.

The WHATWG accepted input from everyone. Stop spreading lies.

The spec was taking time because it takes time to make sure things are done properly, and to make sure raised issues are examined, and, if need be, correct. WHATWG still don't get this to this day, which is why they've declared HTML5 a living spec, ready for use, rather than just waiting for W3C to ratify it when it's been confirmed acceptable.

I recall them saying that versioning should be dropped because HTML is an ever-evolving spec, which is pretty much right.

You seem to be ignoring all the work they did on HTML5 for years while the W3C was stuck with its head in the sand.

Right, so why does introducing new and important features require taking a backwards step, like pushing SGML-esque markup up the long proven beneficial XML markup?

• XML prioritises well-formed mark-up while the focus should be on semantically rich pages.
• It requires the client to check for well-formed mark-up each time when it's the job of the server/webmaster. If the check fails, you get an unhelpful error page instead of the content.
• It's an extra barrier of entry for beginning webmasters that ultimately isn't meaningful. Everyone should easily be able to publish on the web.

No but there is semantic meaning to be gained by adding something akin to CSS where you can either do it inline with semantic= or with a sheet declaring semantics which are applied to the relevant classes.

Moving the problem doesn't seem like a solution to me.

But here's the thing- WHATWG was made aware of ALL of these issues, from a number of sources, on a number of occasions. If it's so open and democratic, why did it pay absolutely no attention whatsoever? Because it's simply inept? or because it's not the open democratic group that you seem to believe it is.

It sounds to me like you're the one who is angry here that they didn't incorporate your ideas. Your idea also sounds like making HTML into something it is not, and that's bad for backwards compatibility.

Re:Holding off using it for other reasons

[BenoitRen]

But, as we've seen with XHTML 1.0, with Appendix C the concept of an XML-based HTML becomes close to useless.

Re:Holding off using it for other reasons

[geekpowa]

The moment you started ad-homing the parent and calling him a "terrible developer", you diminished your argument and damaged your own credibility.

The parent was criticising the a certain engineering philosophy with XML, and asserting that the complexity of XML is disproportionate to the benefits it delivers and that some poorly-defined aesthetic ideal has rail-roaded typical/pragmatic software engineering goals - such as being able to deliver a working, maintainable and supportable solution in a timely fashion. instead of defending and advocating the XML way you decided attack the parent with baseless accusations about his/her professional competency. You lose.

Re:Holding off using it for other reasons

[geekpowa]

Excellent post.

Re:Holding off using it for other reasons

[St.Creed]

XSLT, trivial? Have you ever tried doing anything useful with it?

I converted our primary mainframe application (COBOL) into an XML + XSLT app early 2001. We had migrated to a new application but we needed the old application for retrieval of non-migrated items. So we screenscraped the entire application into ASCII pages and I converted the ASCII pages into XML + XSLT, served up by a simple webapp (2 pages) that had the security we required. It actually performed faster than the mainframe we got rid of.

XLST is not trivial, but it's not that hard to write either. And when used in the right location, it can do some difficult things in a really elegant way.

Re:Holding off using it for other reasons

[yuhong]

Of course not, but do you really need to be an XML expert to write real XHTML by hand? I think you just need to learn to nest and close your tags properly etc.

Re:Holding off using it for other reasons

[wertigon]

The problem with your argument is that there really are many instances where that 5 hours tomorrow never come. Adopting "XHTML6" in your interpretation would mean that nobody could save those 5 minutes, even if I'm just writing a hello world page.

The trouble is, you don't know on beforehand which of these will benefit, and which ones won't. If you make sure to validate your pages, you spend a little time fixing the errors in your code, then you often don't have to go back to touch it ever again. "Be liberal in what you accept, but strict in what you publish" - A principle that has been with us since the first webbrowser.

Solutions only need to be as complicated as the problem itself. One thing that XML failed miserably is keeping simple things simple. SGML is simple. XML (particularly the latter versions) is anything but that.

By XML I assume you're meaning XHTML? So you mean that the four extra rules over HTML - Close all your tags, make attributes and tags lowercase, proper nesting and can't have more than one html tag - is so unbelivably mind-boggingly complex and hard? Especially since you should do most of this stuff in SGML/HTML as well (though there it's strongly recommended, not mandated)? You need a proper document structure, but that's true for both XHTML and HTML. XHTML isn't hard, but yes, it's not as forgiving as HTML. But you know what? These days it doesn't have to! Hobbyists install Wordpress instead of handcoding, like back in the nineties.

Not to mention XHTML offers massive speed improvements when served with the proper MIME-type. I developed a Javascript-heavy site (around 2MB of JS, and yes that was compressed) recently. I tried switching on the application/xhtml+xml MIME type, and got a massive performance boost from it (0.5-1s faster load times, quite a lot since these pages usually load in 3-4s) since the DOM could be parsed faster as you now could assume the HTML to not be broken.

Re:Holding off using it for other reasons

[wertigon]

Not to mention there are tools that help you with that, and most markup these days come from automated tools, like rich-content editors such as tinyMCE. Most pages should be possible to clean up in an automated fashion.

Re:Holding off using it for other reasons

[Xest]

"The WHATWG accepted input from everyone. Stop spreading lies."

Yes everyone, but again, what does it matter if they "accept" input, when they don't listen? How else do you explain the large amount of faults in the spec which have no reason to exist, but were pointed out to them time and time again?

"I recall them saying that versioning should be dropped because HTML is an ever-evolving spec, which is pretty much right."

Er, no, that's stupid. You clearly have no concept of why standards even exist in the first place if you genuinely believe this.

"XML prioritises well-formed mark-up while the focus should be on semantically rich pages."

Why prioritise when you can have both with the sort of solution I and many others have pointed out? The very premise you have to choose one over the other is false.

"It requires the client to check for well-formed mark-up each time when it's the job of the server/webmaster. If the check fails, you get an unhelpful error page instead of the content."

This is a FUD argument. Making sure content is well formed adhering to XML syntax doesn't inherently mean you have to serve it as XML. Just ensuring the content adheres to XML syntax alone gives you all the advantages.

"It's an extra barrier of entry for beginning webmasters that ultimately isn't meaningful. Everyone should easily be able to publish on the web."

But no one's publishing on the web now in pure HTML- they're all using blogger, facebook, twitter and so forth. You know, the kind of apps that are written by professional developers that would be better served by a spec that supports good practice software development.

"Moving the problem doesn't seem like a solution to me."

If you think the solution I suggested is just "moving the problem" rather than a fully fledged solution and you can't grasp that from my previous explanation then you have no place discussing this topic as you clearly don't even understand basic principles about web and software development. Putting style information in CSS style sheets wasn't merely about moving the content- it was about producing a far more flexible solution.

"It sounds to me like you're the one who is angry here that they didn't incorporate your ideas."

Which would be a great troll comment, if they were just my ideas. The problem is even Microsoft, the largest browser vendor on earth at the time pointed out half the flaws with HTML5 and whilst they've accepted now they're going to have to live with it as it is, they were clearly unhappy too with the process. When the process doesn't even listen to the largest browser vendor on earth when it points out legitimate faults, which to this day are not fixed, how can you seriously claim it's an open, democratic process?

"Your idea also sounds like making HTML into something it is not, and that's bad for backwards compatibility."

Backwards compatibility is done in the browser- changing a future HTML spec doesn't do a thing to backwards compatability providing the browser manufacturers are competent enough to ensure their browser handles the new spec properly without them simultaneously deciding to break the old spec. It's not a hard problem, computer scientists have been doing it years with supporting different protocol versions and so forth. But again, because you don't understand this it suggests you're trying to engage in a topic which you simply do not understand the details of. You sound like a fanboy who has jumped on the HTML5 bandwagon without actually really having any technical knowledge of web development and software development- you just know it's the latest buzzword, so feel you must defend it.

Seriously, if you're going to argue about a topic either learn about it first, or if you do understand it, try to avoid making comments that make it look like you're playing dumb for the sake of trying to make an argument.

Re:Holding off using it for other reasons

[Xest]

"The moment you started ad-homing the parent and calling him a "terrible developer", you diminished your argument and damaged your own credibility."

I only pointed out what he made clear from his post. You simply cannot be a good developer if you genuinely think quality should just be chucked out the window so easily. I understand in some projects it must, but implying it's never a concern? that's a bad developer.

"The parent was criticising the a certain engineering philosophy with XML, and asserting that the complexity of XML is disproportionate to the benefits it delivers "

Yes, if you work on very simple systems. Many of us don't, systems are becoming more and more complex, so XML is becoming more and more important. Developers who only work on simple systems and think their simple system mindset applies globally are destined to be left in the dust.

"You lose."

Oh right, I'm glad you decided that. Because obviously you're the grand dictator of who wins debates on the internet.

Oh wait, no you're not. You're just another online nobody who himself thinks he knows all, but manages to only demonstrate a lack of real experience in the field he likes to profess about.

Don't worry, perhaps one day you'll be competent enough to play with the big boys, on real projects.

Re:Holding off using it for other reasons

[geekpowa]

If you knew what sort of projects I've architected and delivered, I'm sure you'd be a little embarrassed with your last comment. But feel free to go off half-cocked and assume, without any data that you must be the most intelligent person in the rroom. Your attitude to both me and the other poster tell me all I need to know about how you conduct yourself professionally and allow me surmise with some confidence your capacity to run an engineering effort.

Re:Holding off using it for other reasons

[Xest]

"The problem with your argument is that there really are many instances where that 5 hours tomorrow never come."

Right. This is what COBOL developers used to say up until a few years before the millenium came along. Oh, and 640k is enough for anybody too.

"Adopting "XHTML6" in your interpretation would mean that nobody could save those 5 minutes, even if I'm just writing a hello world page."

Yes, except there's no time penalty to writing XML based HTML markup. So that assertion is false. The only downside is the initial learning curve is ever so slightly, but largely unnoticably more steep in that you simply have to learn about 4 additional very simple rules which come naturally about an hour after working with it.

"The truly worst code I've seen are the ones that try to be "future proof", "encapsulate functions", "pluggable", "modular", whatever. They make code that perform trivial functions look like a huge mess of spaghetti code."

Worst, or you simply don't understand them? When I was less experienced I found such well written systems harder to understand too, but for what you lose in difficulty for new developers you gain massively in productivity, maintainability, lower bug counts. Sure there are plenty of cases of overengineering out there, but to suggest it's universal is false. Just because some people fail to do things right, doesn't mean we should just do things bad all the time instead.

"Requirements of perfection (i.e. "separation of concerns", "lack of duplicate features", etc) is *not* universal, and you seem to be demanding it in one of the most widely used standards in the world."

It's universal in complicated software as that's the only way you'll ever get big systems built, and systems are getting bigger and bigger all the time so it's only going to become more important. Sure I agree small projects don't need it. I'm not advocating that everyone should have to adhere to these standards for every project- if people don't want to be standards compliant that's fine, but standards exist to support interop and HTML5 fails miserably in that respect which is a big problem. Standards should specify what should be done, and if it isn't then fine- just don't be standards compliant. But suggesting even the most poorly interoperable tosh with horrendous inconsistency is an acceptable standard? that's just an awful situation.

"One thing that XML failed miserably is keeping simple things simple."

But it's not necessarily designed to be. Although I don't personally think it's that complex, it's really not hard to understand XML. XML is designed to facilitate interop and to help make moving data between systems easier. Sure you might not think it's simple but it's tremendously good at what it's designed to do- far easier than working with arbitrary data formats. The web is the biggest thing in the IT world, wanting that to be just as easily interoperated with should not be seen as a bad thing- much less when HTML itself already has 99.9999% of the complexity of XML, so the minor added rules of XML aren't a disproportionate increase in difficulty relative to the massive benefits of a longer term goal- a fully interoperable web where data can be exchanged to web pages from documents, and from web pages into documents, and databases with simple XSL transforms. For someone not having any background in computing I agree XML might be difficult, but if someone is capable of HTML, they're plenty capable of XML so the argument of it being to complex for the web is just utter fud.

Re:Holding off using it for other reasons

[Xest]

"XML is never the right tool for the job, it's a perfect example of trying to be all things to all people"

I agree XML is grossly overused, but never the right tool for the job? That's silly.

"It's not really human-readable and certainly not human-writable"

What? It may be difficult to a newbie, but if you can write/read HTML then you can write/read XML. There's absolutely no difference in difficulty there.

"HTML is and always has been a presentational format; it isn't and shouldn't be a semantic format."

You know, I largely agree with this, but this is precisely why I said semantics should be applied with external sheets, just like styles are- precisely so HTML can stick to being what it is, a presentational format. I was under the impression you were arguing against me, but you seem to be agreeing with me here- if HTML is a presentational format and shouldn't have semantics embedded in it then why the fuck does HTML5 add an arbitrary and already outdated list of semantic tags? It just adds clutter to the spec, doesn't solve the semantic problem, and offers no real benefit. I'm not actually that fussed about the "semantic web" idea but my point is merely that if we are going to attach semantics to HTML, then let's at least fucking do it properly, rather than mix it in with the presentational markup in a very half-arsed manner.

"The original spec people spent about a decade coming up with nothing useful."

Look, avoiding the arguments about the usefulness of the spec (frankly I think some of it is useful personally) then even if mistakes have been made in the past, does that really excuse yet more mistakes like embedding semantics into the code in HTML5 excusable? WHATWG claimed to come around because W3C aren't listening- but they've not listened to the flaws themselves, they've produced a spec that's amateurish and as you point out, mixes semantics and the like directly into what should be a presentational format. Let's forget what the W3C has done wrong in the past- does that really make WHATWG's attempt worthy of avoiding criticism?

"The guys now in charge of the standards are the ones who wrote the software we all use daily to browse the web, rather than the ones who sat in endless discussions and produced nothing. I think you've got the wrong notion of who's inept."

Really? You don't think browser manufacturers are inept? How many serious bugs, how many serious security flaws, how many issues with performance, many of which are braindead flaws that should not even exist have we seen in browsers through the years. They may have been the ones that got us where we are, but that doesn't imply as you seem to suggest that they've done a good job. Browsers have, almost universally been shit pieces of software, we simply use them because they've always been as bad as each other. The only positive side to this is that at least competition is heating up in the browser market nowadays, so hopefully that wont remain the case.

Re:Holding off using it for other reasons

[Xest]

"Presumably things like this is why they dropped the version number and moved to a "Living Standard". The HTML specification will be continually updated, so there's always going to be time to extend the spec to meet changes in the web."

Agreed but it also means you can't necessarily write an HTML5 compliant site, and leave it for a few years, and still find it's HTML5 compliant. A living spec means the standard is changing- and that's just not what competent standards do.

The real solution would've been one that abstracts semantics out of the presentation document, just as CSS abstracts styles away from the presentation document. The point is that if your standard has to be a "living standard" then you've got a fault in your standard, and WHATWG, despite having these flaws pointed out to them, has moved ahead anyway. This implies that their interest isn't in producing a decent spec, but more likely simply hijacking web standards for their own goals. This seems to have been largely succesful too, HTML5 is controlled almost entirely by desktop browser vendors like Google, Mozilla, and Apple, with no input from the people who actually develop web applications, no input from people who produce accessibility tools and so forth taken into account.

"The very minor incompatibilities between today's browsers are nothing like the incompatibilities of the Netscape/IE battles."

Have you looked at some of the HTML5 inconsistencies between browsers? Some web apps using things like canvas outright just don't work unless you're using a specific browser. That seems at least as bad as the Netscape/IE days to me.

"Modern incompatibilities tend to revolve around the best way to render rounded corners."

Modern yes, things were pretty well nailed down in recent years between browsers for the XHTML and HTML specs prior to HTML5, but HTML5 changes all that, everything's up in the air again and takes us back to square one.

Re:Holding off using it for other reasons

[m50d]

It may be difficult to a newbie, but if you can write/read HTML then you can write/read XML. There's absolutely no difference in difficulty there.

People can't write HTML either, that's why browsers had to be as lenient as they are.

As for semantics, I agree that the semantic tags in html5 are a bit silly, as were those in earlier html versions. But I think the WHATWG are less semantic-obsessed than the W3C were, and have shown more focus on more useful things (e.g. video). If "an arbitrary and already outdated list of semantic tags" is the worst thing in the spec, I can live with that.

Browsers have, almost universally been shit pieces of software, we simply use them because they've always been as bad as each other.

They're the most successful pieces of software in history, and they got there by being pragmatic, and giving users what they want. Again, browser makers may not know about making something theoretically pure, but they do know about making something widely used - which is what you want from a spec.

Re:Holding off using it for other reasons

[Xest]

"If "an arbitrary and already outdated list of semantic tags" is the worst thing in the spec, I can live with that."

It's just one of many bad things, none of which really needed to exist.

"You can't get by with just OK products which is all Motorola have had for years. That is why they are losing money quarter after quarter."

Apart from operating systems you mean? Are you going to now tell us how awesome the likes of Windows has been all these years too?

"and they got there by being pragmatic,"

This simply isn't true, browsers never became popular by being software people wanted- on the contrary, IE5/IE6 was the bane of many people's lives, but what other choice was there for years?, they became popular because the web was a good idea and you had to use one to access it. It was the concept of the web that drove browsers, not vice versa, and that's why standards should serve to make the web better, not make lazy browser vendors lives easier by making sloppyness an acceptable standard.

The more things change...

[Anonymous Coward]

especially those who are looking to leverage HTML5 in hopes of unseating native apps.

Why do we keep coming full circle? WHY?

This is exactly where we were in 1998 with Java's "run everywhere, in a browser applet replacing desktop apps on the web, blah blah blah"; yeah, that went somewhere (right into a subsidiary of Oracle). The more things change, the more they stay the same, huh?

Attempting to replace native applications is ridiculous simply due to the impedance mismatch between the web environment and an application. The web exists to run in a sandbox, it was built mainly for multimedia interchange not as a software execution environment, the complaints about local storage and what not reflect that exact problem: you're in a minimalist sandbox, you have limited power and expressiveness by definition – that's kind of the point. The moment a browser allows something that fully behaves like a native application it will be a reinvention of Java and will have all the same problems that had. In some ways, it may even be worse what with the 'broken by design' WebGL specification that allows random websites to try and buffer overrun your system at kernel level. [For those playing along at home, Firefox: "about:config", set "webgl.disabled" to true]

Re:so what - it doesn't do innovation for you?

[master5o1]

Parse error: syntax error, unexpected T_STRING, expecting ',' or ';' on line 1

Perhaps it was Slashdot that removed your escape slash from the second double-quote mark.

MS is the obstacle.

[Anonymous Coward]

If HTML can be used to replace local applications, MS has the most to lose because people would not be locked to Windows anymore. So MS has been working with HTML5 community mainly to slow down things.

"Software engineers" don't do web programming

[Viol8]

They do real programming - writing device drivers, tuning graphical libraries , writing massively parallel simulation code. They DON'T piss about with HTML and javascript except in their free time for a hobby.

Yeah , mod me down all you moderating HTML "coders", I don't care, I have karma to burn.

Re:"Software engineers" don't do web programming

[maxwell demon]

Just wait until we get the ultimate XML programming language.

<statement>
  <assignment>
    <source>
      <sum>
        <term>
          <variable id="x" />
        </term>
        <term>
          <constant type="int" value="1" />
        </term>
      </sum>
    </source>
    <destination>
      <variable id="x" />
    </destination>
  </assignment>
</statement><!-- x=x+1 -->

Re:"Software engineers" don't do web programming

[pfafrich]

I think you have just invented MathML.

Re:"Software engineers" don't do web programming

[Eivind]

that looks almost like coldfusion.

<cffunction name="add">
      <cfargument name = "x" type = "integer">
      <cfargument name= "y" type = "integer>
      <cfset var result = x + y>
      <cfreturn result
</cffunction>

I wish I was kidding. And yeah, I -do- know about cfscript.

Re:"Software engineers" don't do web programming

[Raumkraut]

Just because most people who mess around with web technologies are numpties, doesn't mean all of them are. Engineers of any school solve problems, and sometimes that problem space involves web technologies.

Re:"Software engineers" don't do web programming

[Miamicanes]

The day some nutcase PHB rams a horrible language like that down my throat is the day I officially begin development of a C++ to X-- compiler. ;-)

Re:"Software engineers" don't do web programming

[StripedCow]

The sad part about this joke is that W3C is really forcing stuff like this down our throats. Instead, they should be focusing on providing us with the bare-metal methods to get things done. For example, were they to provide a standard for an accelerated virtual machine (without garbage collection), like NaCl, then a wealth of open-source projects could actually get things moving on the web. Imagine all the nice replacements for javascript and HTML that could come from that. That would be much more efficient than letting one organization control everything. Besides, they would have more time to actually work on the more essential parts of the standards, IMO information interchange and meta-data formats.

Re:"Software engineers" don't do web programming

[bberens]

While I agree with you that HTML is not "coding" in my experience it's harder to find someone who can provide meaningful input to user interface design and provide "pretty graphics" than it is to find a decent coder.

Re:"Software engineers" don't do web programming

[BitZtream]

like NaCl, then a wealth of open-source projects could actually get things moving on the web. Imagine all the nice replacements for javascript and HTML that could come from that.

Browser makers can't keep javascript from getting out of its sandbox and doing things it shouldn't ... are you really so stupid as to think that NaCl will be better? You want to run native code 'in a sandbox' that couldn't keep non-native code from exploiting the system?

You have WAY more faith in Google's engineers than ANYONE ANYWHERE should. NaCl is a horrible idea to anyone with half a clue.

Re:"Software engineers" don't do web programming

[StripedCow]

are you really so stupid as to think that NaCl will be better?

You should read up on their approach to security. They have multiple rings of defense. Very interesting actually.

Native code is much simpler than any scripting language can ever be, and therefore it is actually much simpler to keep things safe in a provable way.

Besides, did you ever hear about software running inside VirtualBox or VMWare infecting the host system?

Re:"Software engineers" don't do web programming

[shutdown -p now]

If you use <ecode> element, you won't need to manually escape each and every < and >

Re:"Software engineers" don't do web programming

[maxwell demon]

Besides, did you ever hear about software running inside VirtualBox or VMWare infecting the host system?

http://www.foolmoon.net/cgi-bin/blog/index.cgi?mode=viewone&blog=1185593255

Don't stop reading too early. The true escapes start at VMftp.

Re:"Software engineers" don't do web programming

[MightyMartian]

Yay! An XML programming language. That way, my source code will now grow by about a factor of 10, become almost impossible to read or debug, and ??? profit!

Re:"Software engineers" don't do web programming

[Dragonslicer]

"Software engineers" don't do web programming... They do real programming - writing device drivers, tuning graphical libraries , writing massively parallel simulation code.

Actually, "programmers" do real programming. "Software engineers" do the design and architecture of software systems. In small companies or groups, the software engineers and programmers are frequently the same people, but it's two different tasks that can potentially be done by different people.

Re:"Software engineers" don't do web programming

[The Dancing Panda]

Feeding the troll: Is that what you think web programmers do? HTML is just output. Javascript is a scripting language we use to speed things up for a decent user experience. Most of the actual work is server side, where we deal with convoluted business rules, integrating with databases, and generally designing websites that do some pretty cool shit, so people like you have somewhere to bitch. My bet is you "real software engineers" would have a difficult time writing the slashdot interface. And this isn't even particularly well done.

Re:"Software engineers" don't do web programming

[Eivind]

I didn't manually escape any of them. I just typed them plain then used "extrans" as the comment-type. Works fine, though I see I forgot a " and a >

Native Apps gone? Not in the next 10yrs at least

[geekpowa]

I've done extensive, years and years of programming in Native apps and I have done quite a few years in web apps too; using various stacks and languages.

The idea that the browser is going to replace a rich client any time soon is, in my view, a fools errand. I pity those who have thrown away perfectly good money over the past 10 years trying to make this happen. There are some success stories, like webmail and web-chat and various cloud services; but these things are comparatively simple animals in terms of their data/user complexity. Also there are alot failures which have cost alot of people money.

Browsers have slowly, very slowly eaten into rich client app space. But as soon as complexity of the application reaches a certain level, i.e. level of complexity you typically encounter in an accounting or stock control system, then cost to build the product becomes prohibitive and the UI suffers significant limitations.

Webapps are harder and more expensive and more time consuming to build, and the end result is typically a poorer UI experience. Imagine trying to write something like Gimp, or Open Office, or an accounting package as a web app as opposed to a rich client? Massively more complex. HTML/HTTP has come a long way, but it has to go alot further still if it is ever going to be beaten into a semblance of an architecture that is going to give the rich client application domain a run for its money.

I think it is inevitable a cloud architecture will emerge that kills the native rich app, but I am highly doubtful that HTML/HTTP will be powering that architecture.

HTML is NOT for applications

[TheDarkMaster]

The hard truth is that for more than fill with patches,for more you put ugly hacks, HTML is not meant to do the work of native applications.

Re:HTML is NOT for applications

[H0p313ss]

The hard truth is that for more than fill with patches,for more you put ugly hacks, HTML is not meant to do the work of native applications.

The problem is that you're about a decade too late with that argument. We've spent so much time and effort smashing this square peg into the round hole of HTML that the expectations are now incredibly high.

You can build real apps with HTML, just like you can build bridges with Popsicle sticks, all you need is buckets of glue.

Re:HTML is NOT for applications

[TheDarkMaster]

I know. I've been saying this for years but only one or two listens. I admit that even works to some types of applications such as HTML form-based applications (inventory control, requisitions, things like that), but are much more difficult, slow, ugly (you need many hacks to "emulate" native interface behaviour) and prone to problems than an equivalent running natively. And to do something like an instant messenger so it's almost impossible to run correctly or efficiently.

Re:HTML is NOT for applications

[slim]

Using WebSockets, you can implement pretty much as efficient an instant messenger as is possible in this firewalled age.

It's true that in the past, making a web page look like a native app has involved ugly hacks. HTML5 and related technologies remove the obstacles that make those hacks necessary.

Re:HTML is NOT for applications

[davide marney]

You might be looking at this too narrowly. HTML is just one client platform among many. You use it when it makes sense; in particular, when you don't want the bother of installing a native app in the first place. Like all other client platforms, HTML has limitations, and only fools with lots of time and money to throw away fail to respect them. In its sweet spot, HTML offers some truly unparalleled features that no other stack can touch (such as hypertext linking, for example.)

Re:HTML is NOT for applications

[TheDarkMaster]

And I agree too. HTML is good for that he is created for (hypertext, webpages, etc and etc). The problem begins when you try to create a "office for browser". You can make then work? Maybe yes, but at that cost? And is far worse when I read some crazy people that says "webapps is the solution for everthing, dinossaur"

Video

[jones_supa]

Remember when a year or two ago HTML5 video was proposed to replace Flash Player? Back then there was a lot of talk about it, but I guess it has never happened. Just pondering.

Re:Video

[jandrese]

There was too much fighting over which video standard to use with HTML5 and it killed that part of the standard in the crib. That said, Apple is still pushing it (because Flash video doesn't work on many of their platforms) so you might see some traction from that arena.

Re:Video

[BenoitRen]

It did happen on YouTube. You can watch many (all?) videos using the WebM format natively in your web browser.

The concept of browser is wrong.

[master_p]

Before modding me to oblivion, please hear what I have to say.

The whole concept of browser is wrong. Browsers are a good solution for serving static documents; it is not a good solution for delivering cross platform dynamic applications.

This article about HTML5 proves that no matter what functionality is hardcoded into the specifications, developers might need more or different functionality.

What is required for serving today's distributed world is a mechanism (a service) that does the following:

- lazy downloading of software components (data and code). Code and data are downloaded only when requested. The mechanism makes sure the code/data are cached locally, so as that if the network fails, the application is still usable.

The current technology fails at this because the downloaded software components can only be one of these:

a) Javascript, which comes with a lot of disadvantages (browser needs to have a Javascript interpreter/compiler, Javascript itself has lots of disadvantages etc).

b) a binary file that requires the installation and maintenance of an add on (flash, Java, etc), which in turn does its own maintenance, adding services to the core O/S etc.

All the above could be avoided with a unified component management mechanism.

- automatic versioning of components. Code components should be automatically versioned by the compiler, so as that the linker at the client side can request an updated component only if the available version is newer than the locally cached version. Downgrading would be automatic if the newer component's symbols do not match the symbols required by another component. The mechanism should keep the old versions of components around in case some component cannot work with the newest versions.

The current technology fails at this, because although the browsers check the version numbers of the add ons against the browser, user interaction is required for the acceptance of a solution (i.e. the users have to accept the new versions by clicking OK, meaning that they know if the new version is appropriate for them).

- both native and bytecode components. The component service should be available for native as well as bytecode components. The service will run a virtual machine, the definition of which should be a native component downloaded lazily and cached as described above.

The current technology fails at this, because it doesn't even have the concept of a component, let alone the concept of native or bytecode component. Browsers only know of addons and extensions, and each browser comes with its own addon and extension model.

- a binary (i.e. non-text) metadata protocol. All information exchanged over the network, including software components and data components, should be written in a unified metadata protocol. The protocol itself will not specify semantics, it will only specify structure. Think about this protocol as a binary version of JSON or XML.

The current technology fails at this, because all the used formats are text-based.

I know many people will disagree with the binary protocol and prefer a text protocol. The text protocol doesn't really offer any advantages over such a simple binary protocol. The main advantage of the binary protocol is speed, because of the much less data required to cross the wires compared to text. The main advantage of the text protocol is that the text buffers can be inspected as they are, but if the binary protocol is simple enough (as is JSON, for example), then very little work would be required to make a tool that displays the contents of a binary buffer.

Think about it this way: the cost of writing a tool that displays the above-described binary protocol's contents is extremely minimal when compared to the savings from using the binary protocol.

A unified communication language between computers is extremely necessary as the first basic step for inter-operation between computers: computers may not understand the semantics of the data, but at leas

Re:The concept of browser is wrong.

[TheDarkMaster]

Interesting ... In a nutshell, you suggest a "generic application container", working in conjunction with an external server maybe using plain TCP/IP sockets. Would do this using Java and some extra libs, if it was not a hell to create a decent GUI using it.

Re:The concept of browser is wrong.

[ByteSlicer]

You might want to take a look at NaCl. It's not exactly what you describe, but it seems to have the security part pinned down. And there are plans for local storage, sockets, etc. You can already use it to run a full DosBox in your browser (running a game with graphics/music/mouse).

Re:The concept of browser is wrong.

[PJ6]

This article about HTML5 proves that no matter what functionality is hardcoded into the specifications, developers might need more or different functionality.

That's because HTML is at too high a level of abstraction to ever sufficiently cover everything an application may need to do, or lend itself to any manageable definition of compliance. The standard needs to be on a lower level and defined by a relatively static object model with versioning defined by a set of unit tests.

.NET's IL could have served this purpose if MS hadn't screwed up Silverlight so bad.

Re:The concept of browser is wrong.

[Anonymous Coward]

Uhm... javascript disadvantages are there, but none of what you describe above... Browsers all have javascript interpreters build in and working. Javascript is great for what it is supposed to be doing. Stuff like doing event handling for a UI. Having snippets of code that "does it's stuff" when "something" happen.

And getting anyone to agree to a unified component model... I must laugh... Try getting Apple and Microsoft to even enter a conference with that as the title. And if you invite Google also, will anyone come?

Web apps will succeed because there is no alternative to them. It is the only "unified" platform out there. It may not be prefect, A few of the problems are actually described in the article, though many of his perceived problems are nothing to do with web applications and HTML but with applications in general especially native applications (All the security and data storage nonsense he speaks about, that are double as problematic on native apps than on web apps)

And as long as someone is allowed to "own" a described way of encoding, transporting, decoding and showing a stream of data to be used for either movie or audio we will have problems with players and formats. This is not to do with HTML5 or browsers, though it is a real problem there... It is a problem for native apps too.

Re:The concept of browser is wrong.

[davide marney]

Some very good analysis and thinking. I second the post about Google's Native-Client technology. The API is here.

Re:The concept of browser is wrong.

[EriktheGreen]

You missed one major point, specifically why the browser as a universal replacement for local apps will fail, and why more generally the idea of "everything in the cloud" will fail, despite it being quite a major fad among the management types currently.

Interactivity and control.

Until technology takes a giant leap and remote or network data access becomes exactly as fast as local bus data access, locally stored data will always be faster to access than remote data, so any program that requires access to more data than can be locally cached will run better on a local PC. Sure, all processing and the actual program can be located on a remote server and a window presented remotely, but in the case of some programs such as non linear video editors, this isn't a significant bandwidth savings.

Control is the big issue. With governments and other authorities becoming more and more intrusive on the net, and with no solid laws governing privacy of data held by a third party, right to privacy on the network itself, the relative reliability and security of network held data compared to local data, and simple paranoia, maintaining control of your computing resources will always be a must for a large portion of the computing population. So no cloud storage for some things, keep it on your local PC.

Computing resources have always followed a cycle of centralization and de-centralization. Corporations have always capitalized on this as the "coming thing". Managers have always believed them. Cloud computing and the apparent "trend" toward a generalized markup language that can empower every type of application in the world is just another tech trend that will eventually find a niche, but not completely replace other types of computing.

For an interesting comparison, look up and check out industry articles on Java when it was first gaining momentum... at one time we were all going to have local Java machines and all data and programs would be universal and stored online. That idea was actually closer than HTML5 to a generalized non local computing environment.

When I hear someone today say something like "We don't need to build out our data center, the cloud is coming" I have to avoid laughing.

HTML 5 is an improved markup language, but it's still just a markup language. The underlying concept of GET/PUT across the network limits its utility.

Erik

Re:The concept of browser is wrong.

[Pascal Sartoretti]

The whole concept of browser is wrong. Browsers are a good solution for serving static documents

A Slashdot page is not a static document (anymore), and a browser is a good tool to serve it.

Re:The concept of browser is wrong.

[TorKlingberg]

The main advantage of HTML+JavaScript in a browser is sandboxing. A webapp cannot mess with your hard drive, unless you allow it to or there is a bug in the browser.

Re:The concept of browser is wrong.

[CBravo]

Interactivity and control.

Most people don't need it doing business work. Your example is the corner case.

Re:The concept of browser is wrong.

[EriktheGreen]

If by "business work" you mean spreadsheets and word processing, then you're correct.

However, most businesses have larger applications like payroll and benefits, financials, marketing, and others that they definitely want control over. Try convincing the average business owner to put customer data and marketing plans or product designs "out there" in the cloud and see how far you get.

It's easy to imagine ordinary work being done in a browser based application format, but instead of spreadsheets think automated check handling, and instead of a word processor imagine a writing marketing copy with images suitable for transmission to a print house.

I think most of the people saying "everything can run in the cloud" or similar don't have much experience doing anything but the basics on a computer, like filing taxes, playing games, or writing e-mails.

Erik

Re:The concept of browser is wrong.

[CBravo]

You are mixing 'browser' app and 'cloud' (where most people assume external cloud). They are not by definition coupled.

I do however think that many office applications, e.g. Excel and Word, will remain on the desktop for a long time.

Btw, the company I work at has http://www.reeleezee.nl/ for online bookkeeping (5M$ turnover / year). Most companies I worked at have external payrolling.

Re:Quite

[Anonymous Coward]

You missed the "Get off my lawn statement".

How does that even matter? Seriously. I learnt to program in Visual Basic, ffs, in fucking Visual Basic! And I knew perfectly at that time that it wasn't meant to solve everything (later I would realize it wasn't meant to solve anything). A course is not intended to teach you every possible language, tool or solution, it's you who should investigate what is the better approach to a project, and what are the advantages and disadvantages of choosing one instead of the other. There isn't a silver bullet and never will be.

If there is something to blame is the managers who hear buzzwords and suddenly feel that unavoidable feeling of reimplementing everything from scratch.

The Server Controls the App

[tvlinux]

The Server controls the web app.
The only data in the client is temporary local data and display data. All data is stored on the server.
When a user logins in a session is created. At this point resynchronization happens. All the data stored in the client is downloaded to the server. the server then deals with what needs to be updated.
Yes, expect people to try to crash the server and corrupt data. Design the server framework to deal with it. Then the server application does data validation and checking. then finally use the data to update the server storage.
The standard frameworks now do not deal with "Data Only" processing. By using a server framework the uses small callbacks for RPC with session security tokens creates a secure enviroment.
The biggest problem are RPC calls that are automated to harvest data. This can be mitigated by throttling in the server framework.

Are you kidding me?

[devent]

"formidable competitors for native apps" Are you kidding me?

How is that even with a DSL line I have to wait at least 500ms for a reaction of the so called "app" to be a "formidable competitors" for my native application? I'm sorry to burst your bubble, but even if you get JavaScript 500% more faster then it's now, it's nowhere a native application, with local stored data is.

Even slashdot.org is a very poor replacement for my email client. I take my email-lists with my local email-client anytime before I post in this poor "Web 2.0" forum of slashdot.

Please start to develop sites with some kind of content, that is for what the Web is designed for. Maybe then I will visit your site. But don't confuse a web site with a native application. Even in 2011 we are nowhere that I can be online 24/7 with a good connection from everywhere. I take my laptop and my local installed apps with my local available data anytime.

Re:Are you kidding me?

[maxwell demon]

And don't tell me you belong to the 2% of people that take backup of your laptop...

If 2% of the people take backups of his laptop, he surely finds one who is willing to restore his laptop from that backup. :-)

Re:Are you kidding me?

[TheDarkMaster]

Try to use your webapp on a PC with dial-up connection to the Internet... Broadband always-on is NOT a universal resource.

Re:Are you kidding me?

[colinrichardday]

A well programmed web app is both fast and responsive (even when data exchange is sometimes slow due to network latency) and is in many cases much better than having a native app.

How would having LaTeX as a web app be better than running LaTeX natively? And how will you eliminate network latency?

No need for complicated install and maintenance. No libraries (no need for special permissions from IT in your company etc.) and no need to check for updates or have a special application run on your system to notify you of updates. The application is automagically in it's newest state when you start it!

So can Yast and synaptic.

Analyze the reasons!

[drolli]

>> HTML5 hard truth No. 1: Security is a nightmare The fundamental problem with client-side computing is that the user ultimately has control over the code running on the machine. In the case of Web apps, when your browser comes with a great debugging tool, this control is easier than ever to abuse.

Relying on the client not being able to understand the executed code is not even security by obscurity but even worse. Relying on client-side checks for consistent data (or even authorization - yes i have seen that) was stupid since the beginning of the web (and before).

Layer your spheres of access correctly, and there will be no bigger problem

> HTML5 hard truth No. 2: Local data storage is limited

Local storage is *always* limited. Relying on having near infinite local storage is something which also pisses me off for Desktop apps.

> HTML5 data storage capabilities are certainly an important addition, but you still can't move stored data to another machine, make copies, back it up, or open it with a different app. It's all buried deep where the browser hides it.

You is the user or the service provider? And *nobody* hinders you to implement also local backup mechanisms and free export of the data for the user. If you dont have the creativity or the knowledge to do so, then dont the fuck try to write a serious application. And if you back up you machine, your browser data is backed up with it.

> Nor can you dig into the files to see what is stored there. Sure, a programmer can take them apart, but only after studying the format and doing some hacking. They're not like spreadsheets or text documents that are easy to open with any editor, making the data less resourceful than it might otherwise be in a desktop app.

Wow. As if the average Desktop application would have completely open, understandable and easy to read data formats.....

>HTML5 hard truth No. 3: Local data can be manipulated

Uhm. did we talk about the server-side consistency check. And if its (according to the Truth Nr. 4) so much easier in the case of a pure desktop application to edit the data would that be not better in the sense of Truth Nr. 5?

> HTML5 hard truth No. 4: Offline apps are a nightmare to sync

Yes, always. Hasnt a single thing to do with HTML5

> HTML5 hard truth No. 5: The cloud owes you nothing It's not really fair to blame HTML5 for all of the structural problems with storing your data in the cloud, but the cloud is an essential part of the vision, which leverages the cloud to fix all of the headaches for installing software and backing up data.

The cloud is *not* an essential part of "the vision" of HTML5. It is a promising approach to deliver services cheap, HTML5 or not.

HTML5 hard truth No. 6: Forced upgrades aren't for everyone

Forced upgrades? We never had these before....

What is this. Sony forces updates to the PS. MS forces the installation of the WGA. Whe web-mail providers i use update senselessly all the time, since 10 years.

HTML5 hard truth No. 7: Web Workers offer no prioritization

A well written program relies on message passing and not polling. As a programmer i seldom had to prioritze threads withing an application.

HTML5 hard truth No. 8: Format incompatibilities abound

Yes, thats sad. The standard is still in the flow.

HTML5 hard truth No. 9: Implementations are browser-dependent

html has been browser-dependent since a long time, and so was java (not badly). Native applications are OS-dependent.

So what. An IT professional who thought that HTML5 would be the magic wand to overcome incompatibilities between environments with testing would have been stupid.

HTML5 hard truth No. 10: Hardware idiosyncracies bring new challenges

Funny. What you want to say: make a 3d game and it wont run as well on a handheld device without acceleration? Yes, that has been pretty much my experience the last 20 years.

HTML5 hard truth No. 11: Politics as usual

Honestly? An HTML5 only problem? Well....

Re:Analyze the reasons!

[drobety]

Thanks for deconstructing the silliness, it reads well, as opposed to the original article, which I had stopped reading at "HTML5 isn't the solution for every problem": I was unaware that HTML5 was held as solving "every problem." It struck me as a strawman, and right at the start of the article, so I figured the rest wasn't worth reading.

Re:Quite

[CadentOrange]

I'm not blaming them (well ok , a bit , you'd think they'd be curious about what went before in their chosen profession) , its generally the fault of the courses they've been on.

If they're not interested in pushing the boundaries of their knowledge and abilities, they're going to get left behind by their peers who do. The only problem I have is that these are the type of developers who seem to get fast tracked into management ...

Re:HAHA !! WEB APPS ARE FOR LOOZERS !!

[jd2112]

I'm going to wait for HTML 6.

Perhaps by then the Internet will be running IPV6.

:-) I couldn't keep a straight face from the previous comment.

Re:Native Apps gone? Not in the next 10yrs at leas

[CadentOrange]

[snip] Imagine trying to write something like Gimp, or Open Office [snip]

For the majority of users out there, Picnik and Google Docs work just fine. I personally prefer Google Docs over MS Office or Open Office, and if it weren't for the fact that I am a serious amateur photographer I'd be perfectly happy with Picnik. As it is, I need Lightroom. I think the trend will be that native apps will be relegated to niche applications that cater to power users. The average user will be easily served by web apps.

Nice new things

[Anonymous Coward]

I have to be honest, all this talk about XML vs HTML5 and good programmers vs bad programmers is completely uninteresting for me. What I see when I look at HTML5 (both in terms of spec and hype) is css-gradients, sockets and a canvas.

Everything else is just talk that can be summed up in the following: Coding web-applications IS NOT like coding desktop-applications.

Solution ... Explorer

[fartrader]

It'll all be fine when MS releases their explorer-specific extensions for data storage and security.

Re:Quite

[maxwell demon]

The fundamentals never get out of date. A new language may come with a new syntax and with new libraries, but only very rarely it comes with a new programming paradigm.

Re:Can I have an "Ahmen!" or at least a "well duh!

[ciderbrew]

I like how you've signed your post.

Work offline

[tepples]

The browser is the view, the only thing it gets sent is data to display.

Then how well does your application work offline? With HTML5 localStorage, limited though it may be, users are going to expect to be able to use your web application even with zero bars. Not everybody can afford $60 per month for the privilege to connect to the Internet during the daily commute on public transit or while in a shopping mall that provides Wi-Fi access only to employees and not to shoppers.

Re:Work offline

[BitZtream]

Then theres a good chance that an HTML app isn't the right way to go.

Stop trying to pretend HTML and JS are a proper way to make an offline app.

They AREN'T.

Just because you CAN do it, doesn't mean you fucking SHOULD do it.

HTML5 local storage should be used where it can for speed improvements and saving bandwidth, not to shoehorn HTML into something it shouldn't be. I'm sorry all you know how to do is throw around javascript and html, but that doesn't make you a developer and that doesn't mean you should try to write desktop/offline apps.

Use the right tool for the job and stop trying to hammer nails into concrete with a small electronics screwdriver and the whole article becomes false.

The only 'hard truths' about HTML5 is that it doesn't fit every problem and things get rather difficult when you start using it for something it wasn't meant for ... i.e. anything more than a presentation layer.

Re:Work offline

[naglep]

So, all-knowing one, what is the proper way to develop an offline Web App?

Re:Work offline

[tepples]

As I understand BitZtream's comment, BitZtream would prefer that developers make a set of five native apps: one for Windows, one for Mac OS X, one for GNU/Linux, one for iOS, and one for Android.

Re:Work offline

[Unknown Lamer]

There are other ways than rewriting the same thing several times. You don't even have to use C or C++. You already need at least different layouts for desktops, tablets (really just desktops without the input devices), and phones (or: tiny screen devices) for an application to be usable. So what is the advantage of using an overgrown design-by-committee hack that has repeatedly rejected all innovation in the name of compatibility? It doesn't help that HTML5 is probably more difficult to implement than the entire rest of an operating system.

Re:Work offline

[Firehed]

I think he was saying that an "offline web app" is basically an oxymoron.

If you want to use HTML to make an application that's designed to work offline, fine. It's the wrong tool for the job, but these days you can make it work. But if you're building a standalone app, that means you're going to have to make a lot of assumptions about the validity of client-supplied data if you're syncing with a remote server when online connectivity is available. Or go all-out, and do stuff ONLY client-side; and the only thing the server does is provide the initial content and effectively install the web app - in this case HTML and friends are just tools to develop a typical downloaded application.

A perhaps more appropriate implementation of HTML5's offline tools is akin to what Gmail does - allows you to continue working at 90% capacity if your connection flakes. Queue outgoing messages in local storage until network is restored, then send them off as soon as it's possible. Do some local caching so that you have access to at least your most recent messages. It's not designed to work offline 100% of the time (it's fundamentally reliant on server-supplied data) but you're not hosed when signal drops to nothing. Think "Google Gears".

Re:Work offline

[CBravo]

The same way you do offline phoning... lol.

Re:Work offline

[grcumb]

Then how well does your application work offline?

As the GP said, you don't trust the client. In an offline or semi-connected scenario, you can still maintain data integrity on the server side. Nothing changes there. If the client chooses the play silly buggers with their own copy of the data, well... that's on them. But when it comes time to sync with the server, the same rules apply as ever did: You perform as much data validation as you need to in order to make sure that one client's actions don't pollute the pool for the others.

It's true that there are edge cases where this might become a problem. One scenario that springs to mind is the use of client data to establish precedence in a queue (e.g. take-out food orders - someone alters location or time data to make sure their order gets made before anyone else's). Software probably can't save you in such cases, but real-life experience will probably teach you to identify those who are gaming the system and you can use other metrics (e.g. CC number, user ID) to mitigate the damage that they do.

It's just the UI

[erktrek]

Having written a (still running) patient flow management system in html3 + hidden frame + javascript - sadly no ajax it is my belief that with proper care a web interface can be used in place of certain local apps. For processes that do not involve complex graphical/video wizardry (i.e. most business apps??) HTML[5] seems adequate enough. This includes many day to day internal business applications where the benefits of management, maintenance & security outweigh most of the drawbacks: bandwidth, hw compatibility, less seamless UI etc.

Separating out the business data and logic/api from the interface also does wonders (ye olde "n-tier" architecture) for the client-side concerns. Everything properly validated through the server-side logic layer.

Migrating an existing local app to the web can be a headache though - then you run into potential usability issues with user expectations and proper program "flow".

Douchebaggery Gone to Seed

[lysdexia]

Surprise! The awesome new tool set has failed to alter the basic workings of HTTP! Golly! You mean a couple of years of hard work by smart humans to create a framework that materially improves the most amazingly successful communication medium ever and has been wonderfully useful from the very beginning has fallen short in some ways? It's an OUTRAGE!

Jaded Editor: 'Hey Contract-Face! Extrude me some "bitch-quip" fodder for the golf course! Make it Slashdotty too!'
Failed Techno-Poet: 'By Your Command.'

These are not "hard truths" these are "speed bumps". Is there an ISO standard waiting period for historical revision?

These are NOT the hard truth.

[Tei]

There are not the real problem with implementing applications with HTML5+Javascript (Except maybe 4).

Most of the things this dude list are normal challenges of any program in any platform. So some photos uploaded with a plugin got deleted by facebook? thats the problem of any website hosting content, can be deleted by the owner of the website, how it was uploaded is not important (could as well be uploaded by a nice interface? thats better).

The REAL problem of HTML5+Javascript is Javascript. Writting small javascript task is something everyone can do. Writting big javascript apps is NOT for everyone. Javascript is not strongly typed, and his dynamic evaluation is HARD. Javascript uses some float number that has less precision than the one you get on most generic programming languages. Javascript flexibility to be written by billion different ways means code from programmer A can be totally different than code from programmer B.... there are only 1 javascript, but there are more than 4 or 6 ways to writte it, that are completelly different.

In short:

Writting a big program in Javascript is a NOT TRIVIAL task.

This is really THE hard truth about applications made by HTML5+Javascript.

Perhaps a little better context for the features

[WebManWalking]

The real purpose of offline web apps is to deal with the challenges of mobility, not to replace the server as the official source of data, and not to move workload off of other computers that are getting overloaded. WiFi isn't universally available. Sometimes you can't connect to the Internet. Offline web apps are a mechanism for saving updates for later upload, a note pad if you will, but one capable of storing information in a format convenient for rapid sync when reconnected. The limitations of local storage are no big deal in that context. Local storage is just a store-and-forward mechanism that you have to tailor to your particular application.

Another major advance in HTML5 is accessibility. The purpose of the new article, section, etc, tags is to provide context to screen readers for the blind. Charts and graphs rendered in Inline SVG are directly readable by screen readers, unlike the pixels generated by Canvas and Java AWT. CSS display properties of table, table-row and table-cell replace table, tr and td for information that's NOT tabular, so that screen readers will not try to read them aloud as if they were. (HTML5 acknowledges that CSS and JS are part of the browser environment. Display properties are currently listed at 10.2.2 in the spec.)

The logical data types of Web Forms 2.0 input tags allow data validation when JavaScript is off, minimizing unnecessary hits on the server when the data entered isn't correct. What a convenience to both the client and the server!

In general, it's not a good idea to jump to conclusions about what someone means, then criticize them for something they never said. Read the HTML5 spec. Much of the context of why features were added is explained there, and in pretty clear English at that.

Re:HTML5

[Gerzel]

It isn't the only or even the major reason they don't want to move.

Really the biggest reason is sheer inertia. Knowing MS Office in HR is synonymous for knowing how to use word processing and spreadsheets. The thought that there might be an alternative never even occurs to those who would be responsible to make the decision to switch in most businesses.

HTML5 is enough for everyone

[lowlevelio]

Until HTML6 is released.

General Truths to all framework upgrades

[Synerg1y]

1. There will be legacy users
2. We are upgrading to introduce new features, not a version #
3. There will be yet uncovered security bugs, this is acceptable because other systems such as the f'in router will compensate
4. Unless it is the cloud itself, the upgrade has absolutely nothing to do with the cloud, it's code, not applications (ex. the application that makes the cloud possible).
5.You must have the upgraded framework to use the upgraded apps/pages/code
6.Not every feature may work as expected, thus hotfixes

Common sense
1. Don't save sensitive data client side
2.There will always be haters/lovers of the upgrade path, these should be exchanged for a white paper / tech spec
3. If your browser runs slow on your computer, you need to...
a. upgrade
b. install anti virus/spyware

Where above do I mention HTML5?

No Qt for iOS, Android, and Windows Phone 7

[tepples]

Conspicuous by their absence from list of supported platforms are all currently popular smartphone and tablet platforms in the United States: iOS, Android, and Windows Phone 7.

Re:No Qt for iOS, Android, and Windows Phone 7

[Unknown Lamer]

None are officially supported, but there has been work done to support at least Android and iOS. I think the lack of a WP7 port is more Elop running the company into a ground crap (I mean, if you could write a Qt app for Symbian or Meego and port it to the new Microsoft-Nokia devices...) so that may be rectified. Personally I think WP7 is doomed within a few years, and iOS not too long after that (be warned, I am also a Free Software nut so ...).

Re:Quite

[Eskarel]

Personally in this instance I blame Steve Jobs. He made all sorts of wild claims about HTML 5 in order to justify the fact that he won't let iOS run anything which remotely appears to threaten the app store as the only source of applications(including certain elements of HTML 4 forget 5). People started to believe that there was a lot more to HTML 5 than there really is. Let me let you in on a little secret folks, very little from HTML 5 or even CSS 3 will make any actual difference to how web applications are written offline storage is vaguely interesting, and some of the new CSS will help though semantic CSS isn't all that useful for actually building apps as opposed to showing content. Javascript hasn't changed and that's really the core of the web as application in the end.

Re:HTML5

[mabhatter654]

but in reality many of Google's projects are something somebody could whip up locally quite easily. The fact is that people didn't want all THEIR information in the "cloud". Companies LOVE having their stuff in their own data centers. There's little reason for many, many apps to be native anymore. But you have to remember, even then most "corporate" apps are 20% "secret sauce" for whatever industry they are in and 80% window dressing and boilerplate, even then they're almost always front ends for databases anyway. Moving to "web" apps make sense because with a small bit of extra effort, you readily add iphones, iPad, and all those other devices in addition to PCs. 75% of the programmers out there spend their time on stuff the public never sees... like designing exciting new TPS reports!

I think many people really miss what HTML5 was supposed to do. It's origins are in the COMMUNITY not the big software makers. In fact it was probably a mistake to even bother with the Adobe, IBM, Microsoft because they don't make their livings USING HTML. HTML5 was from Opera, Mozilla, KHTML, A List Apart, etc. The group of small companies that make their living writing browsers and designing pages for companies. HTML5 was a "cleanup" job to take what the industry learned in the NINE years since HTML4.01 was finalized and implement some shortcuts that are meaningful for DESIGN work. They also figured they'd grab some ground back from Flash for stupid-simple stuff nobody should have been using Flash for in the first place.

HTML5 won't be the "desktop killer" people are hyping.. except that in most companies procedures are so regimented that moving stuff from native apps to HTML5 really isn't that much harder. HTML5 is a good break point. It's been 9 years since HTML4.01 was finalized. Plenty of time for an upgrade and there's enough added of value to start breaking things rather than supporting the past. Personally, I think HTML5 should have FORCED the XHTML issue more as well as FORCED validation to DTDs. That would start culling the old pages to "legacy" mode pushing them to be updated just to make the "warning box" go away.

Re:Native Apps gone? Not in the next 10yrs at leas

[BenoitRen]

While I agree with your points, sir, I'd appreciate it you typed "a lot" instead of "alot".

We've been duped!

[ErikZ]

The truth is, despite its powerful capabilities, HTML5 isn't the solution for every problem.

I want a solution for EVERY PROBLEM!

Re:We've been duped!

[drb226]

Flash has none of these problems! Flash solves everything. /sarcasm

Re:Perhaps a little better context for the feature

[colinrichardday]

Another major advance in HTML5 is accessibility. The purpose of the new article, section, etc, tags is to provide context to screen readers for the blind. Charts and graphs rendered in Inline SVG are directly readable by screen readers, unlike the pixels generated by Canvas and Java AWT.

Except that inline SVG predates HTML5, and Canvas is part of HTML5.

HTML5? More like Web 2.1!

[Graymalkin]

It kills me that the people five year ago that were exclaiming Web 2.0 and JavaScript web apps were the future are now decrying HTML5. Even the Web 2.0 stuff was an extension of ideas Netscape was espousing in the 90s. HTML5 has simply become the latest brand name for that same concept. Google could switch GMail to "HTML5" by changing a few of their document tags.

I think the only difference now is IE6 is finally a marginal statistic in terms of browser usage so babysitting it isn't absolutely necessary for web apps. There's also finally a focus on page scalability and accessibility as a huge portion of an app's users are on mobile/touch devices.

There were always classes of applications that were never going to replaced by Web 2.0/HTML5. What comprises that list has changed (and gotten smaller) as browsers and app writers get more sophisticated. Ten years ago you had rudimentary JavaScript and unsophisticated browsers so basic data entry with HTML forms was practical. As JavaScript engines improved and browsers became more capable the likes of GMail and Google Docs became practical. To do sophisticated apps in 2001 you needed to use a plug-in or Java while today the same functionality can be done entirely in JavaScript in the browser.

There's lots of LoB apps that really have no business being native apps (VB6, Delphi, etc.). These are slowly being transitioned to web apps not only their requirements have changed but the environments have changed. If the CEO decides they want to look up reports on their iPhone or Droid, the reporting app is going to see a quick transition from a clunky VB6 monstrosity to a web app. The same is true for consumer apps, if a large portion of your users switch to Macs or phones (or you've tapped out the Windows market) that native app (a glorified database front end) becomes a liability rather than an asset.

CSS/Javascript sucks even for routine pages

[Animats]

Remember how CSS was supposed to make web pages more compact, and simplify layout by avoiding old-style table based layout? Look at how that worked out.

Here's a single article from the Wall Street Journal. It's 3299 lines of HTML. That doesn't include anything pulled in from style sheets.

As an exercise, I went through and took out all the junk. The actual story, plus all the formatting needed to display the full page in in its original fonts, is 77 lines. So what's the rest? Some of it is links to other stories, but that's under 100 lines. Much of the code is ad-related, even though there are only a few ads. There's a lot of "social related" stuff, which, although it takes up little screen real estate, seems to require far too much on-page code. The "login" mechanism turns out to have all the code for not only "login", but registration of a new account, as part of the page itself. That's on every page served by the Wall Street Journal. There's a vast amount of hidden content, including a "video carousel". There's personalization stuff that would turn on if the user was logged in.

When the people who code crap like that start using HTML 5 with both local storage and connections to the "cloud", it can only get worse.

Re:Perhaps a little better context for the feature

[WebManWalking]

Inline SVG isn't the same thing as SVG images, which did precede HTML5. In Inline SVG the SVG tags are embedded within the HTML as if they were HTML tags. That's newer, since the creation of HTML5 spec. At the time Firefox 4 implemented it last year, then-current versions of Google Chrome, MSIE, Opera and Safari rendered the same tags as nonsense, a hopeless jumble. FF4 also implemented SMIL animation of Inline SVG first.

http://www.caniuse.com/#feat=svg-html5
http://www.caniuse.com/#feat=svg-smil

I know this because I had to reimplement some Java AWT charts and graphs in Canvas and Inline SVG for Section 508 compliance (accessibility). I now allow the user to choose Java AWT, Canvas or Inline SVG, according to what their browser supports. It's surprisingly easy to implement all 3, at least for the simplistic text, lines and rectangles one typically uses for charts and graphs.

Sheeze

[Lisandro]

Am i the only one who cringes when someone mentions "web programming"?

Re:so what - it doesn't do innovation for you?

[dgatwood]

Why not? It makes porting to C (and other languages) a lot easier later when you realize you can't get the performance you want out of PHP. The most portable style of quoting is double quotes. That's the only style in which the rules for backslash escaping are fairly consistent across most programming languages. With single quotes, the rules are inconsistent. Heck, in some shell script dialects (not all, to make things even more fun), to echo a single quote inside a single quote container, you have to leave the single quote container entirely, e.g. 'It'"'"'s a beautiful day' or 'It'\''s a beautiful day'. Ugh. With double quotes, pretty much every programming language from shell scripts and C up through the latest Ruby goodness handles things the same way. This alone makes double quotes vastly preferable to single quotes when defining a string.

Also, I would argue that using quotation marks consistently (whether you're working in PHP or JavaScript or whatever) makes programming a lot easier. If you always use double quotes, you won't have to redo all the quotation marks (either replacing them, adding escaping backslashes, or some combination of the above) later when you need to add a variable into that statement. Also, if you consistently use double quotes, you won't have the risk of adding a variable, then swearing when you realize that you didn't notice the single quotes, your code just wrote gibberish into your test database, and you now have to rebuild a dozen records by hand. Or worse, your production database.

Finally, the snippet above has quotation marks within quotation marks. Using double quotes on the outside and single quotes on the inside is just as valid as the reverse, and is a lot cleaner than using \' or whatever. Reserve that for the annoying case where you need a string with both single and double quotes inside it (e.g. print "<a onclick=\"dosomething('blah')\">...".

Above all, though, the most important rule in coding is to use a consistent style throughout your code. Therefore, since some of your strings will almost certainly contain variables that you want expanded, you should consistently use double quotes (unless, of course, you consistently use string concatenation because you don't believe in interpolation at all).

In short, Mr. or Ms. Anonymous Coward, whoever taught you programming taught you wrong.

OS-level sandboxes

[tepples]

Why not just use the operating system's native sandbox capability by creating a separate user account in which to run each application that needs to be sandboxed? I seem to remember that's what IOS for Wii and iOS for iPhone do. (I'm not sure about Cisco though. :p )

Re:Perhaps a little better context for the feature

[colinrichardday]

I'm pretty sure that I could use inline SVG with Firefox 3. Also, O'Reilly's SVG Essentials (2002) mentions using inline SVG. And even if the images were imported rather than inline, the markup would be the same and would be readable by screen readers.

See also http://www.w3.org/TR/XHTMLplusMathMLplusSVG/

Re:Can I have an "Ahmen!" or at least a "well duh!

[Darinbob]

I have difficulty imagining any "rich, exciting, thrilling and awesome experiences" on the web. Maybe this is the whole problem with modern software devs, they're too focused on trying to achieve this instead of just making things work. If native apps do the job better than why bother with the web to do a half assed job instead?

Re:Perhaps a little better context for the feature

[WebManWalking]

I don't think so on the Firefox 3. I was a participant in the Firefox 4 beta and had to use the beta with about:config's html5 parameter set to true to get Inline SVG to work. You don't soon forget having to jump through those kinds of hoops to get something to work. But I still have Firefox 3 at home, so I can check it after work.

I suppose that theoretically, if the screen reader knew that an img tag was an SVG image by virtue of its mime type, it could parse the SVG. But with Inline SVG in the HTML it's guaranteed to work. Even if the SVG tags aren't recognized by the screen reader, and hence ignored, the text between the tags is plain-old text and will get read aloud. That's where the pertinent info was in the charts and graphs (labels, rankings, percentages, etc), between the tags.

Nice to talk to someone else who likes SVG, by the way.

Re:Perhaps a little better context for the feature

[colinrichardday]

I have an older hard drive from a computer whose motherboard crashed. I might stick it a computer to check the files on it using a pre-4 version of firefox. I'm pretty sure I was doing this before FF4, as I only got it when I upgraded from Ubuntu 9.10 to SuSE 11.4. What declarations were you using?

As for liking SVG, yes. I was used to such markup, having done stuff in pstricks in TeX/LaTeX.

Re:Perhaps a little better context for the feature

[WebManWalking]

I don't know what you mean by declarations. I used the Mac version at home and the Windows version at work. Is double-clicking a declaration? :-)

Too much CPU hungry. I miss Java

[Blaskowicz]

The main issue for me is of extreme slowness even on contempory computers. html5/javascript games, or apps for text reading with "turning pages" not only are slow, they peg 100% of a core only to recreate 1990s level of computing. This has problems including heat, fan noise and electricity bill. I have no flame intentions, just pointing out what seems obvious.

I've had a try at "Pirates love daisies" for instance, and it runs quite a bit slow on a 3GHz computer, re-creating the experience of an Amiga game but with higher res and lower quality sound. also selecting a character results in the display of a black square, as the blending is not supported. Running firefox 5. It should run like total crap on a 1GHz ARM, and of course single-thread performance has hit a ceiling.

I have a feeling the java plug-in worked better back in the days. It even ran on low end cell phones years ago and allowed actual games. There still are some java games around, such as Yahoo games. They load quickly and run butter smooth. So, maybe java isn't open enough but I wish we could have such a solution with near native performance, rather than stuff that feels like it's run on a emulator written in QBASIC.

Re:Perhaps a little better context for the feature

[colinrichardday]

By "declarations", I meant inclusion of DTDs and other such files.

Install to a user account

[tepples]

No libraries (no need for special permissions from IT in your company etc.)

So can Yast and synaptic.

I've never used YaST, so I'll ask about what I know: Since when can Synaptic install a package to a user account with the user's privileges instead of system-wide with root privileges? And since when can the developer of a native app deploy on iOS without the $300 per year overhead of buying a MacBook Air every five years and an iOS developer certificate every year?

Re:Install to a user account

[colinrichardday]

Don't know about synaptic. I don't write apps for iOS, so I don't care about that.

Re:Perhaps a little better context for the feature

[WebManWalking]

Oh, I totally forgot that you had to do that with SVG images. You don't have to declare an XML namespace or prefix tags with namespace prefixes in Inline SVG. None of that. Just the tags. Much easier.

Re:Perhaps a little better context for the feature

[WebManWalking]

...One more thing: In addition to screen readers for the blind, outliners can read the new tags and generate outlines of the content:

http://coding.smashingmagazine.com/2011/08/16/html5-and-the-document-outlining-algorithm/

This will allow generating Tables of Contents for documentation, addressing a major nuisance with using HTML instead of more full-featured word processing applications.