We should generate the shorthands data from longhands

[FremyCompany]

The "padding" property shows up in cases where browsers cannot unfold to longhands.
We have the data for the longhands; we should use that to "build" the shorthand data...

[FremyCompany]

That would also solve the issue we have with "overflow" where Edge and Chrome do things differently.

[AmeliaBR]

Possible improvements, in order of easiness:

1. Add some sort of warning/explanation to the website to redirect users to the longhand values.
2. Create summary data values for the shorthands that compile the data from the longhands.
3. Change the data collection process so that it can actually detect whether the CSS code is using shorthand or longhand declarations. This will be particularly useful as established properties are expanded into shorthand/longhand forms (e.g. text-decoration).

[FremyCompany]

Great comments! For posterity, here are some details:

• Doing 1 should be really easy to do, we already have the necessary data already. Bonus point: we can do it on the website without rerunning any data post processing or changing the script. That's probably what we are aiming at for current release.
• Doing 2 is definitely the right fix for the issue, but we will probably work on that for next release.
• Doing 3 is really difficult, because browsers keep lying about what they see. We really want to get the style as the browsers understand it, not as the author meant it. Sometime they talk past each other a little bit, but that's a picture of how the web works today...

[rspieker]

There is one slight concern with option 2, for it cannot possibly differentiate between explicit and implicit declarations for interpolated declarations such as padding, margin, border and border-radius.

For example:

padding: 1em;
padding-bottom: 0;

which is equivalent to:

padding: 1em 1em 0;

which results in (and is equivalent to):

padding-top: 1em;
padding-right: 1em;
padding-bottom: 0px;
padding-left: 1em;

I'm not sure if the purpose of the tool is to provide such detailed insight, so I may be overcomplicating the issue, in which case I'd aim for option 1 and simply explain (and/or refer to the CSS-specification) how shorthand declarations are always expanded to their longhand counterparts.

[gregwhitworth]

I agree, in the short term we will look at a way to clarify the serialization issue with var() on shorthands that accidentally squeak through. We do not want to get into the business of re-computing the longhands from shorthands as that is the whole point of using the browser engines themselves is to find interop, browser and spec issues, which I believe this is since there is an inconsistency between how custom props are being serialized into the OM in comparison to other shorthands.

[gregwhitworth]

So this is actually defined in the custom props specification, I've sent an email to the list to help get this clarified in the CSSOM spec. We'll still come up with a way to word this and map them to one another somehow. Initially, in a simple way, but we may (if a shorthand exists) pull in the longhand info in a meaningful way somehow.

[war59312]

Microsoft Developers, you should label yourself as "Microsoft Edge member".

Like Kodi does here:

xbmc/xbmc#9541 (comment)

So it's more obvious who is who. ;) Sorry for off topic. Would help.. Thank you.

[FremyCompany]

Done. Thanks for mentioning it.

[gregwhitworth]

A person on twitter had a good idea for clearing up the confusion initially by removing the shorthands until we determine a way to populate them. I was thinking about this, and one way we could do this is while iterating over every node, do a getComputedStyle(<node>).getPropertyValue(<shorthand>) and that would allow us to bypass needing to reparse the stylesheets. That said, looking at a test of this option results in an interop issue where FF/Edge return nothing for shorthands while webkit based browsers return values: http://jsbin.com/foditajaju/edit?html,js,console,output

I'll go glance at what the spec says to do here.

[AmeliaBR]

The spec says to serialize the shorthand if it can accurately reflect the longhands, or return an empty string otherwise:

https://www.w3.org/TR/cssom-1/#serialize-a-css-value

So, if you have a border-image, then the border property should return an empty string, because it resets border-image but cannot set a specific image value. Or if you have one of the new font-variant options, then the font shorthand would be an empty string.

https://codepen.io/AmeliaBR/pen/QOXdMz/?editors=1111

Chrome matches the spec. WebKit serializes the shorthand even if there are affected longhands that can't be represented (also, it's not including bold in the shorthand in my demo, don't know why not). As @gregwhitworth discovered, Firefox and Edge always return the empty string.