What feature would improve the web?

http://paulirish.com/2011/what-feature-would-improve-the-web/

by ChrisArchitect • 15 years ago

43 51 15 years ago

paulirish.com

DanBC• 15 years ago

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.

michaeldwp• 15 years ago

http://www.readability.com may help with #5. They have a handy bookmarklet too.

moe• 15 years ago

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.

robin_reala• 15 years ago

HTML5 has most of those things, and implementors are catching up.

dave1010uk• 15 years ago

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"

mgkimsal3• 15 years ago

JUST DON'T TAKE AWAY MY RESET BUTTON! ;)

IgorPartola• 15 years ago

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.

romaniv2• 15 years ago

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.

mushishi• 15 years ago

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.

melling• 15 years ago

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.

knieveltech• 15 years ago

True anonymity.

tef____• 15 years ago

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.

mgkimsal3• 15 years ago

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.

gkanai2• 15 years ago

re: cookie management, have you tried Ghostery?

mgkimsal3• 15 years ago

Yeah, and I don't care for it. It's an overlay, not a browser button.

daleharvey• 15 years ago

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.

gkanai2• 15 years ago

1. Mozilla is working on this (Boot2Gecko); details here http://www.aminutewithbrendan.com/pages/20111019 and here https://wiki.mozilla.org/B2G

_urga3• 15 years ago

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.

franksalim2• 15 years ago

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.

_urga3• 15 years ago

TCP does not need the upgrade event, handshake etc. TCP is not limited by the WebSocket spec. TCP requires no additional server-side infrastructure.

amalcon2• 15 years ago

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.

_urga3• 15 years ago

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

tszyn• 15 years ago

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

politician• 15 years ago

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?

romaniv2• 15 years ago

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.

exogen4• 15 years ago

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

nephesh• 15 years ago

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.

exogen4• 15 years ago

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.

laughinghan• 15 years ago

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.

exogen4• 15 years ago

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

paulirish• 15 years ago

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.

exogen4• 15 years ago

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.

amalcon2• 15 years ago

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?

jpdoctor• 15 years ago

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.

JoshTriplett3• 15 years ago

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

angry-hacker• 15 years ago

WYSIWYG form element is an excellent idea. Never though about it before... not sure how it would be possible to implement though.

IvarTJ• 15 years ago

The web is a great application platform – it lacks a good hypertext system, though.

lmkg• 15 years ago

Non-single-threaded concurrency model for JavaScript.

ori_b2• 15 years ago

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.

prodigal_erik• 15 years ago

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

ori_b2• 15 years ago

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.

snorkel2• 15 years ago

Then how would you browse?

JoshTriplett3• 15 years ago

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.

WayneDB• 15 years ago

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

mark2422• 15 years ago

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.

pjscott2• 15 years ago

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.

mark2422• 15 years ago

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

snorkel2• 15 years ago

Broader support for BrowserID.

JoshTriplett3• 15 years ago

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.

What feature would improve the web?

Related Stories