Re: ClearSpec: representing implementation in W3C technical reports

Hi Nigel, 

> On 3 Mar 2022, at 7:57 pm, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> 
> Hi Philippe,
> 
> Seems to me that this biases against any specs that are not primarily implemented in browsers.

Technically correct. But! What might be interesting is if there is an analogue for data specs? Presumedly data specs are also "implemented" and have similar conformance requirements for non-browser software (i.e., accompanying implementation reports that lists real software that correctly parses/processes the data).

So, maybe, there is a general solution for both. I mean, irrespective of browser spec or data spec, everyone really just wants to know: "Cool! can I actually use this stuff? If so, since when and where?" 

> I'd like to see safeguards against inappropriate usage of this information, and ways to define other data sources. By inappropriate, I mean using it as a selection input into those specifications that are or are not suitable for onward development, given that the data sources as they are now are patchy at best.

Agree. This is a big challenge we are facing with this project. In my mind, what it really comes down to is: who is the audience? And what value do they get?  

But also, evaluating the quality of the data and making any inferences about a specs implementation status and practical applicability in the real world.

Both MDN and caniuse do a "reasonable" job in this regard (i.e., they are "good enough" solutions). But how folks ascertain that a feature can be used is often a bit of a mystery and, sadly, often wrong or somewhat misleading once one starts digging into the actual details (e.g., "sorta supported, and you gotta turn on this flag... oh, and only on certain mobile devices"). 

Further, although MDN, wpt.fyi, and caniuse are one click away, they do serve their purpose well: so, do _really_ want specs replicating all of the MDN/caniuse/WTP compat tables? Or do we just want the absolute minimum subset, and will that serve our community/audience well enough?    

Similarly with WTP data: it's extremely helpful for implementers, but can be totally meaningless to web developers (I can't imagine a regular web developer knowing what WPT is or why they should even care, specially with MDN being the authority on anything "web development").

> Also, Spec Editors are important, but specs are owned by WGs, who need to agree to this. Can we assume that this would not be mandatory?

Correct. It's all opt-in and would need to happen at a WG and spec-level. 

For example, the caniuse data shown by ReSpec is highly configurable: allowing for selection of specific browser, desktop vs mobile, etc. [1] 

Having said that, and to your point above, Editor's self-selection and quality of data from caniuse can be problematic: we get into all sorts of problems around the definition of "supported". We also see browsers deliberately excluded from the support tables, which makes the tables also serve as a marketing/self-promotion tool (i.e., "look how awesome browser X is at supporting Y... Browser Z is not even listed! lol.")  

This is compounded by WTP also, which tests things under highly restricted conditions due to various limitations: like requiring the physical hardware with particular sensors and built-in services. Despite herculean efforts, it means WPT gives us a limited view of actual support of various things... particularly for mobile devices. 

So, fundamental question again, would showing WPT data do more harm than good? Could it lead to confusion and who is best served by showing this data? 

(I know... a lot of questions... they are for everyone to think about)

[1] https://respec.org/docs/#caniuse

Received on Friday, 4 March 2022 01:05:08 UTC