MDN/Development/CompatibilityTables/Data Requirements: Difference between revisions

1. The first example show two tables like the ones availables on [http://caniuse.com caniuse.com]. Those tables are feature centric, which means they display data only for a single feature (or feature set). It's ideal when a user wish to have a cross browser view about a specific feature. Web developers use it quite often when they have to deal with compatibility issues while working on a specific feature. It's an operational view.

2. The second example show a table like the ones we currently have on MDN. Those tables are an overview representation. It is still a very detailed vision more feature centric than browser centric. It's ideal when a user plan to use a given set of features and wish to know the compatibility context in detail before starting to work on his project. It's also an operational view.

3. The third example show a table like the one available on [http://mobilehtml5.org mobilehtml5.org]. It provides a quick overview about the support of features (or feature sets) by a set of browser. It looks a lot like the current MDN layout but does not address the same users. Such representation is ideal for project managers or web architects who need to decide if a feature fit the requirements of their project. It's a decisional view.

4. The fourth example show various other table layouts with the ability to filter the displayed data (more about filtering below). Those layouts are more browser centric as they focus on the browser as the main input factor.

5. The fifth example show an exhaustive support chart as they exist on MDN. This is a browser centric layout made to provide an full overview of the features supported by a single browser. This is an informative view. As an example, see: https://developer.mozilla.org/en-US/docs/Mozilla_CSS_support_chart

The second idea is less important and require a deeper investigation as it can be tricky to provide an accurate information. Currently on MDN, most of our pages contain information about several features at the same time or information about feature which evolved greatly over time. Therefor, such information can be often misleading if not handled very carefully. More specificaly, Such summary information can hide inter-compatibility problems: the "support" may mean "it can be made work in this browser", "follow the spec, but maybe with a couple of minor glitch", "follow perfectly the spec". The flexbox support is one example: most modern browsers follow the spec, but maybe with a couple of minor glitch. But flexbox was available in one way or another in browsers long time ago (but interoperability was a nightmare to achieve).

As anyone can contribute to our data, we need a way to revert any vandalism or mistake while contributing. That means that we need to keep an history of the changes made to our data and a way to revert any change. We also need to track which user has made a change in order to fulfill our CC-BY license or to banish him in case of vandalism.

'''QUESTION:''' ''Do we want a user to be able to revert his own changes?''<br>

'''QUESTION:''' ''How to grant any user to revert any change?''

'''QUESTION:''' ''Do we need to make such data hard bind with compatibility data or could they be handled separately?''

 

 

The name of the specifications defining the feature.

 

'''QUESTION:''' ''Do we need that name to be localisable?''

 

 

The URL to the specification (or specification part) defining the feature.

 

'''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 number for stable specification or code names for unstable specification.''

Any complementary information regarding a specifications defining the features.

'''QUESTION:''' ''Do we need to be able to comment a specification in this context? If yes, it MUST be localisable.''

The browser logo is a good quick visual hint in many cases so we need to be able to display it.

 

'''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:''' ''Should we also take OSes and devices into account or raw implementation notes are good enough for this?''