HTML 5 is like wrapping aluminum foil around a pig. It's shiny but in the end it's still wrinkled up aluminum foil wrapped around a fat pig. In the end developers will still rely on this pig to feed themselves.
The DOM is a mess, HTML has become a mess, CSS is a mess, ECMAScript is a mess everything about developing applications in the browser is a complete mess. But in the end this is what we have as a foundation to build our applications off of. However bad the foundation might be the end user doesn't care; they just want desktop quality applications that run in the browser.
Application frameworks like Cappuccino and SproutCore are being set in place now to make ridiculously simple task which have been made ridiculously complicated by web technologies simple again.
The idea behind HTML5 is to make the browser more capable of actually running applications. We keep building off unstable foundations and now we're running into the problems mentioned here.
The HTML5 standard is bringing a great deal of new technologies to the browser, but eventually these problems are going to have to be addressed. Eventually we're going to have to cook this pig wrapped in foil so that the only thing left are the good parts... so that it comes out as barbecue. If not we're always going to be building more frameworks on top of awful foundations to abstract ourselves.
lmorchard
· 4 months ago
In case you haven't noticed it: The whole internet, from top to bottom, is a series of nested foil-wrapped pigs. Many people have expressed a desire to cook the thing, in whole or in part, but no one's managed to lever the thing into a big enough oven yet.
Grumble if you like, but what you're observing is the best process possible for the web—because it's the only one that's managed to cause progress of any kind. If you think you can do a better job of herding cats and applying dynamite to foundations, more power to you.
Randy Luecke
· 4 months ago
Except our progress is uselessly delayed. While we're all slaving over supporting IE we slowly build technologies that already exist again, so that they will be abstracted from browser bugs. Drag and drop for example will continue to be use javascript in jQuery, Cappuccino, SproutCore, etc probably until the end of time for abstraction sake while native html apis go unused. Simply because we have to engineer things that are already there we are slowing progress. There has never been another process for progress on the web.
Now, whether I like it or not the browser is the future of applications I just wish the foundation was a bit more stable.
Tinus
· 3 months ago
That evolution is slow is conventional wisdom. I think Steven Den Beste said it best:
In the long run, Darwinian evolution sounds like a good idea. But like adventure, it’s better read about than experienced, because the only way it can really happen rapidly is with a high death rate.
It's quite useless on Webkit if you're implementing a generic dragstart handler and need to use dataTransfer.getData to find out what data is being dragged to begin with. The bug is is explained in WebKit Bug 23695 (https://bugs.webkit.org/show_bug.cgi?id=23695).
alos
· 4 months ago
Interesting post! The D&D between browser windows is awesome!
Laurent
· 3 months ago
No, the D&D between browser windows is useless
alos
· 3 months ago
That is very shortsighted of you. Can you imagine dragging code from your Bespine to an article being written on another window in Google Docs? Moving your slides from 280Sildes to a presentation being done in another webapp? Moving calendar or contact info between apps? D&D Is a very interesting, I'm sure dragging between browser windows is just the start.
jax
· 4 months ago
For me the exiting thing about native drag and drop, unlike the JS library emulation, is that you get drag and drop that really works with your environment. You can use your keyboard for drag and drop, or have drag and drop on your phone (most phones don't come with an attached mouse), you can have voice-controlled drag and drop, or in systems like Nintendo Wii you could have a quite literal drag and drop support.
gazhay
· 3 months ago
HTML5 is never going to be the answer for a couple of good reasons.
The browser manufacturers only implement it while it is good for them - as soon as HTML5 (WHATWG or WWW) mandate something they don't want to do - it breaks.
HTML is a mark-up language that has been bullied and abused into a "solution" to deliver web applications to users. That shouldn't need explaining, it's like using a bar of chocolate as a screwdriver.
HTML5 doesn't attempt to clean up "tag-soup" or completely badly written HTML, we still have engines 'guessing' at what authors meant.
And finally, a number of people "behind" the standards are academic snobs, who look down on anyone else. (Hixie is *not* one of them)
Name
· 3 months ago
At least some people try. Complaining that it will never work is exactly what I would expect from a "academic snob". At least these guys dare to innovate!
J. King
· 3 months ago
Gee, why don't you trot out more baseless, unsubstantiated accusations while you're at it?
That reality (browser vendors are the ones who make browsers---amazing!) complicates getting the perfect outcome shouldn't surprise you, and it shouldn't discourage you, either. The endless march forward of technology is littered with imperfect solutions to complicated problems, with hacks layered upon each other neck-deep which enough effort and code have actually turned into something useful. It's nothing new, and it's not bad. If you think you can come up with another solution which actually has a chance in hell of getting adopted by thousands of corporations and millions of individuals in hundreds of countries on a sane timeframe, you're probably wrong, anyway.
For the record HTML5 -does- attempt to 'clean up "tag-soup"': read Section 9. A staggering amount of time has gone into making sure that future agents get a consistent, interoperable parse tree in standard mode while also mirroring existing behaviour as much as possible; ignoring all this hard work is folly.
gazhay
· 3 months ago
You both think I haven't been involved - I have. I was on the WHATWG and W3C mailing lists, and insulted off list by numerous of the "academic" snobs. The procedure is flawed, as is the use of HTML5 for web applications. Neither of you argued away that point, instead you said - it's the best we can do. Settling for second best is bull.
Mr. King, you also come from a silly point of view, Adobe Air, Silverlight and Flash all attempt to do what you suggest, so saying "getting adopted by thousands of corporations and millions of individuals in hundreds of countries on a sane timeframe, you're probably wrong, anyway." is just plain pathetic. Take your delusions elsewhere.
Jens Alfke
· 3 months ago
Part of the problem, apparently, is that HTML drag-n-drop is *not* a new API. It's been in MSIE for about ten years, and is being standardized after the fact. What's in the spec can't really be changed in incompatible ways because there are a lot of websites that support the MSIE API.
(Note: I have no direct knowledge of DnD in MSIE, but this was the answer given by Hixie to some recent comments on the API's deficiencies on the WHATWG list.)
I'm actually doing a bit of work on DnD support in Chrome and WebKit. I have a WebKit patch out that fixes a bunch of nits with the values of dropEffect and effectAllowed, which will hopefully get reviewed and checked in soon.
Ben Vanik
· 3 months ago
Great post! One comment on the delayed drag change idea -- I love it, but one thing it lacks is the ability for the drag target to filter the results. You would need a way to tell the drag event what types are being dragged. Cocoa does this with -[NSPasteboard addTypes:owner:] paired with [NSView registerForDraggedTypes:]. Just something to remember if you are begging people for API changes ;)
Ryan
· 3 months ago
Great post, good insightful look at the DnD API.
Like Jens Alfke said this API has been reversed engineered from Microsofts own proprientry API and is not new. There are however further proposed extensions to the current API such as the files attribute on the dataTransfer method that I wrote about http://www.thecssninja.com/javascript/drag-and-... this allows us to go in the other direction by dragging from our desktop into the browser.
All Comments
The DOM is a mess, HTML has become a mess, CSS is a mess, ECMAScript is a mess everything about developing applications in the browser is a complete mess. But in the end this is what we have as a foundation to build our applications off of. However bad the foundation might be the end user doesn't care; they just want desktop quality applications that run in the browser.
Application frameworks like Cappuccino and SproutCore are being set in place now to make ridiculously simple task which have been made ridiculously complicated by web technologies simple again.
The idea behind HTML5 is to make the browser more capable of actually running applications. We keep building off unstable foundations and now we're running into the problems mentioned here.
The HTML5 standard is bringing a great deal of new technologies to the browser, but eventually these problems are going to have to be addressed. Eventually we're going to have to cook this pig wrapped in foil so that the only thing left are the good parts... so that it comes out as barbecue. If not we're always going to be building more frameworks on top of awful foundations to abstract ourselves.
Grumble if you like, but what you're observing is the best process possible for the web—because it's the only one that's managed to cause progress of any kind. If you think you can do a better job of herding cats and applying dynamite to foundations, more power to you.
Now, whether I like it or not the browser is the future of applications I just wish the foundation was a bit more stable.
In the long run, Darwinian evolution sounds like a good idea. But like adventure, it’s better read about than experienced, because the only way it can really happen rapidly is with a high death rate.
The browser manufacturers only implement it while it is good for them - as soon as HTML5 (WHATWG or WWW) mandate something they don't want to do - it breaks.
HTML is a mark-up language that has been bullied and abused into a "solution" to deliver web applications to users. That shouldn't need explaining, it's like using a bar of chocolate as a screwdriver.
HTML5 doesn't attempt to clean up "tag-soup" or completely badly written HTML, we still have engines 'guessing' at what authors meant.
And finally, a number of people "behind" the standards are academic snobs, who look down on anyone else. (Hixie is *not* one of them)
That reality (browser vendors are the ones who make browsers---amazing!) complicates getting the perfect outcome shouldn't surprise you, and it shouldn't discourage you, either. The endless march forward of technology is littered with imperfect solutions to complicated problems, with hacks layered upon each other neck-deep which enough effort and code have actually turned into something useful. It's nothing new, and it's not bad. If you think you can come up with another solution which actually has a chance in hell of getting adopted by thousands of corporations and millions of individuals in hundreds of countries on a sane timeframe, you're probably wrong, anyway.
For the record HTML5 -does- attempt to 'clean up "tag-soup"': read Section 9. A staggering amount of time has gone into making sure that future agents get a consistent, interoperable parse tree in standard mode while also mirroring existing behaviour as much as possible; ignoring all this hard work is folly.
I was on the WHATWG and W3C mailing lists, and insulted off list by numerous of the "academic" snobs. The procedure is flawed, as is the use of HTML5 for web applications. Neither of you argued away that point, instead you said - it's the best we can do. Settling for second best is bull.
Mr. King, you also come from a silly point of view, Adobe Air, Silverlight and Flash all attempt to do what you suggest, so saying "getting adopted by thousands of corporations and millions of individuals in hundreds of countries on a sane timeframe, you're probably wrong, anyway." is just plain pathetic. Take your delusions elsewhere.
(Note: I have no direct knowledge of DnD in MSIE, but this was the answer given by Hixie to some recent comments on the API's deficiencies on the WHATWG list.)
I'm actually doing a bit of work on DnD support in Chrome and WebKit. I have a WebKit patch out that fixes a bunch of nits with the values of dropEffect and effectAllowed, which will hopefully get reviewed and checked in soon.
Like Jens Alfke said this API has been reversed engineered from Microsofts own proprientry API and is not new. There are however further proposed extensions to the current API such as the files attribute on the dataTransfer method that I wrote about http://www.thecssninja.com/javascript/drag-and-... this allows us to go in the other direction by dragging from our desktop into the browser.