What feature would improve the web?(paulirish.com)
paulirish.com
What feature would improve the web?
http://paulirish.com/2011/what-feature-would-improve-the-web/
22 comments
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.
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:
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.
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; }
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
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.
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 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"
[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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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. 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.
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).
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.
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.
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.
The web is a great application platform – it lacks a good hypertext system, though.
[deleted]
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?
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.
[deleted]
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.
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... )
(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.
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.
[deleted]
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...