Shorthands

[kof]

In CSS we can write a short notation:

border: 1px solid red;

Which is in a full form:

border-width: 1px;
border-style: solid;
border-color: red;

While shorthand is practical, it is not typable and not supported by react-native.

Should we find a replacement or even remove a support for this from this standard?

[kitten]

Well, we don't have any special cases for shorthands. We shouldn't remove them (i.e. disallow) because they're still valid CSS and then we'd need to do some conversion on-the-fly while parsing.

I think the correct approach is to write a transformer that will transform rules to a React Native format. We wouldn't really need one that just removes shorthands, I guess, since the React Native CSS-like support is a little different than just CSS without the shorthands.

[kof]

The question is more: do we want to use a transformer at consumption time of ISTF or at build time.

The benefit I see when preprocessing and removing all shorthands:

1. Shorthands are sometimes very complex, they are designed to "increase" readability for humans. ISTF is not for humans.
2. Preprocessing can be done once, before publishing, otherwise every consumer might need to do it.
3. Generally simpler output when targeting cross platform. 1.At the consumer side, not having shorthands by design, means a lot of simplicity for further postprocessing.
4. Gives you out of the box atomic css rendering capability. In atomic CSS a big issue is shorthands.

Contras:

1. Larger file size. Can be fixed when implementing the #22 (heap approach)

[kitten]

I think that’s a great idea to make it easier to manipulate the format during runtime. I would put it aside as an idea for now, but it’d definitely come in handy in combination with autoprefixing and React Native transforms as mentioned above.

Alternatively we could just write a helper that can be used as needed. I feel the more we’re trying to do when transforming the format (prefixing, flattening, expanding shorthand’s...) the slower it’s going to be when utilising an ISTF pipeline during runtime only

[kof]

I am not sure expanding is going to be a speed problem. Prefixing shouldn't be done at this build time, because we don't know where it is going to be used.

[kitten]

@kof due to the non-AST nature of this format every transformation will need up to 1 pass through the list of nodes (some optimisations are possible)

I’m talking about a runtime-only set up, so all of these would run during runtime at some point in such a setup. Not thinking about the preprocessing case, this would add an extra pass. We can see whether we can write an optimised traverser which combines some transformation steps

[kof]

You mean the amount of properties will increase due to expand and so the pass through will take more time?

[kitten]

@kof no, I mean every transformation we make (prefixing, flattening, expanding shorthand’s...) will need up to one pass through (time complexity might be less, if we combine some transformation steps with a clever traverser)

so every transformation we introduce will hurt our performance, either during build time (negligible) or runtime (for runtime-only parsing&transformation, or prefixing which should be done during runtime anyway)

[kof]

Oh, yes, I am only considering it during build time. The question is at build time before publishing of a dependency (like es7->es3) or during app build before producing user facing scripts.

[kof]

Lets create a vocabulary for all this things, because it is too often hard to understand what we are talking about! Do you like to add a vocabulary somewhere in the spec? Or mb a separate file?

[kitten]

@kof a separate glossary would be useful, yea. I can write one up this evening :)

I’d be careful to only consider it for dependencies. At the end of the day the user might have to deal with “local” ISTF from their own code, and “external” ISTF from packages. If those are treated differently then that’ll be confusing

[kof]

I’d be careful to only consider it for dependencies. At the end of the day the user might have to deal with “local” ISTF from their own code, and “external” ISTF from packages. If those are treated differently then that’ll be confusing

Definitely, I am still fighting the wording. The step where extraction of CSS and conversion to ISTF happens, how do we call it?

[kof]

So we have a pre and post- processing step. Pre is the extraction/build where we could do the expanding, because in this case expanded ISTF lands on npm and consumers don't need to expand any more. In this case we can make it part of the contract that ISTF contains only expanded CSS.

Another possibility of course is to allow the shorthands and make the expanding an optional transformation at the consumption stage, on the server at build time of the user facing script.

[kof]

I tend to think that putting more logic into preprocessing/extraction step, before ISTF format is built is a better option, since we give to consumers less things to care about (I hope so) and the resulting format is more streamlined, less complexity. Shorthands are partially very complex.

[kitten]

The step where extraction of CSS and conversion to ISTF happens, how do we call it?

I'd call it the "Parsing Stage" — should be clear enough as ISTF only concerns css-in-js, thus there's no other parsing stage on our end.

So we have a pre and post- processing step. Pre is the extraction/build where we could do the expanding, because in this case expanded ISTF lands on npm and consumers don't need to expand any more. In this case we can make it part of the contract that ISTF contains only expanded CSS.

I think those are our common terms:

• Preprocessing / ~Build-time~
• Postprocessing / ~Runtime~

Let's not call it build-time and runtime anymore, as both steps might also run during runtime-only, if we have a lib, like SC, that can be used without a build-step.

I agree that if we expand CSS it would be part of preprocessing.

I tend to think that putting more logic into preprocessing/extraction step, before ISTF format is built is a better option

Totally agreed :+1:

So the Glossary would be:

• Parsing — The process of detecting CSS-in-JS and converting it to ISTF
• Preprocessing — Transforming ISTF with various transformers to make it distributable and ready for usage in a user environment
• Postprocessing — Last transforming steps of ISTF on the client (user environment), like autoprefixing
• Stringification & Injection — Turning ISTF and the contained interpolations back into CSS and injecting it into the stylesheet
• Nodes — A node in the IST Format. Since it's an array it's an item on it of the form [TYPE, ...]

[kof]

Sounds good