Beta Testing New Compatability Tables

MDN
1

Hi All,

We’re putting a new compatibility table design into beta this week! They’ll start to appear slowly a few pages at a time.

Florian, Jean-Yves, Will, Chris, Daniel, and over 50 contributors are migrating our old browser compatibility tables into JSON. The JSON is in the browser-compat-data GitHub repo and gets published as an npm module. We’re about 35% done with the migration!

Pages that have the data migrated, will have the new design. Here’s a preview:

26
261074×169 18.2 KB

Improvements:

  • Background colours to convey a quick overview of support.
  • Display desktop and mobile data side-by-side.
  • Node.js support in JavaScript tables.
  • Responsive versions for mobile and tablet views.

Things we know we need to fix before it’s out of beta:

  • You can’t tell support without the colors.
  • Localization is spotty. Things like “Yes” and “No” have been translated but not some of the longer more complicated strings.
  • Long tables on mobile screens are really long.

Colour blind & low-contrast theme users, we’re sorry. The original design had something to help but it didn’t user test well :frowning: For now you can either: pick “show old table” in drop down menu on the top right or uncheck the beta tester check mark on your profile page. If you would like to help us user test the next colour-free solution please send me an email!

What’s next?

Thanks for using MDN!
Stephanie.

10 Likes
2

This is huge! It’s been a long time coming, and this is going to make our compatibility information so much more useful and usable

Eric Shepherd
Senior Technical Writer
MDN Web Docs: https://developer.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy

3

Fantastic to see this coming along. Thanks for all the great work Stephanie!

4

I should preface this by saying that these are way way better than the old tables.

I think the wording and styling or “Partial” is too aggressive. AIUI we get that styling if any subfeatures are not supported, or any subfeatures have any compat notes.

Quite often these things represent quite detailed aspects of the implementation: a user of the API should read the details, but can very often just use the thing fine. I think showing it yellow, with a line across and labeled “Partial”, suggests that I’ll very probably have problems using the feature.

Actually now I look at these, I think perhaps I don’t understand how it’s determined which styles to apply. For example, take https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json#Browser_compatibility. The background row has green “Yes” for Edge, but it also has a note. So does a note not trigger yellowification? And the browser_action row has a yellow “Partial” for Firefox, but the details for browser_action show only green for Firefox.

5

Thanks Will!

Partial support is something we haven’t specified very well so far. The redesign makes it a lot more visible, so I think we should find a specification for when we want to mark something as partially supported.

I think the current spec and implementation is:

  1. If there is a note for a main feature, the note icon is added ("[ ]"). The cell is not yellow, the icon is sufficient enough.
  2. If there are sub features, the cell of the main feature gets yellow, if:
    2.1 the version of one of the sub features is different to the one of the main feature.
    2.1.2 exception is if the subfeature version is null/unknown, then no yellow.
    2.2 the sub features contain notes (this is a bit inconsistent to the rule 1.).

I’m happy to discuss this spec and to change the implementation (and to fix bugs if it doesn’t work like this everywhere - please file under KumaScript and label as “bcd”).

I think we haven’t really talked about how to do this best yet, so thanks for starting to think about it.

6

If there is a note for a main feature, the note icon is added (“”). The cell is not yellow, the icon is sufficient enough.

Hmm, if “the icon is sufficient” in this case, then why not also use the icon when incompleteness is expressed in subfeatures? Why isn’t it sufficient in this case too? The disclosure arrow in this case could display the status of subfeatures for this feature, for this browser.

7

the cell of the main feature gets yellow, if:
2.1 the version of one of the sub features is different to the one of the main feature.

So if I understand it, this means that any feature that has subfeatures that were added in later browser versions, will get “Partial” in aggregate tables. Is that correct? But this is going to apply to a great many features that have very solid cross-browser support going back years.

To pick an example that’s not in WebExtensions, this means that an aggregate table would show that all browsers have partial support for border-radius. This doesn’t seem like a very helpful thing to tell people.

(I do think this is a hard problem!)

8

I think there’s two problem here:

  1. There’s information in footnotes that needs to be represented differently structurally.

Example: rel.preconnect says it has full compatibility from 39 with the footnote “Before Firefox 41, it doesn’t obey the crossorigin attribute.”

This could be full support from Firefox 41 with partial support and a footnote on Firefox 39.

I think this is just a product of migrating our textual data into a structured format and new data will be better.

  1. Figuring out feature support from a bunch of sub features is hard.

Hopefully the new table styles let people determine this themselves at a glance. If not, I think we should be handing it the same way we do “basic support” rows and doing them by human.

Stephanie.

9

One alternative would be: mark a feature as supported (green) if all its subfeatures are supported in the latest version of the browser.

10

There’s some suggestion that the [] icon used when there are notes is not clear: https://bugzilla.mozilla.org/show_bug.cgi?id=1424269.

AFAIK we tested some different icons here, and the summary is: noone understood any of them, but everyone just hovered over the icon, saw the tooltip, and understood then.

I think that the disclosure arrow at the bottom of the cell is also always visible when the [] icon is. If this is true, then perhaps we could dispense with the icon entirely, and just use the arrow as an indicator? https://screenshots.firefox.com/zSlRI50Uwubl5djW/developer.mozilla.org

11

I think we should change the [ ] to a *.

We need to keep an icon because the down arrow could be there when there are no footnotes on the current version. (The down arrow indicates that there is more information available. That could mean more information on previous versions but no restrictions on the current version.)

Well, that is how it is intended anyway :wink:

Thanks,
Stephanie.

A little history for those interested:
The icon is meant to represent “see footnotes” and started out as the same symbol we’re using in the current tables, including a number “[1]”. The number-less icon “[ ]” tested best as a replacement for the text “See Footnotes” but… I was probably thinking a bit too literally here and did not think to even test an asterisk.

1 Like
12

I agree! About the only other thing that might make more sense would be to actually use footnote numbers.

Sheppy

13

Oh, that makes sense. I thought my suggestion was too good to be true :). FWIW I agree that * would be better then [].

14

It occurred to me just now that the little widgets for opening the notes on a given feature for a particular browser are very small and may be difficult to click, especially for people with dexterity issues or people using certain types of low-precision input devices (possibly including touch screens). It might be a good idea to make them just a little bit taller.

Sheppy

15

Perhaps, yes. It would at least be worth testing some alternative heights, to see if it brings a11y advantages without affecting the look and feel too much.

The note widgets are of course keyboard accessible, providing another way to access them for those with keyboard available.

Touch screens may still be an issue though.

16

Clicking or tapping anywhere in the table cell will open them :wink:

17

True, true :wink:

I was just wondering whether the hit areas were slightly small for those on touch screens.

18

LOL - I was so sure looking at it that the little triangle widget was the hit area. Never mind then. :slight_smile:

Eric Shepherd
Senior Technical Writer

MDN Web Docs: https://developer.mozilla.org/

Blog: http://www.bitstampede.com/

Twitter: http://twitter.com/sheppy

19

I think the name of features should wrap if necessary, and always break at “.” separators. As it is, feature names can become hidden:

I think it would be great if dotted names wrapped with indentation, like:

RegisteredContentScript
    .unregister
    .someOtherThing
1 Like
20

So, yes, the names should wrap. That said, it seems to me that when looking at an article about a specific interface, it would be nice if we could remove the “InterfaceName.” part from “InterfaceName.functionName()”.

When looking at the page about the RegisteredContentScript interface or class, the compat table doesn’t need to say the name of the interface at all, really, does it?

Sheppy