Re: [Compat-data] What does 'supported' mean? [Decision]

[Stephanie Hobson]

Rest assured that the api also provide ways to signal footnotes, flags, and
alternate spellings all of which will can be combined with support to
provide a fuller picture :)

1. Is a feature that requires a prefix to work 'support:yes'?
If it matches the current spec, support: yes.
2. Is a feature that requires a different name to work 'support:yes'?
If it matches the current spec, support: yes.

There was not a clear consensus on 1 and 2 so I am going to error on the
side of making developer's lives easier and copy what caniuse does. A lot
of our users go back and fourth between the two, might as well save them
some mental energy.

It's frustrating to think that the spec could change on us but it's an edge
case we have no clear way to predict. For display on MDN, I will provide a
warning that prefixed behaviour may be invalidated by a spec change but it
will be up to our other api consumers to decide how to handle this.

3. Is a feature that the browser recognizes but does not display a UI for
'support:yes'?
If the spec does not require a UI support:yes, otherwise support:partial
4. Is a feature that is behind a preference that is disabled by default
'support:yes'?
support: no

Consensus!

Thanks,
Stephanie.



On Fri, Jan 23, 2015 at 1:56 AM, Jeremie Patonnier <
jeremie....@gmail.com> wrote:

> +1 with Jean-Yves
>
> 2015-01-22 20:56 GMT+01:00 Jean-Yves Perrier <jype...@gmail.com>:
>
> > On 22/01/2015 19:45, Stephanie Hobson wrote:
> > > Looks like we have agreement on 3 and 4 :)
> > >
> > > There's agreement that 1 (prefix) and 2 (alternate names) should be
> > > support:partial if they do not match the spec.
> > >
> > > Discussion seems to be around what to do if the prefixed implementation
> > > matches the spec but the spec could change. I have some questions that
> > > could help decide:
> > >
> > > Where there's been changes in the past have they occurred around the
> same
> > > place in the process? Could we say support:partial for prefixes that
> > match
> > > working drafts and candidate recommendations but say support:yes with
> > > confidence if it's a proposed recommendation?
> > In the CSSWG process, there are no significant changes between a CR and
> > a PR, never. If there are significant changes, the spec goes back to
> > WDLC (Working Draft Last Call) first; this happened quite often,
> > especially with complicated features (E.g. flexbox).
> >
> > But this is the W3C process. Not all specs are following it (and
> > strictly speaking Tim Berners Lee can overule the W3Cprocess, cf HTML5
> > spec).
> >
> > > Are compatibility tables a place to be teaching new devs that prefixes
> > are
> > > complicated or can we assume that seasoned devs are aware that a prefix
> > > could mean future complications?
> > I don't think we should teach them there (except via a link to a
> > "prefix" article maybe).
> > > How important do we think it is to match what other resources do?
> > >
> > I don't think matching other resources is relevant. But if they do
> > things differently, it may be interesting to see how and understand why,
> > and nod just discard them.
> >
> > --
> > Jean-Yves Perrier
> > Senior Technical Writer / Mozilla Developer Network
> >
> >
> > _______________________________________________
> > Mdn-drivers mailing list
> > Mdn-d...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/mdn-drivers
> >
>
>
>
> --
> Jeremie
> .............................
> Web : http://jeremie.patonnier.net
> Twitter : @JeremiePat <http://twitter.com/JeremiePat>
> _______________________________________________
> Mdn-drivers mailing list
> Mdn-d...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/mdn-drivers
>

[John Whitlock]

Added as bug 1128531

https://bugzilla.mozilla.org/show_bug.cgi?id=1128531

This covers:
- The API change to force support=No if support.default_config !=
support.requires_config
- The documentation change to describe the consensus

Based on the discussion, when importing a prefixed support from MDN,
support=Partial if there is a note or footnote, and support=Yes if there is
none. Contributors can adjust these after import. The import process is
currently in development (bug 1079920), so no new bug written.

https://bugzilla.mozilla.org/show_bug.cgi?id=1079920

John


On Fri, Jan 30, 2015 at 1:35 PM, Stephanie Hobson <sho...@mozilla.com>
wrote: