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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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?
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.
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'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?
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.
[+] [-] exogen|14 years ago|reply
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...
[+] [-] laughinghan|14 years ago|reply
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.
[+] [-] paulirish|14 years ago|reply
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
[+] [-] nephesh|14 years ago|reply
[+] [-] moe|14 years ago|reply
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.
[+] [-] dave1010uk|14 years ago|reply
[1] See http://wufoo.com/html5/ for "The current state of HTML5 forms"
[+] [-] romaniv|14 years ago|reply
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.
[+] [-] robin_reala|14 years ago|reply
[+] [-] IgorPartola|14 years ago|reply
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.
[+] [-] mgkimsal|14 years ago|reply
[+] [-] DanBC|14 years ago|reply
My 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.
[+] [-] michaeldwp|14 years ago|reply
[+] [-] ori_b|14 years ago|reply
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.
[+] [-] prodigal_erik|14 years ago|reply
[+] [-] JoshTriplett|14 years ago|reply
[+] [-] snorkel|14 years ago|reply
[+] [-] _urga|14 years ago|reply
Add a Javascript API to enable a web app to open a TCP socket (as opposed to WebSocket) with the origin server.
[+] [-] amalcon|14 years ago|reply
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.
[+] [-] franksalim|14 years ago|reply
[+] [-] daleharvey|14 years ago|reply
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.
[+] [-] gkanai|14 years ago|reply
[+] [-] mgkimsal|14 years ago|reply
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.
[+] [-] gkanai|14 years ago|reply
[+] [-] tszyn|14 years ago|reply
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).
[+] [-] politician|14 years ago|reply
[+] [-] melling|14 years ago|reply
Know someone with IE7 or IE8, get them off of it.
[+] [-] knieveltech|14 years ago|reply
[+] [-] mark242|14 years ago|reply
[+] [-] pjscott|14 years ago|reply
[+] [-] IvarTJ|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] romaniv|14 years ago|reply
[+] [-] amalcon|14 years ago|reply
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?
[+] [-] angry-hacker|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] snorkel|14 years ago|reply
[+] [-] JoshTriplett|14 years ago|reply
[+] [-] tef____|14 years ago|reply
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.
[+] [-] lmkg|14 years ago|reply