HTML 5 has date & time pickers, data lists (combo boxes), ranges (sliders). We just need better support [1]. Not sure what you mean by Multi-Buttons and DropDowns - HTML has had radio buttons and select boxes for a while now.
Gawd. The number of times I've had to implement Yes/No/Other + <input type="text" name="other-foo" />... Yes it can be built using basic elements, but there must be a better way!
Also, while HTML5 supports all the different types you described, very few browsers actually render them this way.
I would also add not just date selectors, but also date range selectors and time selectors as well. These are non-trivial and are so often broken.
This. It becomes harder and harder to develop interfaces using progressive enhancement, since the expectations from web interfaces are keep changing while the UI components available in native HTML are stuck in the early nineties. HTML 5 didn't fully address this issue.
I disagree about the slider. That is not a good solution; using it strains hand, and causes trouble especially for elderly people. Also it does not give a clue what is the range.
more easily understandable and manageable cookie management.
a little button with a picture of a cookie that popped open a window showing what cookies were being sent on a page, and what those values are, with options to kill them.
that alone would make it easier for people to understand what the hell data is being tracked about them, feel more in control, and (possibly) prevent stupid legislation from being pushed written by people who haven't the vaguest clue about what cookies are.
1. Full Device api / OS integration, basically phonegap supported natively in browsers, some support is slowly trickling though, I never understood why its taking such a long time though
2. Fix whatever performance problems make building RIA really damn hard. Some people say this problem is inherent to javascript + dom and cant be fixed, I am not sure, I do know browsers were making amazing steps over the last year or 2 and have mitigated it a lot, but its not quite there, in particular GC stalls are incredibly hard to work around.
FileSystemAPI support in Firefox, and the ability to tell the operating system to open a file stored with FileSystemAPI using the default registered native application (it must be possible to get notifications when this file changes, for syncing to the server). This would enable the DropBox use-case, where a user could drag an excel file into a web app, click a link in the web app to edit it with Microsoft Excel, and then press Save in Excel, and the web app would sync a diff with the server.
Add a Javascript API to enable a web app to open a TCP socket (as opposed to WebSocket) with the origin server.
What use cases for TCP do you envision where WebSocket won't be sufficient? It is quite possible to speak standard protocols over WebSocket that are typically spoken over TCP.
Last thing first: TCP requires a listening server. WebSocket requires a listening server. There is not inherently more infrastructure required.
The handshake and HTTP upgrade are there for a reason. Connecting out from web applications with straight TCP breaks the web security model. After the handshake, you can treat WebSocket binary frames as if they were a TCP byte stream. Speak any protocol you want to.
Anything you can do with TCP you can do with WebSocket. The only exception is that you cannot connect to a listening server that does not expect the WebSocket handshake. That is intentional! In fact, that is the reason for the WebSocket handshake.
the ability to tell the operating system to open a file stored with FileSystemAPI using the default registered native application (it must be possible to get notifications when this file changes, for syncing to the server).
This is a seriously scary concept. It has all the same dangers as the automatic-file-opening did in Outlook.
It can probably be done securely, but wow, that's not an easy problem.
For sure, it's difficult. As you say, it probably can be done securely. It certainly needs to be done to provide users with a bridge for moving data from file systems into web apps and back and manipulating data from both sides of the bridge. It may require a special privilege, and in that case, for example for a trusted web app, it need be no more scary than a browser prompt: "allow this web application to open 'mydata.xls' in Excel?" with a "remember my choice for all files of this type from now on".
Frictionless (micro)payments. Paying for access to premium content on the Web should be as easy as buying a song on iTunes. People will pay for stuff if it's super-easy.
It could save newspapers. It could change the Web from an advertiser-oriented medium (like TV) to a user-oriented medium (like iPod/iPad apps).
I've wanted to build a cross-browser BitCoin plugin for some time now, but the impossibility of it ever running on iOS keeps me from starting. Would such a plugin satisfy your needs?
If I had to pick one feature, it would be either proper client-side includes or partial caching. Probably the latter, because it's more aligned with the Web mindset.
I'm surprised only one person mentioned "inherit: none" for CSS (that's what they called it, anyway). If you've ever tried to develop a widget that anyone can stick on any old page, you know this: either you go with an IFRAME and your styles are fine but integration with page events and responding to content size changes are hard, or your styles are totally fucked.
There is absolutely no way to "silo" any area of a page from rogue CSS selectors besides using an IFRAME. Even the <style scoped> feature [1] which isn't even supported yet (AFAIK) doesn't really address the issue. The result is that you're constantly building a bigger and bigger localized CSS reset for your widget and trying to win the specificity arms-race against the host page.
Not to disagree, but this type of scenario has become much easier to deal with using iframe's and postMessage (https://developer.mozilla.org/en/DOM/window.postMessage). You can basically setup a client script that is embedded as the widget and some javascript inside your iframe to talk between each other. Just thought I'd throw out another option for those that are looking for one.
There is that, which is nice when you can get away with it. Unfortunately I still consider this the "hard" approach for a few reasons.
1. Supporting IE7, for which people tend to use an intermediate Flash object to do the communication.
2. There's still the content size problem. Does your IFRAME'd widget change size? Now you need to detect all size changes with JavaScript and send them back to the host page so it can resize the IFRAME.
3. Is your widget non-rectangular or concave? For instance, can it pop out a menu of a different size than the widget itself? Well, now you need an additional IFRAME for each piece that sticks out.
I believe this is an intentional design decision in CSS, and is related to all good user agents letting you run custom user scripts on page load to manipulate pages arbitrarily. What if I prefer reading white-on-black text, and have a custom stylesheet that does that? Your widget will be a glaring, angry block of black-on-white text in an ocean of calm black. In general, I would argue you should just try to play nice with whatever inheritable styles you're given to the extent you can. Sure, your widget will be unreadable if the page chooses black-on-black text, but so will the page, so that won't actually happen.
Basically, your widget should be like a weaker version of the shadow DOM of replaced elements (buttons, textboxes etc), you supply good default styles but they have to be overridable by the page.
> In general, I would argue you should just try to play nice with whatever inheritable styles you're given to the extent you can. Sure, your widget will be unreadable if the page chooses black-on-black text, but so will the page, so that won't actually happen.
I can tell that you've never had to deal with this problem before. :)
Ignoring useragent styles for a moment, it's not uncommon for pages to declare broad styles like:
And it's likely that these styles are perfectly readable on the page. Now the author adds your widget, and suddenly your widget is also subject to these styles. If your widget is complex – think "mini app", not "ad unit" – you now have to reset every single possible CSS property for the widget to be usable on every site, and in a way that gives it the highest specificity compared to other selectors used by other page styles.
I wasn't thinking inherit: none would disable a useragent's default styles. Just other styles directly on the page. But it's certainly not that simple to define those semantics.
You just apply that to each property you want to reset. You might think that applying it to EVERY property is a nightmare but in many cases you wouldnt need to. Disqus, for example, operates in your own CSS so it can look native to the page. They only have to override a few properties to assure their layout is good.
So yeah, while `inherit:none` would be awesome, I think `prop: initial` gets us most of the way there.
Hmm, you'd still have to ensure that your selector has higher specificity, right? That itself can be hard unless you're okay with adding !important to everything. I was thinking that inherit: none would somehow address this, but the rules would probably be pretty complicated.
I'd love to see page-internal isolation functionality: basically, a better Caja. Let me designate part of the page as untrusted by the rest of the page.
What if a web-specific StackOverflow-like site could (securely) display arbitrary examples? What if a social network status update could contain live code, but that code couldn't break out of the update?
Kill the browser. Seriously, the way it's heading, it's turning into a sandbox for applications. So, let's stop pretending and go all the way - get rid of the browser, keep the sandboxed execution.
It would be great if that could be done along with the removal of all the hacks that showed up while the browser was still a document viewer, but that's not likely.
Please no. The web has vastly more utility than version 2.0 of client/server hell, with its entombed content that's only accessible through exactly one brain-damaged app which you can't improve. If javascript devours the web, it will be the second greatest disaster of our industry (second only to walled gardens devouring open tools).
I'd like to see an "enhanced" SPDY added to every browser and web server implementation, one that allows for a package of assets to be concatenated, compressed, and sent in one chunk, rather than waiting for a browser to interpret HTML before starting to request more assets.
SPDY already supports server push, where a server can tell the client, "I'm sending over some files (e.g. JavaScript and CSS and a bunch of little images) that you're going to want soon. You're welcome." It sounds like exactly what you want.
X-Associated-Content still requires each file to be broken out as its own, doesn't it? I'm thinking more of a single file with a manifest, highly compressed, that only requires one fopen() to push all of the data to the client. Sort of a browser cache warming file. "You need this Javascript, this CSS, and these images for any page on the site. Take this file and you're all set."
Since SPDY multiplexes multiple streams to the same socket, and commonly-used static content will be cached in the server's memory anyway, I don't see much practical difference between what SPDY's X-Associated-Content and what you're proposing.
Seconded. This could kill off the insanity of "Sign in with $OTHER_SERVICE", as well as eliminating the whole concept of generating and remembering passwords.
54 comments
[ 4.3 ms ] story [ 134 ms ] threadMy list would be something like:
1) Standards compliance. Validated HTML and CSS.
2) Don't force your design on my browser. Let me set fonts; colours; sizes; margins; etc.
3) Please god let flash die.
4) Allow me to pay a subscription to opt out of ads.
5) Simplify design. I'm usually interested in the content. Design often gets in the way of the content.
There's probably a million more.
HTML badly needs native DatePickers, ComboBoxes, Sliders, Tabs, Multi-Buttons, DropDowns etc.
In 2011 we shouldn't have to deal with less-than-half-baked javascript monstrosities to display a basic input widget.
[1] See http://wufoo.com/html5/ for "The current state of HTML5 forms"
Also, while HTML5 supports all the different types you described, very few browsers actually render them this way.
I would also add not just date selectors, but also date range selectors and time selectors as well. These are non-trivial and are so often broken.
For example, this is how sliders really should look like: http://worrydream.com/Tangle/
We need trees. We need pure-HTML drag-and-drop support. We need simple components that can be combined to create complex, usable interfaces.
Know someone with IE7 or IE8, get them off of it.
http://www.mementoweb.org/
it adds date negotiation in the vein of content negotiation to http. it is like browser support for the wayback machine.
a little button with a picture of a cookie that popped open a window showing what cookies were being sent on a page, and what those values are, with options to kill them.
that alone would make it easier for people to understand what the hell data is being tracked about them, feel more in control, and (possibly) prevent stupid legislation from being pushed written by people who haven't the vaguest clue about what cookies are.
1. Full Device api / OS integration, basically phonegap supported natively in browsers, some support is slowly trickling though, I never understood why its taking such a long time though
2. Fix whatever performance problems make building RIA really damn hard. Some people say this problem is inherent to javascript + dom and cant be fixed, I am not sure, I do know browsers were making amazing steps over the last year or 2 and have mitigated it a lot, but its not quite there, in particular GC stalls are incredibly hard to work around.
Add a Javascript API to enable a web app to open a TCP socket (as opposed to WebSocket) with the origin server.
The handshake and HTTP upgrade are there for a reason. Connecting out from web applications with straight TCP breaks the web security model. After the handshake, you can treat WebSocket binary frames as if they were a TCP byte stream. Speak any protocol you want to.
Anything you can do with TCP you can do with WebSocket. The only exception is that you cannot connect to a listening server that does not expect the WebSocket handshake. That is intentional! In fact, that is the reason for the WebSocket handshake.
This is a seriously scary concept. It has all the same dangers as the automatic-file-opening did in Outlook.
It can probably be done securely, but wow, that's not an easy problem.
It could save newspapers. It could change the Web from an advertiser-oriented medium (like TV) to a user-oriented medium (like iPod/iPad apps).
There is absolutely no way to "silo" any area of a page from rogue CSS selectors besides using an IFRAME. Even the <style scoped> feature [1] which isn't even supported yet (AFAIK) doesn't really address the issue. The result is that you're constantly building a bigger and bigger localized CSS reset for your widget and trying to win the specificity arms-race against the host page.
I would love that feature.
[1] http://dev.w3.org/html5/spec-author-view/the-style-element.h...
1. Supporting IE7, for which people tend to use an intermediate Flash object to do the communication.
2. There's still the content size problem. Does your IFRAME'd widget change size? Now you need to detect all size changes with JavaScript and send them back to the host page so it can resize the IFRAME.
3. Is your widget non-rectangular or concave? For instance, can it pop out a menu of a different size than the widget itself? Well, now you need an additional IFRAME for each piece that sticks out.
Basically, your widget should be like a weaker version of the shadow DOM of replaced elements (buttons, textboxes etc), you supply good default styles but they have to be overridable by the page.
I can tell that you've never had to deal with this problem before. :)
Ignoring useragent styles for a moment, it's not uncommon for pages to declare broad styles like:
And it's likely that these styles are perfectly readable on the page. Now the author adds your widget, and suddenly your widget is also subject to these styles. If your widget is complex – think "mini app", not "ad unit" – you now have to reset every single possible CSS property for the widget to be usable on every site, and in a way that gives it the highest specificity compared to other selectors used by other page styles.I wasn't thinking inherit: none would disable a useragent's default styles. Just other styles directly on the page. But it's certainly not that simple to define those semantics.
You just apply that to each property you want to reset. You might think that applying it to EVERY property is a nightmare but in many cases you wouldnt need to. Disqus, for example, operates in your own CSS so it can look native to the page. They only have to override a few properties to assure their layout is good.
So yeah, while `inherit:none` would be awesome, I think `prop: initial` gets us most of the way there.
Also related: https://github.com/premasagar/cleanslate
What if a web-specific StackOverflow-like site could (securely) display arbitrary examples? What if a social network status update could contain live code, but that code couldn't break out of the update?
And don't make me download/install an addon, because odds are you just caused my support expense to blow up by 10x.
It would be great if that could be done along with the removal of all the hacks that showed up while the browser was still a document viewer, but that's not likely.
I'd like to see the two problems (application platform, interlinked document platform) split cleanly.
(Something like Microsoft's HTML Components (HTC) - http://msdn.microsoft.com/en-us/library/ms531018(v=vs.85).as... )