I’d like to suggest a change to the browser compat schema in which we add the following to “feature":
An optional “shorthand” property, which specifies the name of another feature which includes the functionality of the described feature. For example, this would be set to “background” in the feature property for background-clip, so that there’s a quick way to tell from the JSON that the CSS property being described has a shorthand property available, and what its name is.
An optional “longhand” property, which is an array of strings, each string being the name of another API whose functionality is included by the feature being described.
For example, if this were implemented, you’d change background.json so that it includes this:
{
“version”: “1.0.0”,
“data”: {
“css”: {
“properties”: {
“background”: {
“longhand”: [
“background-color”,
“background-clip”,
“background-repeat,
…
],
“__compat”: {
…
And so on.
Then in background-color, you’d have something like:
{
“version”: “1.0.0”,
“data”: {
“css”: {
“properties”: {
“background-color”: {
“shorthand”: “background",
“__compat”: {
…
With this, we can establish a smooth linkage between these properties that allows code to easily construct lists of related content from them, build navigation, and so forth. In addition, you can create the lists of longhand properties without having to do it by hand or use special macros for each group, which leads to these lists being easier to maintain in the future. A single “LonghandProperties” macro would do the job for any CSS property, without needing to make content changes at all.
This would probably also make it possible to improve our SEO by getting these properties out there in more places more easily and accurately.
I don’t know if this could be adapted to things other than CSS properties, but it’s possible.
Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <
https://developer.mozilla.org/>
Blog:
https://www.bitstampede.com/
Twitter:
https://twitter.com/sheppy