Changes

Jump to: navigation, search

MDN/Development/CompatibilityTables/Data Requirements

981 bytes added, 11:11, 31 January 2014
no edit summary
Here is the place where all the functional requirements for compatibility data are gathered.
== Data use Use cases ==
This part intent to answer the question: What do we want to do with compatibility data? This will help us defining which data we need to have.
; === Compatibility Tables : This is the current use case for MDN. For each feature we document, we display a table providing an overview of the support of the feature on severals browsers. There is traction to be able to build data compatibility tables like the ones available on [http://caniuse.com caniuse.com].; Compatibility Badges : The idea is to provide a very quick visual hint on top of the page to tell which browser currently support the features describe on the page (it can be a logo or anything else).; Compatibility Filters : We wish to create pages listing features with the ability to show/hide some of the features based on a browser (and possibly its version) selected by the user. We would also possibly wish to build pages listing the features of a specific browser and allow the user to see the features of the version of it's choice (this especially handy for Firefox OS).; Compatibility Search : It would be nice to allow user to define one or more browsers (and their versions) to perform search on MDN and provide results only relevant for the given browsers.===
This is the current use case for MDN. For each feature we document, we display a table providing an overview of the support of the feature on severals browsers. There is traction to be able to build data compatibility tables like the ones available on [http://caniuse.com caniuse.com]. === Verbatim Compatibility Badges === There are two ideas : 1. Provide a very quick visual hint on top of the page to tell which browser currently support the features describe on the page (it can be a logo or anything else).2. Allow to create in-line compatibility badges to provides quick information within our content. === Compatibility Filters === We wish to create pages listing features with the ability to show/hide some of the features based on a browser (and possibly its version) selected by the user. We would also possibly wish to build pages listing the features of a specific browser and allow the user to see the features of the version of it's choice (this is especially handy for Firefox OS). === Compatibility Search === It would be nice to allow user to define one or more browsers (and their versions) to perform search on MDN and provide results only relevant for the given browsers. === Export API === Once the data are structured, it would be helpful to make them available through an API.
From httpsExamples:* Allow a thrid party web sites two embed our data. As an example, [http://groupslists.googlew3.comorg/Archives/forumPublic/#!topicpublic-webplatform-tests/mozilla2013OctDec/0000.html webplatform.org is planning to do it].* Allow web devtools to provide such information while using a feature.mdc/DlmsxCyRpso
* If our compatibility data are available in a structured way, How would you have us to display/use such compatibility information on MDN?
** In a compatibility table that's immediately visible when landing on the API's landing page.
** The table at the bottom of the page and a link/button in on the top to access directly to the table.
** Offering something like http://caniuse.com
** I like how the tables are displayed in http://caniuse.com because you can see at a glance if something is supported in the different versions (or if there is any regression).
*** I prefer not to use tabs to separate mobile and desktop but have all in the same table.
*** It's a good idea hide the old versions of the browsers with the option to expand the table.
*** A section of notes (or footnotes) I think is also needed to put links to bugs or documentation for not fully implemented features.
** I like http://caniuse.com display for individual API's, but I also really like http://mobilehtml5.org display for overall compatibility.
*** We have to be careful not to provide overall compatibility "scores" of sort like http://html5test.com does as it's a somehow misleading information for users.
* When contributing such compatibility data, what's bother you and how would you prefer to contribute such data?
** An "Edit" button that transforms the cells in inputs/selects and that allows add new rows (browser's versions) could be easy for contributors to maintain the tables manually.
** I want a single button, "Submit your browser's web compatibility data to Mozilla." (I'm thinking about JS API's more than CSS. I would want at least one magical button so it's super-easy for anyone to contribute to the compatibility database in 5 seconds of interaction.)
*** Perhaps running the http://modernizr.com/ suite would be the best option, perhaps enhanced with tests for other features
*** We must first agree on the database, that is knowing the information that we need, which is not "feature xyz on Fx 29 supported? Yes/No" but much more complex.
*** Get all the info that we can automatically from browsers is also a good idea, but with a warning (some kind of tag, or maybe put the cell in other color) to change or confirm the sent data.
*** I don't know if lot of people (contributors in that case) going to access MDN with browsers others that Firefox (desktop) or Chrome/Chromium, so we are not going to get data from new mobile/tablet versions of the browsers (one of the most interested things for me)
**** We can put a "campaign" around this kind of valuable data and content to invite more and new visitors to contribute.
** Caniuse allows to import Google Analytics stats, so that you know how many (current) users of your website you're leaving out if you choose to use a given features.
* Beyond displaying the data on MDN, how would you access those data (while editing MDN or on another web site), and for what purpose?
** We should publish the compatibility data in an API format too so that developer tools (Firefox, Firebug, Chrome, Sublime Text, vim, whatever) can integrate it.
** An API offering data per browser/per feature would be awesome
** An API that can be used for debugging tools would be great (and really useful)
== Data to display Displayable data ==
This part list all the pieces of data we want need to display to the users, one way or another.
=== Feature ===
To provide useful information we need to clearly define the features we are providing information about.
; name '''QUESTION:''' ''We need to handle sub-features such as specific values for CSS properties (see [https://developer.mozilla.org/en-US/docs/Web/CSS/display display]) or different Function signature or return value for JavaScript function (see [https: //developer.mozilla.org/en-US/docs/Web/API/MozMobileMessageManager.getSegmentInfoForText getSegmentInfoForText]). How to do this?'' ==== Name ==== The human readable name of the feature. <br> '''QUESTION:''' ''Do we need that name to be localisable?''; specification : A list of specification that define ==== Technology ==== The technology associated with the feature <br>(CSS, HTML, JavaScript, etc). This important to make sure features with the same name but used in different technology are clearly differentiated. '''NOTEEXAMPLES:''' ''Several specifications can define the <a single feature> tag in HTML or SVG, the display property in CSS or JavaScript, etc. The ''navigator '''QUESTION:''' '' DOM property is a good example of this case.Do we need that name to be localisable?''
'''QUESTION:''' ''We need to handle sub-features such as specific values for CSS properties (see [https://developer.mozilla.org/en-US/docs/Web/CSS/display display]) or different Function signature or return value for JavaScript function (see [https://developer.mozilla.org/en-US/docs/Web/API/MozMobileMessageManager.getSegmentInfoForText getSegmentInfoForText]). How to do this?''
=== Specification ===
In our documentation we display informations regarding the specifications defining a given feature.
 
'''NOTE:''' ''Several specifications can define a single feature. The ''navigator'' DOM property is a good example of this case.''
'''QUESTION:''' ''Do we need to make such data hard bind with compatibility data or could they be handled separately?''
; name : ==== Name ==== The name of the specifications defining the feature. ; url '''QUESTION: ''' ''Do we need that name to be localisable?'' ==== URL ==== The URL to the specification (or specification part) defining the feature.; state : ==== State ==== The state of a given specification <br> '''NOTE:''' ''This can cover many ways to define a spec state. for example, the W3C has formal state (e.g. Working Draft, Candidate Recommendation, etc.) where the ECMA has version numberfor stable specification or code names for unstable specification.''; notes : ==== Notes ==== Any complementary information regarding a specifications defining the features. <br> '''QUESTION:''' ''Do we need to be able to comment a specification in this context? If yes, it MUST be localisable.'' 
=== Browser ===
* Browser X does not implement Feature Y since version Z (In that case, the version is pointless if a browser never implemented the feature)
'''ExampleEXAMPLE:''' ''[https://developer.mozilla.org/en-US/docs/Web/CSS/display#Browser_compatibility the CSS display property with the run-in value in Chrome].'' ==== Name ==== The name of the browser. '''NOTE:''' ''Even if the number of actual browser engine creators is very low the number of browser in use is quite huge and the market is changing quickly, therefor we cannot set a finite list of browsers to display.'' ==== Logo ====
; name : The name of the browser. <br>'''NOTE:''' ''Even if the number of actual browser engine creators is very low the number of browser in use is quite huge and the market is changing quickly, therefor we cannot set a finite list of browsers to display.''; logo : The browser logo is a good quick visual hint in many cases so we need to be able to display it. <br>'''QUESTION:''' ''Do we need to be perfectly accurate in that matter by matching the exact logo for a given Browser version or do we just want to relay on the last version of a logo?''
'''QUESTION:''' ''Do we need to be perfectly accurate in that matter by matching the exact logo for a given Browser version or do we just want to relay on the last version of a logo?'' ==== Browser version Version ====
The browser version is a very important information to display but it is also the key information to bound a browser, a feature and it's implementation state (partially implemented, fully implemented, not implemented).
'''NOTE:''' ''Browser version numbering is a mess, it is not simple numbers.''
==== Browser prefix Prefix ====
Many features in their early stage are prefixed. This is mostly a CSS habits but JavaScript sometimes use it too. While displaying compatibility data, prefix can be a convenient way to mark a feature as "experimental" or "not standard" but the prefix itself must be display in order to make things clear for the user.
A browser prefix depend on the browser, the feature is defined for Feature X in Browser Y and the browser versionVersion Z.
=== Implementation notes ===
* Information about Feature X in all browsers
* Information about Feature X in Browser Y
* Information about Feature X in Browser Y in version Version Z
'''NOTE:''' ''Such information MUST be localisable.''
* https://groups.google.com/d/msg/mozilla.dev.mdc/DlmsxCyRpso/cryjYMRy6gMJ
 
=== Verbatim ===
 
From https://groups.google.com/forum/#!topic/mozilla.dev.mdc/DlmsxCyRpso
 
* If our compatibility data are available in a structured way, How would you have us to display/use such compatibility information on MDN?
** In a compatibility table that's immediately visible when landing on the API's landing page.
** The table at the bottom of the page and a link/button in on the top to access directly to the table.
** Offering something like http://caniuse.com
** I like how the tables are displayed in http://caniuse.com because you can see at a glance if something is supported in the different versions (or if there is any regression).
*** I prefer not to use tabs to separate mobile and desktop but have all in the same table.
*** It's a good idea hide the old versions of the browsers with the option to expand the table.
*** A section of notes (or footnotes) I think is also needed to put links to bugs or documentation for not fully implemented features.
** I like http://caniuse.com display for individual API's, but I also really like http://mobilehtml5.org display for overall compatibility.
*** We have to be careful not to provide overall compatibility "scores" of sort like http://html5test.com does as it's a somehow misleading information for users.
* When contributing such compatibility data, what's bother you and how would you prefer to contribute such data?
** An "Edit" button that transforms the cells in inputs/selects and that allows add new rows (browser's versions) could be easy for contributors to maintain the tables manually.
** I want a single button, "Submit your browser's web compatibility data to Mozilla." (I'm thinking about JS API's more than CSS. I would want at least one magical button so it's super-easy for anyone to contribute to the compatibility database in 5 seconds of interaction.)
*** Perhaps running the http://modernizr.com/ suite would be the best option, perhaps enhanced with tests for other features
*** We must first agree on the database, that is knowing the information that we need, which is not "feature xyz on Fx 29 supported? Yes/No" but much more complex.
*** Get all the info that we can automatically from browsers is also a good idea, but with a warning (some kind of tag, or maybe put the cell in other color) to change or confirm the sent data.
*** I don't know if lot of people (contributors in that case) going to access MDN with browsers others that Firefox (desktop) or Chrome/Chromium, so we are not going to get data from new mobile/tablet versions of the browsers (one of the most interested things for me)
**** We can put a "campaign" around this kind of valuable data and content to invite more and new visitors to contribute.
** Caniuse allows to import Google Analytics stats, so that you know how many (current) users of your website you're leaving out if you choose to use a given features.
* Beyond displaying the data on MDN, how would you access those data (while editing MDN or on another web site), and for what purpose?
** We should publish the compatibility data in an API format too so that developer tools (Firefox, Firebug, Chrome, Sublime Text, vim, whatever) can integrate it.
** An API offering data per browser/per feature would be awesome
** An API that can be used for debugging tools would be great (and really useful)
Jeremie Patonnier
Confirm
630
edits
Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/911861"

Navigation menu