New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We should generate the shorthands data from longhands #26

Open
FremyCompany opened this Issue Apr 4, 2016 · 10 comments

Comments

Projects
None yet
5 participants
@FremyCompany
Member

FremyCompany commented Apr 4, 2016

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

This comment has been minimized.

Member

FremyCompany commented Apr 4, 2016

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

@AmeliaBR

This comment has been minimized.

AmeliaBR commented Apr 4, 2016

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

This comment has been minimized.

Member

FremyCompany commented Apr 4, 2016

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

This comment has been minimized.

rspieker commented Apr 6, 2016

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

This comment has been minimized.

Contributor

gregwhitworth commented Apr 7, 2016

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

This comment has been minimized.

Contributor

gregwhitworth commented Apr 7, 2016

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

This comment has been minimized.

war59312 commented Apr 11, 2016

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

This comment has been minimized.

Member

FremyCompany commented Apr 11, 2016

Done. Thanks for mentioning it.

@gregwhitworth

This comment has been minimized.

Contributor

gregwhitworth commented Dec 7, 2017

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

This comment has been minimized.

AmeliaBR commented Dec 7, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment