Browser compat: CSS shorthand properties and their component classes

[Eric Shepherd]

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

[William Bamberg]

I think it's a good idea to have data to represent this stuff, but it isn't
compat data, so it shouldn't live in browser-compat-data. It could live in
https://github.com/mdn/data (and already does for all I know).

Will

On Mon, Jun 12, 2017 at 5:35 PM, Eric Shepherd <eshe...@mozilla.com>
wrote:

> _________________________________________________________________________
> dev-mdc discussions are moving to Discourse.
> Join the MDN category at https://discourse.mozilla-community.org/c/mdn
> Unsubscribe: https://lists.mozilla.org/options/dev-mdc/wbamberg%
> 40mozilla.com?unsub=1&unsubconfirm=1
> MDN contributor guide: http://bit.ly/ContributorGuide
>

[Chris Mills]

I think this is a good idea. This data could go in

https://github.com/mdn/data/blob/master/css/properties.json

Surely?

I don’t think it exists already.

Chris Mills
MDN content lead || Mozilla
developer.mozilla.org || MDN
cmi...@mozilla.com || @chrisdavidmills

> Unsubscribe: https://lists.mozilla.org/options/dev-mdc/cmills%40mozilla.com?unsub=1&unsubconfirm=1

[Eric Shepherd]

You’re right; it belongs there rather than in browser-compat, and I’d have thought of it if I hadn’t been (a) knee-deep in b-c at the time and (b) working past 9 PM after being up starting at 4 AM. :)

Chris is right — https://github.com/mdn/data/blob/master/css/properties.json is a good place for that info. The same basic concept would apply — changing background to include a “subproperties” property (which I think is more obvious what it means than “shorthand”, but really either one would do):

“background”: {
"syntax": "[ <bg-layer> , ]* <final-bg-layer>”,
"media": "visual”,
"inherited": false,
“subproperties”: [
"background-color”,
“background-size”,
…
],
…


And so on. Then the same kind of thing in background-color:

"background-color": {
"syntax": "<color>",
"media": "visual",
"inherited": false,
“shorthand”: “background”,
...

This would get us the information needed for this sort of relationship building. It would then be trivial to create macros like {{LonghandProperties}} and {{ShorthandProperty}} (or whatever, depending on the naming we decide upon), thereby removing the need to manually update all those lists while at the same time avoiding having custom macros for each set of properties. It would also be possible to create a {{SiblingProperties}} or {{RelatedProperties}} by looking for “shorthand”, then looking up that property to get the list of siblings. This is better than managing the same list of properties all over the place, by far, I think.

This will help us have more thorough documentation with less per-incident cost over the medium and long term, with only a fairly minor up-front investment of time.

> On Jun 13, 2017, at 12:26 AM, William Bamberg <wbam...@mozilla.com> wrote:
>
> I think it's a good idea to have data to represent this stuff, but it isn't compat data, so it shouldn't live in browser-compat-data. It could live in https://github.com/mdn/data (and already does for all I know).
>

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network

[Florian Scholz]

Can you file this as a suggestion here https://github.com/mdn/data/issues ?

Thanks!

--
Florian Scholz

Technical Writer
Mozilla Developer Network

On Tue, Jun 13, 2017 at 1:32 PM, Eric Shepherd <eshe...@mozilla.com>
wrote: