[Framework] Complete implementation info with badges

[tidoust]

NB: PR is not yet ready to merge!

Some updates on the way to improve the implementation info rendered on screen (#13, #128, #143, #211)

The code now renders more specific implementation information on screen using visual badges on top of browser icons. Badges are:

• Feature available on desktop only / mobile only / desktop and mobile
• Features requires using a prefix
• Feature is behind a flag

Essentially, there will always be a desktop/mobile badge and, most of the time, that badge will be the "desktop and mobile" one, because most recent features are developed on all platforms. FWIW, I tried different ideas there, including separating the desktop and mobile info completely, or using "not on desktop/mobile" badges to be able to use bare browser icons most of the time. The solution proposed here is the best I found so far...

A tooltip explains what the implementation info means, for instance:
"Experimental in Chrome (mobile). Feature requires using a prefix. Source: Chrome Platform Status."

That text also appears in a span element for accessibility readers.

Clicking on the browser icon takes the reader to the right page on the Platform Status Web site where the implementation info comes from.

Some changes made to the extract-impl-data.js script to make things possible:

• The script now sets a selected flag on the implementation info that is considered to be the right one for each user agent.
• The script also sets the URL to look at on the underlyin Platform Status Web site to get additional info.
• The script only runs the selection logic once (it incorrectly ran after each step)
• The Chrome Platform Status platform was marked as authoritative for Chrome for Android (it was only considered as authoritative for Chrome for Desktop)

The styles of the generated table have been slightly updated to set some minimum width to the implementation column (enough to render 5 browsers), and some maximum width to the feature column (to keep it short).

Also created a tr function to translate strings instead of passing the translations object around.

What still needs to be done:

1. add missing browser icons for Baidu, QQ, Samsung Internet, UC.
2. expose the filtering logic in the implementation column, so that the user may choose what browsers she wants to see
3. some way to let the roadmap author specify the default profile, such as "show main browsers", or "show all browsers".
4. Further improvements to the styles of the table (I think I'll merge the spec name and group columns in particular, similar to what is done in the new TR page, to save some space and improve readability)

[tidoust]

I added missing icons for Baidu, QQ, Samsung Internet, UC. They can probably still be improved (I could not really find a good logo for Baidu's browser in particular).

The implementation column now exposes a filtering menu using a <details> element that allows the user to select which browsers get displayed. See commit message for details. It's not perfect, but does the job...

I did not add any mechanism to let the author specify a list of UAs to render by default. I propose to postpone that to another PR. The current default is to display the four main codebases, because that's where the bulk of the implementation info is.

The translation logic for the filtering menu is still missing. That still needs to be done before the PR can be merged.

[tidoust]

Translation logic now done. The PR should now be ready for full review and merge.

Note: The need to handle translations for the filtering menu means that the translations.xx.json files need to be preserved when the roadmap is published, and that the links to the utils.js script also need to be preserved in the generated pages.

[xfq]

This PR is too large for me to effectively review, so I just reviewed the major parts (the code logic), and trust you for the rest of the patch.

[xfq]

Thanks! I'll push a fix to the Baidu Browser's logo.

[tidoust]

Thanks @xfq, the PR started small, it just grew out of control ;-)

I realized last night that making filter-implstatus.js assemble the filtering menu is not what I should have done. As explained above, this means that script now needs to load translation files, which need to be preserved when the roadmap is published. But the filtering menu can actually be prepared by the generate.js script, with filter-implstatus.js only enabling the menu and reacting to changes.

This would have the benefit of keeping the logic once the page is generated simple. I'll try to craft another PR.