New Chromium Web Platform Feature Dashboard

[Max Heinritz]

For a while now we’ve maintained a list of Chromium’s web platform features on this chromium.org wiki page. The data itself is great, but the format of an unstructured wiki page has proved a bit unwieldy. We like caniuse.com and similar browser support resources because they’re super easy to read and update.

We think the developer community (and the web in general) benefit when it's easy to see which features landed when and view this data filtered by category, prefixed status, standardization, device support, etc.

So, we’re going to try tracking Chromium’s web platform status in a structured way. For each feature, we’ll show:

• our implementation status
• progress through the standards process
• our current understanding of the opinion of other browser vendors
• other key metrics

Please take a look at the new chromestatus.com.

Keep in mind that the data is preliminary and some of it may be incorrect, especially for subjective columns like our understanding of the opinion of other browser vendors. Please let us know if you see something missing or spot any incorrect values. Right now it’s basically just a spreadsheet, if the page is useful we may improve it further, perhaps by linking with the caniuse.com API or Chromium issue tracker.

Woo!

Max

[PhistucK]

Thank you.

So how can I update it now?

(I have a @chromium.org account)

I found one error - the full screen API is no longer behind a flag since quite a few releases ago, I believe.

(It is prefixed, though)

Also, the text must be wrapped. Currently, it is simply trimmed in a lot of places (the full screen API, for example, but the last column is trimmed in a lot of places).

☆PhistucK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 
 

[PhistucK]

Got it. With a @chromium.org account, just go to -

https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AjGgk26K1Cc-dFdfUlRQRWtjUm5XdjB4cmFGWjhTZmc#gid=0

I made all of the text wrap and corrected the implementation status of the full screen API.

What does "Stable" mean?

For example, the Web Audio API is considered "Stable" in the spreadsheet, however, it is vendor prefixed at the moment. I would not consider a vendor prefixed feature a stable feature. Should I change it to "Experimental feature"?

Perhaps introduce a new value? "Stable (but prefixed)" or something?

☆PhistucK

[Darin Fisher]

If we ship a feature to the Chrome "stable" channel, then it means we consider it a stable feature.  This applies equally to vendor prefixed properties and unprefixed properties.  A vendor prefix is just used to indicate that a feature is non-standard.

-Darin

[PhistucK]

But it means that once it is a standard feature (which could sometimes be a matter of months), it will surely change (removing the prefix)...

And besides, if the general advise is not to use prefixed features for production systems (unless I am mistaken here?), then you cannot really call them "stable".

☆PhistucK

[Adam Barth]

Perhaps we should rename "Stable" to "Shipped"?

Adam

[Alex Komoroske]

The purpose of the column is not that the feature is stable, but rather that it shipped on-by-default on the stable channel of Chrome.

There's an additional column for "prefixed".

[Adam Barth]

Maybe "Stable channel" would be a better term than "Stable"?

Adam

[Max Heinritz]

>So how can I update it now?

>(I have a @chromium.org account)

You should have edit access now if you have a chromium.org account (seems like you got it working). Thanks for your help.

+1 to Alex's comments about Stable -- it means the feature ships in the Stable channel of Chrome. I changed "Beta" => "Beta channel" and "Stable" => "Stable channel" to be more precise, per Adam's suggestion.

[Takahiro Ichihashi]

Hi Max,

I liked the visibility of wiki. But the http://www.chromestatus.com/ works as well if all the features are visible there & updated frequently. 

Just one thing I found here is that probably webrtc column need more break down. (personally I'm interested in web audio input availability)

Sorry for jumping in.

 - ti

[Max Heinritz]

Hi Ichihashi-san,

Thanks for your comment. Some of the more granular features and subfeatures don't have their own dedicated rows. We're still figuring out the right level of detail. For now I added bug links in the last column of the sheet for the WebRTC and WebAudio rows:

WebRTC -> WebAudio (crbug.com/121673)

WebAudio -> WebRTC (crbug.com/112367)

Also, I want to call out that the iframed feature dashboard on chromestatus.com is a bit difficult to navigate because the left columns and top rows are not frozen. We're working on it. In the meantime, the raw Google Spreadsheet might be easier to read: https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AjGgk26K1Cc-dFdfUlRQRWtjUm5XdjB4cmFGWjhTZmc#gid=0

Max

[Jake]

Would it be possible to have the row and column headers fixed so they're always visible when scrolling? 

On Wed, Mar 6, 2013 at 10:38 PM, Jake <ja...@jakeonthenet.com> wrote:

Would it be possible to have the row and column headers fixed so they're always visible when scrolling? 

[PhistucK]

Note that only @chromium.org accounts can view https://docs.google.com/spreadsheet/ccc?key=0AjGgk26K1Cc-dFdfUlRQRWtjUm5XdjB4cmFGWjhTZmc.

As a regular @gmail.com user - it displays the "Request access" screen.

☆PhistucK

[Max Heinritz]

>Would it be possible to have the row and column headers fixed so they're always visible when scrolling?

There are two ways to embedding the spreadsheet. With the current one, we get colored cells but no fixed headers. Vice versa for the other. For now we're prioritizing the colors.

Eventually we'd like to build a small web app that gives us more control over data presentation. For now, I recommend using the raw spreadsheet. Stay tuned.

On Thursday, March 7, 2013 12:01:44 AM UTC-8, PhistucK wrote:

Note that only @chromium.org accounts can view https://docs.google.com/spreadsheet/ccc?key=0AjGgk26K1Cc-dFdfUlRQRWtjUm5XdjB4cmFGWjhTZmc.

As a regular @gmail.com user - it displays the "Request access" screen.

I changed the spreadsheet settings to "Publicly visible on the web," but this seemed to have removed edit access for chromium.org accounts. It doesn't seem like there's a way to have both. (Tradeoffs everywhere!) Please request access if you want to edit the sheet.

[Jake]

The raw spreadsheet works fine. Thanks!

[Eric Seidel]

(I'm asking to this broad list, as I suspect others may be interested
in the answers.)

I am currently in the process of reviewing Kunihiko Sakamoto's
fantastic patch for adding CSS3 Font Loading Events:
https://bugs.webkit.org/show_bug.cgi?id=98395

Presumably this feature should be tracked by this chromestatus.com spreadsheet.

Where should I direct him to for the process/policy for doing so?


For WebKit we have this (old) documentation:
https://www.webkit.org/coding/adding-features.html

Which presumably I should consider updating to point to some of these
Chromium resources.

[Max Heinritz]

Great question. Here's a new chromestatus.com FAQ which covers common policy and process issues. Please point him there.

I added a link to the FAQ on the "Key" tab of the spreadsheet.

Eric, if you think it's appropriate, please add a reference to chromestatus.com and the FAQ in the WebKit documentation.

Thanks!

Max