back
51 comments
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 would love that feature.

[1] http://dev.w3.org/html5/spec-author-view/the-style-element.h...

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:

    p { text-shadow: 0 1px 0 #000; }
    h1, h2, h3 { text-transform: uppercase; }
    a { color: red; }
    input { margin-bottom: 2em; }
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.

so the `initial` value can functionally replicate this. https://developer.mozilla.org/en/CSS/initial

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

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.
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.

The single biggest thing that I could think of: Forms!

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.

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.

[1] See http://wufoo.com/html5/ for "The current state of HTML5 forms"

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.

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.

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.
HTML5 has most of those things, and implementors are catching up.
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.

JUST DON'T TAKE AWAY MY RESET BUTTON! ;)
Nothing on their short list is of any interest to me.

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.

http://www.readability.com may help with #5. They have a handy bookmarklet too.
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).
Too late. It's already trying to solve two problems, and doing it poorly.

I'd like to see the two problems (application platform, interlinked document platform) split cleanly.

No way. The browser still puts the user in control, not the site; let's not replace it with any sandbox that lacks that design constraint.
Then how would you browse?
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.

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".
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.
TCP does not need the upgrade event, handshake etc. TCP is not limited by the WebSocket spec. TCP requires no additional server-side infrastructure.
I have 2 requests but they are pretty big ones

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.

1. Mozilla is working on this (Boot2Gecko); details here http://www.aminutewithbrendan.com/pages/20111019 and here https://wiki.mozilla.org/B2G
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.

re: cookie management, have you tried Ghostery?
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 don't think we need a feature more than for everyone to have a modern browser IE9, Chrome, Firefox 7+, or Opera.

Know someone with IE7 or IE8, get them off of it.

True anonymity.
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.
The web is a great application platform – it lacks a good hypertext system, though.
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?

WYSIWYG form element is an excellent idea. Never though about it before... not sure how it would be possible to implement though.
Broader support for BrowserID.
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.
i'd like to see more support for memento

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.

Non-single-threaded concurrency model for JavaScript.
A standard way to take some HTML/CSS and Javascript and bundle it as a component for use in other web apps.

(Something like Microsoft's HTML Components (HTC) - http://msdn.microsoft.com/en-us/library/ms531018(v=vs.85).as... )

Simple, honest-to-god, true drag-and-drop of files. To/from the desktop.

And don't make me download/install an addon, because odds are you just caused my support expense to blow up by 10x.

Already exists, no add-on required. You can access the file contents from JavaScript, or upload it to the server and process it there.