Hawaiʻi's Technology Community
HTML5 Widgets: FAIL
I realize its sacrilegious to say anything bad about HTML5, but I have to say I am really disappointed in its handling of widgets (i.e. combo boxes, lists, sliders, etc.) HTML5 introduces new form input types such as range, date pickers, color selector, etc. but they are completely opaque and have very narrow APIs. This is due to HTML5's approach of punting to the browser to render and manage the widget. Often the browser in turn punts to the OS. This was the approach Java AWT took when it was introduced in 1995 and we all remember how well that went :-/ There is a reason it was nicknamed the Awful Windowing Toolkit!
In HTML5 there is, for example, no way to extend a range to provide two nobs for a price range. You also cannot style it with CSS aside from doing things like putting a border around the outside. If you want to create a custom widget you are left to start from scratch and do all your own painting and event handling with a canvas component or SVG elements. This is a non-trivial endeavor for all but the simplest components. Every other modern RIA platform (Flex, Silverlight, JavaFX, etc.) provides a nice OO library of extendable and skinnable components. What not HTML5?
Of course there are third party libraries that have nice components such as JQuery UI, but the whole point of HTML5 is to create a solid foundation for RIAs that allows you to create great user experiences without having to use a bunch of third party libraries that bloat page loads. This is particularly important on mobile devices that don't benefit from high speed connections. It wouldn't be that hard for HTML to define some basic, skinnable, extensible widgets that can be styled with CSS and extended with Javascript in a standard way. This would facilitate lightweight RIAs that perform well everywhere from the desktop to the phone.
There are a lot of things I like about HTML5 - CSS3, semantic tags, local storage, etc., but the lack of a standard widget library that can be extended via Javascript and CSS is a major failing. The other is the lack of a standard intermediate language, which I ranted about in a previous post.
Views: 1687
Comment
-
Comment by Chris Runnells on March 8, 2011 at 8:48pm
-
I know this is just reiterating at this point, but it would be really nice to have consistent form controls across all platforms/browsers/operating systems. Not only would it improve user experience because the form controls would be consistent between devices (excluding bad design implementations), but it would make our job as web designers easier because we wouldn't have to do as much browser testing on our forms.
-
Comment by Daniel Leuck on March 8, 2011 at 11:05am
-
@Chris Good point. I intend to.
@David Exactly. For mobile this is particularly important. The solution to the look and feel problem is for the standard to include a default, neutral (grays) CSS for the widgets, allow the browsers to provide their own default and allow web designers to override both of them. That is the beauty of CSS :-)
-
Comment by J. David Beutel on March 8, 2011 at 10:46am
-
Dan, it would be nice if hosted widgets were available on all platforms, especially mobile (iOS, Android, etc), to avoid the overhead of downloading your own. I suppose the reason we don't have that now is not so much the lack of a standard for it, but the unwillingness of the platform owners to provide it, because they want to preserve a look-and-feel advantage for native apps, to promote their own platform (e.g., iOS not supporting Flash).
-
-
I agree, and maybe the thing to do about it is to suggest it to the W3C? I'm sure they have their hands full with working on the HTML5 spec, but something like this does sound important. Relying on browser and OS vendors to design the form controls leaves web designers and developers out in the cold.
Granted, like Mark said, there are JS libraries out there to help normalize some form controls (the name of which escapes me right now), but this isn't something we *need* Javascript for!
-
-
@Brian Sad but true.
-
Comment by Brian on February 14, 2011 at 5:34pm
-
Certainly the tragedy/reality is that HTML5 will not be the panacea for a plethora of development spanning the desktop through mobile.
I.e. we'll all still have our flash/SL apps for data-heavy dashboards and be doing HTML5 for lightweight mobile versions.
-
-
Mark Quezada: With all that said, I think it would be great if we had high-performance, low-overhead skinnable widgets baked right in. But really, who would get to define them and their interfaces? Apple? Microsoft? Google?
The W3C. It would be part of the standard. Everyone else can add their own skins, extensions, higher level widgets, etc.
Mark Quezada: This is why I believe the standard HTML5 widgets are so minimal. It's easier to agree on the basics. By offloading the creation of more complex widgets to a layer above "native" you allow everyone to create anything they want as long as they can use HTML, CSS and javascript to get there.
Keeping it simple makes sense. They shouldn't be creating pivot tree tables that can wash your car. I'm not asking for that. What I am asking for is what they have already specified for the new input types as proper widgets that can easily be modified and extended via Javascript and CSS. Using well understood concepts like pluggable cell renderers and editors they could make things like combo boxes, lists and grids much, much more powerful and clients much, much lighter. I'm taking issue with the architectural decision to use peers, not the complexity level they've chosen to tackle. We know it can be done because Flex, Silverlight, WPF and Swing all have skinnable, highly flexible widget sets that do not use native peers.
-
-
Mark Quezada: I understand your sentiment, but, in one sentence, you're using the term "HTML5" to mean (and/or include) "CSS3, semantic tags, and local storage" (which, funnily enough, can only be used through a javascript api), but in a different sentence you lament that you must resort to using those same technologies to render your own, custom widgets and you would rather use just "HTML5" directly?
What I am saying is fairly concise: I'm saying the W3C's HTML5 spec should include a set of common widgets with robust APIs that can be modified via Javascript and styled with CSS.
Mark Quezada: If the heart of HTML5 is in fact the full stack of those technologies then one could argue that there is an endless supply of widgets and themes available to do anything and everything, and you can extend and create your own quite easily.
That is true, and I acknowledged this in my post. My point is that you shouldn't have to download external Javascript to get basic customizable widgets. When you do you take a hit and on a phone its quite noticeable. I know because we've done it both ways.
Mark Quezada: I think relating the situation to Java AWT is a bit misguided.
Its actually a very direct relationship. When you build a cross platform widget library there are two primary approaches. One is to use native peers. A peer is a native widget for which a parallel object exists in the hosted platform. The other is to implement the widget in the hosted platform so all the behavior and view aspects can be overridden if the client programmer so chooses. When you use a slider or date selector input type in HTML you are getting a peer - a browser rendered or OS rendered widget. That is why you don't have full control over it. That is exactly how AWT handled widgets. AWT had additional problems such as very primitive layout managers, but I am specifically referring to the peer approach versus rendering in the hosted platform. Swing came about because the peer approach failed. Subsequent RIA technologies - Flex, WPF, Silverlight, etc. all included their own fully customizable widgets rather than using peers.
-
Comment by Mark Quezada on February 11, 2011 at 5:34pm
-
Bummer, it cut off the end of my response. Anyway, just saying that all of those vendors would have to work together to make sure everything works the same on every platform. This is why I believe the standard HTML5 widgets are so minimal. It's easier to agree on the basics. By offloading the creation of more complex widgets to a layer above "native" you allow everyone to create anything they want as long as they can use HTML, CSS and javascript to get there.
Just my two cents.
-
-
I understand your sentiment, but, in one sentence, you're using the term "HTML5" to mean (and/or include) "CSS3, semantic tags, and local storage" (which, funnily enough, can only be used through a javascript api), but in a different sentence you lament that you must resort to using those same technologies to render your own, custom widgets and you would rather use just "HTML5" directly?
If the heart of HTML5 is in fact the full stack of those technologies then one could argue that there is an endless supply of widgets and themes available to do anything and everything, and you can extend and create your own quite easily. (Of course, I'm being a bit obtuse, but I'm trying to make a point.)
I think relating the situation to Java AWT is a bit misguided. AWT failed because the applications it rendered were this weird hybrid of native UI elements with non-standard layout, interface, and interaction issues. Running on a PC? Sure, the checkboxes would render like native checkboxes, but it didn't feel right. Running on a Mac? Yup, you'd get a toolbar at the top of the application, but the interface just didn't feel Mac-like. It was like the uncanny valley for UI.
The web (or maybe more correctly, "web applications") have never had a "standard" interface like you'd expect from a single operating system. Users have grown accustomed to each company's own style of web applications and now this "standard" is defined individually for each web application creator. Most of Google's interfaces and widgets look and act the same, and yet they are very different than Facebook or Twitter's stuff.WIth all that said, I think it would be great if we had high-performance, low-overhead skinnable widgets baked right in. But really, who would get to define them and their interfaces? Apple? Microsoft? Google? Would they work together to make sure they look and act the same on every platform? At some point all of thos
© 2024 Created by Daniel Leuck.
Powered by
You need to be a member of TechHui to add comments!
Join TechHui