[Compat-data] What does 'supported' mean?

[Stephanie Hobson]

Hi All,

As part of the UI design work for the enhanced compatibility tables[1] I've
come across a couple design decisions that need making and would like some
group input.

*As part of deciding if a feature is supported[2] we need to do some
thinking around what supported means. The API options are "yes", "no", and
"partial".*

I'll list my use cases and recommendations to get the discussion going:

1. Is a feature that requires a prefix to work 'support:yes'?
Example: display: -moz-flex;

For: caniuse would display this as a yes.

Against: Quirksmode does not display a yes. It doesn't match the spec,
devs must be aware there is a complication.

Recommendation: 'support:partial'.

2. Is a feature that requires a different name to work 'support:yes'?
Example: mozMatchesSelector()

For: caniuse would display this as a yes.

Against: Quirksmode does not display a yes. It doesn't match the spec,
devs must be aware there is a complication.

Recommendation: 'support:partial'.

3. Is a feature that the browser recognizes but does not display a UI
for 'support:yes'?
Example: <input type="date"> A javascript query for support will return
true in iOS Safari however there is no special widget provided for user
input.

For: The browser recognizes it. Caniuse displays a yes. A MDN table
displays this as a yes.

Against: Quirksmode displays a no. As a dev this feels like partial
support to me, especially if I'm trying to decide if I need to implement a
widget. The same MDN table displays this as a no >_<

Recommendation: 'support:partial'.
4. Is a feature that is behind a preference that is disabled by default
'support:yes'?
Example: Grid support in Chrome must be enabled in chrome://flags

For: ?

Against: caniuse marks this as 'no'. It doesn't matter what the dev
codes, it won't work.

Recommendation: 'support:no'.


Thanks,
Stephanie.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1006017
[2]
https://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#supports

[Chris Mills]

> On 21 Jan 2015, at 23:25, Stephanie Hobson <sho...@mozilla.com> wrote:
>
> Hi All,
>
> As part of the UI design work for the enhanced compatibility tables[1] I've
> come across a couple design decisions that need making and would like some
> group input.
>
> *As part of deciding if a feature is supported[2] we need to do some
> thinking around what supported means. The API options are "yes", "no", and
> "partial".*
>
> I'll list my use cases and recommendations to get the discussion going:
>
> 1. Is a feature that requires a prefix to work 'support:yes'?
> Example: display: -moz-flex;
>
> For: caniuse would display this as a yes.
>
> Against: Quirksmode does not display a yes. It doesn't match the spec,
> devs must be aware there is a complication.
>
> Recommendation: 'support:partial’.

I’d say this is support yes, with a prefix listed alongside, so

Yes -moz-

For example.

As long as the behaviour is exactly the same, and it otherwise follows the spec.

>
> 2. Is a feature that requires a different name to work 'support:yes'?
> Example: mozMatchesSelector()
>
> For: caniuse would display this as a yes.
>
> Against: Quirksmode does not display a yes. It doesn't match the spec,
> devs must be aware there is a complication.
>
> Recommendation: 'support:partial’.

I’d still say support yes for this, as long as the behaviousis exactly the same and follows the spec, and then provide the complication info in a footnote. It’s a bit more complicated/less obvious than just a standard prefix, so needs a note, but it’s still supported.

>
> 3. Is a feature that the browser recognizes but does not display a UI
> for 'support:yes'?
> Example: <input type="date"> A javascript query for support will return
> true in iOS Safari however there is no special widget provided for user
> input.
>
> For: The browser recognizes it. Caniuse displays a yes. A MDN table
> displays this as a yes.
>
> Against: Quirksmode displays a no. As a dev this feels like partial
> support to me, especially if I'm trying to decide if I need to implement a
> widget. The same MDN table displays this as a no >_<
>
> Recommendation: 'support:partial’.

I’d agree with support partial for this, plus a footnote to explain exactly what’s going on. The browser does something with it, but what it does do doesn’t follow the spec.

> 4. Is a feature that is behind a preference that is disabled by default
> 'support:yes'?
> Example: Grid support in Chrome must be enabled in chrome://flags
>
> For: ?
>
> Against: caniuse marks this as 'no'. It doesn't matter what the dev
> codes, it won't work.
>
> Recommendation: 'support:no’.

I’d agree, as long as you provide a footnote to mention the experimental support.

What matters is support in the user’s browser, not support in the developer’s browser. And users won’t have such prefs enabled.

>
>
> Thanks,
> Stephanie.
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1006017
> [2]
> https://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#supports

> _______________________________________________
> Mdn-drivers mailing list
> Mdn-d...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/mdn-drivers

[Jeremie Patonnier]

Hi :)

2015-01-22 9:33 GMT+01:00 Chris Mills <cmi...@mozilla.com>:

>
> > On 21 Jan 2015, at 23:25, Stephanie Hobson <sho...@mozilla.com>

> > 1. Is a feature that requires a prefix to work 'support:yes'?
> > Example: display: -moz-flex;
> >
> > For: caniuse would display this as a yes.
> >
> > Against: Quirksmode does not display a yes. It doesn't match the spec,
> > devs must be aware there is a complication.
> >
> > Recommendation: 'support:partial’.
>
> I’d say this is support yes, with a prefix listed alongside, so
>
> Yes -moz-
>
> For example.
>
> As long as the behaviour is exactly the same, and it otherwise follows the
> spec.
>

There is some ambiguity. If the prefixed version follow the spec, the
support could be mark as "yes" (hyphen is a good example of that) otherwise
it should be mark as "partial" (flex box was a good example for that). The
problem arise when a prefixed property claim to follow the spec and the
spec is changing (example of that: CSS gradient with a last minute change
in the spec)

So for prefixed stuff, I'm more in favor of marking them as
"support:partial" because it's to much in flux to be sure the support is
accurate.

> 2. Is a feature that requires a different name to work 'support:yes'?
> > Example: mozMatchesSelector()
> >
> > For: caniuse would display this as a yes.
> >
> > Against: Quirksmode does not display a yes. It doesn't match the spec,
> > devs must be aware there is a complication.
> >
> > Recommendation: 'support:partial’.
>
> I’d still say support yes for this, as long as the behaviousis exactly the
> same and follows the spec, and then provide the complication info in a
> footnote. It’s a bit more complicated/less obvious than just a standard
> prefix, so needs a note, but it’s still supported.
>

So, in echo to my previous comment, we could state that if there is no
footnotes, we could assume 'support:yes' other wise at the moment there is
a footnote for a given browser, we should assume 'support:partial'

> 3. Is a feature that the browser recognizes but does not display a UI
> > for 'support:yes'?
> > Example: <input type="date"> A javascript query for support will return
> > true in iOS Safari however there is no special widget provided for user
> > input.
> >
> > For: The browser recognizes it. Caniuse displays a yes. A MDN table
> > displays this as a yes.
> >
> > Against: Quirksmode displays a no. As a dev this feels like partial
> > support to me, especially if I'm trying to decide if I need to
> implement a
> > widget. The same MDN table displays this as a no >_<
> >
> > Recommendation: 'support:partial’.
>
> I’d agree with support partial for this, plus a footnote to explain
> exactly what’s going on. The browser does something with it, but what it
> does do doesn’t follow the spec.
>

If the spec does not require a UI, a support without UI should be mark as
'support:yes'. 'support:yes' means that the browser implement the
functionality and that its implementation is equal or richer than the spec.

In your specific example, <input type="date">, as per the HTML spec, does
not require any specific UI. It only requires content constrain and
validation. So any browser having the constrain and validation mechanism
implemented, with or without UI, should be marked as 'support:yes'.

> 4. Is a feature that is behind a preference that is disabled by default
> > 'support:yes'?
> > Example: Grid support in Chrome must be enabled in chrome://flags
> >
> > For: ?
> >
> > Against: caniuse marks this as 'no'. It doesn't matter what the dev
> > codes, it won't work.
> >
> > Recommendation: 'support:no’.
>
> I’d agree, as long as you provide a footnote to mention the experimental
> support.
>
> What matters is support in the user’s browser, not support in the
> developer’s browser. And users won’t have such prefs enabled.
>

+1: 'support:no' with a footnote

Best,
--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[Chris Mills]

> On 22 Jan 2015, at 10:03, Jeremie Patonnier <jeremie....@gmail.com> wrote:
>
> Hi :)
>
> 2015-01-22 9:33 GMT+01:00 Chris Mills <cmi...@mozilla.com>:
>
> > On 21 Jan 2015, at 23:25, Stephanie Hobson <sho...@mozilla.com>
> > 1. Is a feature that requires a prefix to work 'support:yes'?
> > Example: display: -moz-flex;
> >
> > For: caniuse would display this as a yes.
> >
> > Against: Quirksmode does not display a yes. It doesn't match the spec,
> > devs must be aware there is a complication.
> >
> > Recommendation: 'support:partial’.
>
> I’d say this is support yes, with a prefix listed alongside, so
>
> Yes -moz-
>
> For example.
>
> As long as the behaviour is exactly the same, and it otherwise follows the spec.
>
> There is some ambiguity. If the prefixed version follow the spec, the support could be mark as "yes" (hyphen is a good example of that) otherwise it should be mark as "partial" (flex box was a good example for that). The problem arise when a prefixed property claim to follow the spec and the spec is changing (example of that: CSS gradient with a last minute change in the spec)
>
> So for prefixed stuff, I'm more in favor of marking them as "support:partial" because it's to much in flux to be sure the support is accurate.

I don’t know about this. Whether we say yes or partial, a spec change can still be damaging because it makes the page content inaccurate until we update it.

I definitely agree that we should say partial if the behaviour does not follow the spec.

>
> > 2. Is a feature that requires a different name to work 'support:yes'?
> > Example: mozMatchesSelector()
> >
> > For: caniuse would display this as a yes.
> >
> > Against: Quirksmode does not display a yes. It doesn't match the spec,
> > devs must be aware there is a complication.
> >
> > Recommendation: 'support:partial’.
>
> I’d still say support yes for this, as long as the behaviousis exactly the same and follows the spec, and then provide the complication info in a footnote. It’s a bit more complicated/less obvious than just a standard prefix, so needs a note, but it’s still supported.
>
> So, in echo to my previous comment, we could state that if there is no footnotes, we could assume 'support:yes' other wise at the moment there is a footnote for a given browser, we should assume ‘support:partial'

Yup, sounds ok.

>
> > 3. Is a feature that the browser recognizes but does not display a UI
> > for 'support:yes'?
> > Example: <input type="date"> A javascript query for support will return
> > true in iOS Safari however there is no special widget provided for user
> > input.
> >
> > For: The browser recognizes it. Caniuse displays a yes. A MDN table
> > displays this as a yes.
> >
> > Against: Quirksmode displays a no. As a dev this feels like partial
> > support to me, especially if I'm trying to decide if I need to implement a
> > widget. The same MDN table displays this as a no >_<
> >
> > Recommendation: 'support:partial’.
>
> I’d agree with support partial for this, plus a footnote to explain exactly what’s going on. The browser does something with it, but what it does do doesn’t follow the spec.
>
> If the spec does not require a UI, a support without UI should be mark as 'support:yes'. 'support:yes' means that the browser implement the functionality and that its implementation is equal or richer than the spec.
>
> In your specific example, <input type="date">, as per the HTML spec, does not require any specific UI. It only requires content constrain and validation. So any browser having the constrain and validation mechanism implemented, with or without UI, should be marked as 'support:yes’.

ok, fair enough, if it does follow the spec ;-)

[Jean-Yves Perrier]

On 22/01/2015 10:03, Jeremie Patonnier wrote:
[prefixed as support:partial]

>
>
> There is some ambiguity. If the prefixed version follow the spec, the
> support could be mark as "yes" (hyphen is a good example of that) otherwise
> it should be mark as "partial" (flex box was a good example for that). The
> problem arise when a prefixed property claim to follow the spec and the
> spec is changing (example of that: CSS gradient with a last minute change
> in the spec)
>
> So for prefixed stuff, I'm more in favor of marking them as
> "support:partial" because it's to much in flux to be sure the support is
> accurate.
>

Another point here: the prefixed version can follow the spec at some
point, and the spec can be changed later. So without the implementation
changing it would go from support:yes (but prefixed) to support:partial
(and prefixed).

So I'm also for support:partial here.

>> 2. Is a feature that requires a different name to work 'support:yes'?
>>> Example: mozMatchesSelector()
>>>
>>> For: caniuse would display this as a yes.
>>>
>>> Against: Quirksmode does not display a yes. It doesn't match the spec,
>>> devs must be aware there is a complication.
>>>
>>> Recommendation: 'support:partial’.
>>
>> I’d still say support yes for this, as long as the behaviousis exactly the
>> same and follows the spec, and then provide the complication info in a
>> footnote. It’s a bit more complicated/less obvious than just a standard
>> prefix, so needs a note, but it’s still supported.
>>
>
> So, in echo to my previous comment, we could state that if there is no
> footnotes, we could assume 'support:yes' other wise at the moment there is
> a footnote for a given browser, we should assume 'support:partial'

Same for me, support:partial here.

>
>> 3. Is a feature that the browser recognizes but does not display a UI
>>> for 'support:yes'?
>>> Example: <input type="date"> A javascript query for support will return
>>> true in iOS Safari however there is no special widget provided for user
>>> input.
>>>
>>> For: The browser recognizes it. Caniuse displays a yes. A MDN table
>>> displays this as a yes.
>>>
>>> Against: Quirksmode displays a no. As a dev this feels like partial
>>> support to me, especially if I'm trying to decide if I need to
>> implement a
>>> widget. The same MDN table displays this as a no >_<
>>>
>>> Recommendation: 'support:partial’.
>>
>> I’d agree with support partial for this, plus a footnote to explain
>> exactly what’s going on. The browser does something with it, but what it
>> does do doesn’t follow the spec.
>>
>
> If the spec does not require a UI, a support without UI should be mark as
> 'support:yes'. 'support:yes' means that the browser implement the
> functionality and that its implementation is equal or richer than the spec.
>
> In your specific example, <input type="date">, as per the HTML spec, does
> not require any specific UI. It only requires content constrain and
> validation. So any browser having the constrain and validation mechanism
> implemented, with or without UI, should be marked as 'support:yes'.
>

Here also I agree with support:yes. The absence of a UI, should be a
note, though.

>> 4. Is a feature that is behind a preference that is disabled by default
>>> 'support:yes'?
>>> Example: Grid support in Chrome must be enabled in chrome://flags
>>>
>>> For: ?
>>>
>>> Against: caniuse marks this as 'no'. It doesn't matter what the dev
>>> codes, it won't work.
>>>
>>> Recommendation: 'support:no’.
>>
>> I’d agree, as long as you provide a footnote to mention the experimental
>> support.
>>
>> What matters is support in the user’s browser, not support in the
>> developer’s browser. And users won’t have such prefs enabled.
>>
>
> +1: 'support:no' with a footnote
>

+1 too: support:no with a footnote (that what I do now, wasn't what I
was doing a few months ago)


--
Jean-Yves Perrier
Senior Technical Writer / Mozilla Developer Network

[Stephanie Hobson]

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?

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?

How important do we think it is to match what other resources do?

Thanks,
Stephanie.








On Thu, Jan 22, 2015 at 4:29 AM, Jean-Yves Perrier <jype...@gmail.com>
wrote:

[Jean-Yves Perrier]

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.

[Jeremie Patonnier]

+1 with Jean-Yves

> _______________________________________________
> 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>