Shared publicly  - 
 
What is your top request for the Web Platform?

What is missing that would help to create compelling webapps? What do you see in other application platforms that the web should have? What feature should be added, or spec created, that would significantly improve what you could build on the web?

https://www.google.com/moderator/#16/e=200e26

Please submit your requests above. I asked this a year ago ( http://paulirish.com/2011/what-feature-would-improve-the-web/ ) but it's time to get some new ideas. BIG ideas!
32
11
Robin Drexler's profile photoJim Munro's profile photoKym Dusting's profile photocorey light's profile photo
52 comments
 
Please do! I'm about to flood this with people so I want to get some good suggestions in here first.
 
One language. A universal code syntax. I guess I'm asking for coffee script, or something similar, that can compile to any other syntax.
 
There are already projects underway which would fix/improve things (such as the flexbox) that just haven't fully developed yet.
 
How about.. a full blown W3C spec for responsive design?
 
I think the biggest problem isn't new features, it's phasing out older browsers that are still widely used in enterprise.
 
Streams. NodeJs like streams with support for strings and typed arrays (buffers)
 
Who down voted "faster app startups"? Really? :)
 
May sound stupid, but we're lacking native notification support for various operating systems. Osx now has it's implementation through Safari, and Ubuntu will get another one. Chrome desktop notifications do not count, as they're not native.
 
Let's try keep the requests very specific.

For example, APIs/features that address very specific issues you've run into during development. Something like "high performance audio" is good, but it's very broad. "Native feature detection for all CSS/JS features" is specific.
 
It would be nice to have mobile phone sensor capabilities potentially with ability to request said information.
 
+Ruben Orduz at a macro level, i think you're right. Looking at any new API in the browser, i think most of our reactions are a mix of excitement, fear, and uncertainty. We are never sure these things are "production ready" and have enough cross browser support (even modern browsers) to really feel confident in developing on them.
 
Metadata for alternate text embedded in image formats that user agents leverage to default for alt text.
 
cross browser paste without crud formatting while keeping semantic markup (headings, paragraphs) links and embeds. (total wish for those of use working in large user base cms with content editable or wysiwyg editors)
 
Some style logic in CSS, so we can make conditions intead mix javascript adding classes because we're mixing desing and logic with that. It will be nice to apply some styles to the body just if there's a section with a "foo" class.
 
Maybe there's no need of logic, but an inverse selector would be nice.
 
A chrome frame that does not need to be installed client side.  Script is thrown into site.  User goes to the site.  User sees the page rendered as it would be in Chrome.  Regardless of what browser they install.  The icing?  Same thing on mobile with WebKit.
 
Maybe you already have these in your previous survey:

Modularity, code protection (not just obfuscation ) and a Real IDE. 
 
we have great feature detection tools, but the polyfill world feels unreliable. similar to the chrome frame request, it would be rad if one single tool could reliably fill the gaps in my visiting users browser. extra points if it only filled where my app needed to fill the browser. maybe a manifest is compiled during minification builds or something

that way we could always be using the newest n coolest code, with the same confidence we have with display: block, prefix free fo sho
 
1) Native AMD. Something like require module in nodejs.
2) Native deferred script loading.
3) JavaScript media types (like CSS media types). Examples would be: mobile, desktop, touchscreen. This removes the concern of feature/browser detection and leaves it to the best candidate to know what it needs; the browser itself.
4) Non-proprietary way to access the prototype (no _proto_).
5) Compile and run stylesheets like: text/less, text/jade text/plates. Just like an HTML has a doctype, CSS pre-compilers can have one that allows for native pre-compiling.
6) A standard way of templating HTML.
7) If I type in "window.showMeTheMoney()" web apps will instantly build themselves from specs in my mind. You're welcome.
 
+Paden Portillo 
1) ES6 modules. It's coming
2) script[defer]. Been in Chrome/Firefox for years.
3) I like the idea of applying media queries to script elements. Fallback story is painful though. :/
4) Not totally up to speed on my ES6, though I think Object.getPrototypeOf() captures this
5) less/jade/sass all release new versions with new syntax regularly. While I love them it feels dangerous to bake support into the browser that is so volatile
6) https://code.google.com/p/mdv/ is coming to WebKit..
7) YES!

Great list, sir. :)
 
+Paul Irish
2) defer and async for inline scripts would be cool.
6) nice but I see HTML variables here... ?
 
I think a standard URI Map would be of great use and very powerful for web applications. 
This would enable a central location for a webapp to define its images, URL endpoints (parameterised), script locations...whatever using relative or absolute paths.
This could be referenced across multiple pages to define the same resource without specifying again its URI or this map could itself then be hosted and used across multiple webapps.

Using CSS selectors, it could look something like:

Markup:
<img class="myLogo" />
<script id="jQuery" />

Map:
".myLogo" : "/img/logo.png",
"#myMainScript" : "https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"

The location of the URI directory could be specified similar to the cache manifest file (relative or absolute):

<html uri-dir="http://www.myapp.com/uri.dir" >

Benefits include:
1) Cleaner, more semantic markup
    I only care that an element is an image and not where it is located.

2) Reusability
    Define a resource once and reference it many times across a        single or multiple sites.

3) Transparency
    We have a central location for all to inspect a URI.    

4) Maintainability
    If a resource changes,  we only need to change it in one location.

My 2 cents.
 
+Paden Portillo I second JS media types - although I suspect it would be frowned upon by code evangelists it would be extremely practical.
 
I just can't wait for the newly proposed <picture> element to work its way into HTML5!
 
humm... and also the death of IE :P
 
One rendering engine for all browsers. Seriously. This will never happen, but it would be cool.
 
Variety can be a good thing. The competition and the different ways of solving problems lead to a better web in the end. At least i believe that.
 
+Joe Nerdan Hmm... but we have to check several browsers every time. As developers/designers we spend far too much time strugglin around with different rendering of elements.
 
That`s true. But the gaps become smaller, there are frameworks to help you with that (especially for mobile) and i`m willing to take a little pain to support the diversity of browsers.
 
Better layouts. I'd like to be able to change the position of some elements without changing the position in the DOM. An example would be moving the navigation to the bottom on mobile.
 
How about a reliable non-spoofable (simpler) user agent string? We're not there yet are we?
 
+Sunny Walker I think the whole point of all this is to never need to sniff the user agent string. With modernizr, you rarely if ever should need to
 
How about href attributes on elements other than anchors and drop the anchor tag? I would love it if I could put an href on an li or heading, etc. may not be ideal for every element, but the death of the anchor would be awesome. 
 
+Jim Munro well you can wrap anything in an anchor now, and if all you need is :hover you can use that on any element
 
I use browser sniffing not for features but for analytics, +JP DeVries, so there are other legitimate uses. Modernizr is awesome (I use it), but it also shouldn't be necessary. In fact, maybe that's a better suggestion: roll modernizr's features into the browser!
 
Add jquery as an official language spec <script type="text/jquery">

Ok, maybe not likely, but it's worth a try :)
 
+Philipp Dunkel that is already being considered via adding a dollar sign to the element being styled. For example, .article $.pre-button button:hover would style elements with a "pre-button" class containing a button being hovered over, all within an article.


Note: this is a bad example because you could use pseudo-elements, but you get the idea.
 
CSS stuff like variables that scss and less have had for so long, or maybe a way to add other languages more easily. Also maybe add a way to use regex in CSS selectors e.g. (Regex()) added to part of the selector?
 
We also need a sarcasm tag with "sincerity" attribute
 
A native html feature detection API could really speed things up
 
+Ben Greer agreed.@supports queries are currently being discussed, but an HTML version would be very helpful (and a JS version)
 
+Dale Martyn Check out flexbox. I'm with +Robin Drexler on the notifications - the simple Alert could be so much more useful. Maybe a more powerful (customizable) version of it that is like a modal?
 
I was passing time before a doctor's appointment, and found an interesting article in American Scientist.
http://www.americanscientist.org/issues/pub/pixels-or-perish

I'll summarize some disadvantage points I picked up:

1. Pixels: The problem of fractional pixels. SVG helps, with animations and responsive design...

2. Complexity.  D3.js, Processing, R, etc. help but it still takes a good deal of technical skill to compose diagrams for the web.

3. Permanence - Will today's content exist on the web of tomorrow.  A URI might change, be restricted, or cease to exist in the future. Specs might be deprecated. Researchers are gravitating to PDF for stablility, especially with vector graphics.
--

This had me thinking about:
- Declarative HTML and CSS rather than JSON and helper scripts.
- Scoped CSS in Content Tools (polyfill somehow?).
- Is anybody working with MDV for SVG?
- Can some interactions be declarative?
- Native JS events for Elements leaving the visible area and/or being removed (videos in a slideshow or in google reader).
 
If were just dreaming about really big ideas for minute. Then why not a new web language built around making concurrency simple for laymen. I'm NOT promoting the idea that yet another  dart or even coffeescript here. Eventually we are going to need multithreading in the document. Webworkers only recognize the need, not make it easy.  I don't mean build another Java VM that allows low level thread primitives either. I mean something simple enough that you might not even know your writing concurrent code. Maybe picking up a few tips from Haskell or Erlang. If were lucky we might even get the option of compiled source code support in the VM and save some bandwidth