The initial layout is launched, here come the tweaks 🔨 …

• Tone down colors (green especially) to be less neon ⚡
• Full browser logos on mobile
• Better bugzilla label (NEW to 12/24 Resolved, normalize the rest)
• Anchor for feature (see gh headers)
• Better separation (more space?)
• Status click targets for desktop

Source: https://github.com/Fyrd/caniuse

For now we should pull in percentage for global supported (green) and partial support (yellow) and show it in the UI as an indicator for "can I use (it)?".

Put a lens on the platform status to reflect interests of developers. Highlight some features per collection to raise awareness.

• Games
  • WebGL 2
  • WebAssembly
  • Web Audio
  • TBD …
• Apps
  • Service Workers
  • Push API
  • Web Manifest
  • Fetch API
  • BackgroundSync
  • Geofencing
  • TBD …
    Design
  • Flexbox
  • Web Animations
  • CSS Scroll Snap
  • Web Components
    • template Element
    • Shadow DOM

Appendix A

Games features outlined by @juj

• Canvas+WebGL 1.0
• WebGL 2.0
• Web Audio
  • I would really love to require two currently nonexisting features here: 16-bit integer PCM sample type, and glitch-free synthesized audio streaming API, however there is no spec upgrade to Web Audio yet to enable these.
• Pointer lock
• Full Screen
• SharedArrayBuffer
• SIMD.js
• Web Workers
  • (test APIs available in web workers?)
• Gamepad API
• IndexedDB
• Page Visibility API (http://www.w3.org/TR/page-visibility/)
• requestAnimationFrame
• Web Sockets
• WebRTC
• (WebAssembly?) (too early?)
• Mobile: touch events (i.e. multitouch, and not just single touch emulated as mouse events, http://www.w3.org/TR/touch-events/)
• Mobile: vibration API (http://www.w3.org/TR/vibration/)
• Mobile: DeviceOrientation and DeviceMotion (http://www.w3.org/TR/orientation-event/)
• Mobile: Screen Orientation API (http://www.w3.org/TR/screen-orientation/)
• Mobile: Geolocation (GPS)
• Features important specific to Emscripten (probably test these a little bit better than just feature testing):
  • Emscripten memory model:
  • ArrayBuffer.transfer (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer/transfer)
  • Test guaranteed HEAP availability: allocate a 1GB (1.5GB? 2GB?) heap and test that is must succeed. (non-mobile)
  • Test that Emscripten HEAP is properly handled as a virtual noncommitted memory until used (e.g. spawn several pages that allocate a 1GB Heap, but don't use it)
  • Emscripten filesystem interaction:
  • IndexedDB in workers
  • FileReaderSync
  • File API: Blob URLs and Blob constructor (http://www.w3.org/TR/FileAPI/#url)
• Support for running large codebases (large # of lines in the .js file, large # of functions, large # of vars in a function, large # of cases in a switch)
  • possibly doesn't need a specific test, and we could just make sure that we have a very large application that stresses these in the second part of this suite (below)
• Math.fround (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/fround)
  • Currently we have been holding this back in Emscripten and have not set this as default enabled, since even though other browser support this, not all browsers actually improve performance when having this enabled. In this suite, we should enable all tests to have this (in the strict -s PRECISE_F32=1 mode) and only measure performance with this enabled. Also, we should make sure ArrayBuffer.transfer() (-s ALLOW_MEMORY_GROWTH=1) is enabled in all tests.
• Math.imul (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/imul)
• JavaScript const keyword (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const)

Ensure that our parsers work, that external sources don't change format or otherwise break unexpectedly.

For the cookbook I use

app.use(function forceSSL(req, res, next) {
  var host = req.get('Host');
  if (!host.startsWith('localhost')) {
    // https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
    res.header('Strict-Transport-Security', 'max-age=15768000');
    // https://github.com/rangle/force-ssl-heroku/blob/master/force-ssl-heroku.js
    if (req.headers['x-forwarded-proto'] !== 'https') {
      return res.redirect('https://' + host + req.url);
    }
  }
  return next();
});

We might not have a node.js server for this one when we host it, but lets see.

https://travis-ci.org/mozilla/platatus/builds/90161405

Works with the same presentation style of 4 of 11 resolved.

For example, WebGL is prefixed in IE (see https://dev.windows.com/en-us/microsoft-edge/platform/status/webglcanvas3d), but we say it is shipped. Should we differentiate between the two?

Spawned from #8

Output:

• index.html
• status.json
• [slug].html – Vote to move to v2 ?

Currently the list of features to track is not defined within this spec. IE, Chrome, webkit all seem to track different things. We should define out list relating to WADI (or do we wish to be comprehensive live IE?).

W3C Manifest
Service Workers
Push API with permissions APIs
Notification Dashboard/Control
Push Service (autopush server supporting Webpush)
Offliner libraries (internal projects) oghliner and offliner
Background Sync (https://github.com/slightlyoff/BackgroundSync)

Some of these have subfeatures so that partial implementations may be tracked separately. This issue is to come up with the canonical list to start.

Post on hacks.

Spawned off #13 …

via @dbialer:

I think it would be good to build product KPIs directly into this so that we have a clear understanding of what success looks like and measure from the start. We should instrument and build measurability directly into the MVP with Github, feedback mechanisms, and perhaps analytics. These could include:

• a. Page/project visits as an indicator of interest in this project and usage. We should have a goal of X visits per month as an indicator of usage. What is a reasonable goal here? 5K visits per month?
• b. community participation - how many non-paid staff contributors join this (as one of the goals is to increase radical participation). We should have a goal of Y contributors by Z date. Perhaps pull requests or commits? How would 5-10 contributors (outside paid staff) by sometime in Q1?
• c. Feedback - one of the goals is feedback. How do we collect that? filing issues? Can we have a feedback form? We should have a goal of some sort of active/useful feedback. Not sure what would be good here.
• d. How do we know it is low maintenance? We should have a goal that other teams are updating their information around X features.

If we don't achieve goals that get us on the right track, then perhaps this isn't as useful as we think? So part of this project should not just be coding, but achieving the usage we desire.

Any thoughts on this?

Re: @TimAl

We should have a goal of X visits per month as an indicator of usage

Sounds good to me. I have no idea what a reasonable number would be... I also don't really know when it would be reasonable to expect usage to pick up.

We should have a goal of Y contributors by Z date. Perhaps pull requests or commits? How would 5-10 contributors (outside paid staff) by sometime in Q1?

I like the idea of making contribution a goal. These numbers sound optimistic to me but I don't know if this project will turn out to be more "if you build it they will come" or "if you start building it they will come and help out"

Feedback - one of the goals is feedback. How do we collect that? filing issues? Can we have a feedback form? We should have a goal of some sort of active/useful feedback. Not sure what would be good here.

Good points/questions. We should probably file an issue for this and continue the discussion there.

How do we know it is low maintenance?

This seems like a hugely important piece of the project. If it's not low-maintenace then eventually it will fizzle. Maybe a UX person can help us with this? Measure the number of clicks to update something? Measure the number of manual tasks? This also seems like a good candidate for a separate issue where we can discuss

So part of this project should not just be coding, but achieving the usage we desire

I totally agree with this message

shipped/preview is hard to maintain over time.

Defer release channel from version number.

Fill back from chrome data.

we need a favicon; even in the very early stages, I find it helpful to locate the app among my many tabs

Web performance best practices

From Marco's comment in #100 -

Is it waiting for the Selenium server to start? Maybe you could start it and then periodically check if it's started by checking if you can connect to its port.

Let's implement this smart wait

Few cards from the Trello board are features that we want to expose (like e10s), but the board should still be a good reference for upcoming features that need exposure in platatus.

what about a place for live benchmarks you can run against your current browser? for example, asm.js section could link to:

https://kripken.github.io/Massive/

• Run on each build (Selenium)
• Downside: We don't have much interaction yet to test

@darkwing had recommendations using Intern and Selenium.

we should somehow track the progress of this metabug?
https://bugzilla.mozilla.org/show_bug.cgi?id=1168939

Check for uniqueness of values given for bugzilla, documentation, spec, browsers reference, etc.

https://www.chromestatus.com/feature/6170807885627392

This will give us status for asm.js, Promises, etc:

https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore/features.json

Make a simple UI that serves both casual browsing and experienced users.

Looking at prior art

• Long accordion list are hard for casual browsing as they require lots of browsing, clicking while hiding a big part of the list items
• Edge sees 20% of visitors coming from mobile

Elements of a feature

• Title and one-line summary
• Firefox implementation status as first-level detail
• Enthusiasm/Implementation per vendor
  • States
    • None: Question mark - Gray
    • Deprecated/Skepticism: Disabled state - Red
    • Under Consideration: Logo enabled but faded - Orange
    • In Development: Nightly logo or another in-development indicator - Yellow
    • Shipped: Release logo - Green
  • Combination of color codes and logos
  • Additional links available to vendor status page and bug
• Standardization URL and stage
• Firefox meta (see MVP)
  • Bugzilla bug and status
  • Documentation
• Edit link to features/*.md file on github

v1 Mockup

v0 Drafts

Question: Which indicators for support status work best in a small space?

Bars

Circle indicators

When I don't run selenium manually, tests fail:

Suite firefox on any platform FAILED
Error: [POST http://localhost:4444/wd/hub/session] connect ECONNREFUSED
  at Server.createSession  <node_modules/intern/node_modules/leadfoot/Server.js:310:15>
  at <node_modules/intern/lib/executors/Runner.js:190:22>
  at retry  <node_modules/intern/lib/util.js:723:13>
  at <node_modules/intern/node_modules/dojo/Promise.ts:393:15>
  at runCallbacks  <node_modules/intern/node_modules/dojo/Promise.ts:11:11>
  at <node_modules/intern/node_modules/dojo/Promise.ts:317:4>
  at run  <node_modules/intern/node_modules/dojo/Promise.ts:237:7>
  at <node_modules/intern/node_modules/dojo/nextTick.ts:44:3>
  at process._tickCallback  <node.js:355:11>

TOTAL: tested 0 platforms, 0/0 tests failed; fatal error occurred

selenium.log shows the following error:

Error: Invalid or corrupt jarfile tests/support/var/selenium-server-standalone-2.48.2.jar

Requirements:

• HTTPS
• Pushed live by travis when pushing to gh

@zalun might be able to help here as worked a lot more with travis and hosting, maybe even within Mozilla.

Add analytics before launch to measure project success against goals from #27.

We also want to track usage to understand users and their use cases.

we could add links in our generated HTML to URL's like

https://github.com/mozilla/platatus/edit/master/features/service-worker.md

thereby allowing users of the app to easily offer corrections to our metadata.

Follow up for #26 , we will update this bug description as new ideas get added.

Shortlist

• W3C Manifest 📦
• Service Workers 📦
• Push API 📦
• Streams API 📦
• Fetch API 📦
• Promises
• Background Sync (https://github.com/slightlyoff/BackgroundSync)
• asm.js 🎮
• wasm.js 🎮
• WebGL 1 🎮
• WebGL 2 🎮
• Web Audio 🎮
• Web Sockets 🎮
• WebRTC 🎮
• SIMD 🎮
• Page Visibility API 🎮 📦
• Gamepad API 🎮
• Shared Array Buffers/Threading 🎮
• Fullscreen API 🎮 📦
• IndexedDB 🎮 📦
• Media Source Extensions (MSE)
• Pointer Lock 🎮
• Screen Orientation API 🎮
• Device Orientation/Motion Event 🎮
• Vibration API 🎮
• Custom Elements
• Shadow DOM
• HTML Templates
• HTML Imports
• Media Capture from Canvas
• MediaRecorder
• Permissions API

🎮 - requested by games team
📦 - by app initiative
❗ - piecemeal implementation/hard to track

Backlog

• Web Cryptography API ❗
• Presentation API ❗
• ES6
  • Default parameters
  • Destructuring
  • new.target
  • Classes
  • Symbols
  • Unscopables
  • Proxies
• Pointer Events
• Ambient Light Sensor API
• Navigation Timing API
• Vibration API

This will give us a level for enthusiasm/implementation, or if its missing a no-public-signals. When available we also get the implementation bug and owner. The priority is general standards/development/implementation status and not compatibility.

Browser status to fill in from external site: Webkit, Chrome, Edge

What we don't get:

• Opera
• Release version for Webkit
• Fine-grained browser-platform status (like caniuse/browsercompat)

platatus should have a w3c app manifest and tag link in the section

To show the bug with the right state a feature needs to know what the bug status is.

right now we are showing the status of tracker bugs, such as "bug (RESOLVED)".

IMHO the status of the tracker bug is rarely interesting. Instead, we should show a summary of the bugs tracked by the tracker, something like "bugs (26/30 RESOLVED)."

I have code like that at https://github.com/wfwalker/wadi-blessed-dashboard/blob/master/wadi.js#L40

I think we use Fx as shorthand for Firefox and not FF.

What works:

• mart3ll likes the dev edition gradient in the header
• mobile design works well

Improve:

• People think the icons looks broken, they probably are.
  • Fading out the icon with a gradient?
• Focus on Firefox status, other browsers are peripheral
• Bugzilla link should be closer to Firefox status and not with general links
• Palette via mart3ll: http://blog.seanmartell.com/2014/09/17/mozilla-id-project-palette-explorations/

we don't want people to accidental navigate away from our app, right?

We have references for other browsers and should construct links to them within engine; so we don't concat/escape link segments in the template.

To be decided: Testing framework. @TimAbraldes @brendandahl @mykmelez ?

Discuss what is platatus? What problem should it solve? Which technologies will be used and how?

Service worker isn't updated right now, which leads to old content being shown.