HTML UI
By glazou on Monday 19 September 2011, 10:16 - Standards - Permalink
I had an interesting online chat with a friend in the US this morning (well, this night for him...). The topic was HTML and the recent Microsoft announcements. While we see HTML reach a next level with desktop apps, the lingua franca of the web is still far, really far away from having all what's needed for desktop apps or even web-based desktop-alike apps. If form controls improved a lot between html4 and html5, a wide range of UI elements are still out of reach. Well. Let me explain before shouting : they are codable but each and every site has to reinvent the wheel with lots of UI theming and JavaScript-based controls. That's bad because that's incoherent and expensive. HTML+CSS still lacks major, really major stuff like:
- real menus
- tabboxes
- pop-ins and more powerful tooltips
- trees (and when I mean trees, I mean tree-like widgets like the XUL <tree> able to render tens of thousands of lines w/o making the user experience awful)
- better integration with the OS/WindowManager
- etc.
While we're (the Standards Community) now focusing on super-mega-hyper-useful stuff like an API to get the battery status (sic...), we're still unable to include in a web- or desktop app such widgets with a native look&feel. There are zillions of frameworks to ease the pain, but none of them is ready for desktop apps, and HTML+CSS+JS desktop apps need them to become mainstream AND cross-platform.
I think then a new standardization effort between HTML and CSS is needed to make HTML UI appear. Let's look back at XUL and XAML a bit... Thoughts?
Comments
l can't agree more. At least a better templating and reusable controls are needed.
Amen. On the CSS side, we’re still lacking decent means to style HTML4 form elements. If new UI elements described in an hypothetical “HTML UI” spec would be styled with CSS, surely that’s an opportunity to look back at styling the existing elements as well?
On the accessibility side, I guess this would call for a ARIA update (ARIA 1.1 or 2.0).
There is currently an effort to design <menu> and <command> elements for HTML5 (though there aren't any implementations yet) and, as I understand it, <menu type="toolbar"> would make a menu bar... but aside from that, I agree whole-heartedly.
In fact, in one of my current projects, one of the more time-consuming elements of porting over to a new platform has been fixing up a partial tab box implementation that needs to degrade gracefully.
fvsch also makes an excellent point about styling existing elements. It took a surprising bit of browser-specific hackery to make sure that checkboxes would print properly on Firefox and Chrome when I was designing an @print stylesheet for my TiddlyWiki. (And I still had to nudge the font size to fit the checkboxes on Firefox, since you can't resize even the non-native Firefox checkboxes via CSS)
Do we really need native-like L&F? See http://goo.gl/g8qWL
I agree wholeheartedly. I'm trying to port a large suite of Remote XUL apps to HTML and it's really quite painful:
* Lack of powerful/native widgets, as you described
* No good, standardised, componentization model. XBL2 should provide this, but nobody seems to want to implement it natively
* No good i18n/l10n story
At least the flexible box model is gaining some traction, but I hate to think how many developer hours are being spent worldwide reimplementing tabbed forms, trees and all the other things that XUL has, when really these should be getting specced/implemented at the W3C and vendor level.
I suppose this is why they have the WinJS library in the Metro apps: because there are still too many limitations. While I think WinJS does break those limitations, it's still a very hacky solution. Luckily, HTML is a living spec, now, so we don't need to wait until HTML6 before we can have new elements for trees and pop-ups. However, we need them sooner, rather than later.
Would you have the idea to dance salsa on polka music ? I think no. So why do you want to create applications with a language designed for document ?
I have a mixed feeling about that.
We « already have » what you are saying not in the browser but outside of the browser, aka the chrome. The issue being that the chrome is very very controlled environment (closed) and widely different from OS to OS (not sure it is good or bad). So because the HTML/CSS is not controlled by the Operating Systems, we had layers and layers of abstraction: networks, apis, markup, layout, etc. UI language could be one of them. It might be easier to do it here, not sure it is the place I would like to see it. Somehow, I wonder is it do we need an HTML UI language or do we need to make the browser chrome more flexible?
Really no 100% opinion on one side or the other.
Do we really need native look'n'feel? Why do we still talk about desktop? Everything should be in browser, it allows fast UI innovation and not locked by your local system. I'd really like XUL tree especially the performance it brings to us, but it's not so important for real web.
@Bob: never heard of W3C Widgets ? Dashboard ? Opera Widgets ? Windows8 desktop apps ? WebOS ?
While I agree on the reusable code part, the native OS/WindowManager is irrelevant when everything is done via web-based tools and applications. Standards for these UI elements would be nice (notice how Google has been standardizing the UI on their apps).
I’ve been visiting your blog for a while now and I always find a gem in your new posts. Thanks for sharing.
Killing remote XUL without a replacement was one of the biggest mistakes Mozilla did within the last year.
Killing XUL in a time when web apps become more and more important was a big mistake.
Yes, I know: Where's the standard? But having something (XUL) is better than nothing.
All those UI elements are about presentation, so they shouldn't be part of HTML. Or do you disagree?
maybe HTML really dodged a bullet by avoiding desktop controls all these years. web UI transitioned very well to touch input, except for those parts that were trying to mimic desktop UI (like hover menus or flash games).
also, these are the only standard desktop controls that are missing from (most) touch platforms (the good ones):
menus, trees, tabboxes..
and microsoft is even removing menus on the desktop part of windows8 (with the ribbon UI).
what do those controls have in common? they are all powerful but too fiddly (mouse only) and too complex for non-programmers.
maybe there is a lesson there..
The Component Model stuff Dimitri Glazkov et al. are working on seems relevant...
I have been telling that for a while and fully agree.
IMHO, to make web apps have a really good UI/UX story, we need 1) a binding language, 2) an overlay model, and 3) a number of widgets (as you mentioned, a tree/list, panels, and others) in HTML - and that's going beyond what's "HTML5" right now.
Last week, I heard people from related Mozilla teams agree with me, but we need to continue to push together to get those things done. Mozilla, with the experience we gathered from XUL, is in the best possible position to work on that as we already know a few things about how to deal with those things in practice, including pitfalls and "don'ts".
Unfortunately we're at a crossroads right now, and it's not obvious what direction to take next. Behind us is a road with Remote XUL, XBL, Overlays and so on, which provides a good basis for producing desktop-like applications which are served as though they're web pages. But that's been deprecated and there's no telling how long it will remain viable for. Even if Mozilla don't kill it outright, will they really be interested in fixing regressions in future?
In front of us we have too many paths, and none of them ready to take yet. XBL2 has at least got a W3C spec, but nobody seems interested in implementing it. What I've seen of Glazkov's component model shows it to be a work in progress (which will probably end up just as involved as XBL1/2) - and it's not ready for real-world use yet.
We've moved from a non-standard option which worked very well in one browser, to a collection of half-baked ideas that aren't ready to use - but at least they're not ready to use across <em>all</em> browsers
Take the wrong road and I'm faced with the prospect of having to migrate again in the near future. Do nothing and I'm faced with the possibility that any given 6-week release cycle could introduce a regression that breaks our Remote XUL code.
More than a component model, widgets, overlays and so on, I'd like to see a public commitment from the vendors. Form a working group and commit to implementing its specs. At least that would give us a clear direction to proceed in.
I would add Localizable File Upload control to the list. The non-localizability of existing one forces people to use some workarounds like embedding Flash controls.
But the problem is such Flash controls not necessary respect CSS, so...
I believe translatable, style-able File Upload control is what we need.
FYI Daniel - there was a related effort in the W3C a few years ago and it ended with this publication <http://www.w3.org/TR/2007/NOTE-dfau...