First draft #17

kof · 2017-05-30T13:08:52Z

This is mainly to discuss the details of it and raise all concerns. cc @geelen

tabatkins · 2017-05-30T17:59:45Z

readme.md

+```js
+[
+  [RULE_START],
+    [RULE_TYPE, 1],


Merge this value into the previous token ([RULE_START 1]); no need to wait until the second token of the rule to find out what type of rule it is. Then you can drop RULE_TYPE entirely.

Yep, thought about that too.

tabatkins · 2017-05-30T18:05:50Z

readme.md

+    [PROPERTY, 'color'],
+    [VALUE, 'red'],
+    [RULE_START],
+      [SELECTOR, REF, ':hover'],


This structure doesn't seem to let you distinguish between & :hover and &:hover. I suggest the SELECTOR rule should actually break down the selector structurally.

Maybe after the SELECTOR, an alternating sequence of compound selectors and combinators, where each compound selector is an array of simple selectors, which are strings?

That is, &:hover would produce [SELECTOR ["&", ":hover"]], while & :hover would produce [SELECTOR ["&"] " " [":hover"]].

true that, maybe a spacer marker?

'& :hover' -> [SELECTOR, REF, SPACE, ':hover'] '&:hover' -> [SELECTOR, REF, ':hover']

How would the selector &.foo.bar .baz be encoded?

(I'm trying to push you to a consistent, extensible selector representation that minimizes the amount of hand-parsing end-users have to do, which maximizes the likelihood that they'll parse things correctly.)

&.foo.bar .baz -> [SELECTOR, REF, '.foo', '.bar', SPACE, '.baz']

bad idea?

I'm trying to push you to a consistent, extensible selector representation

Totally appreciate that!

tabatkins · 2017-05-30T18:06:55Z

readme.md

+[
+  [RULE_START],
+    [RULE_TYPE, 1],
+    [SELECTOR, SCOPED, '.foo'],


Similarly, is there some restriction of one-class-per-selector in effect here? Otherwise, you can't tell what's supposed to be scoped; or are all the classes meant to be? Less sure what the right answer would look like here, tho.

I was thinking that we can only have one class here, there is an example with multiple classes in one selector.

so if we need multiple classes in one selector it would looke like this:

[SELECTOR, SCOPED, '.foo'] [SELECTOR, SCOPED, '.bar']

That indicates a selector like .foo-XXX, .bar-XXX, right? I was talking about a selector like .foo-XXX.bar-XXX, where they're both in the same compound selector.

Ah good point!

What about this?

All scoped: .foo.bar -> [SELECTOR, SCOPED, '.foo', '.bar']
Some scoped: .foo.bar -> [SELECTOR, [SCOPED, '.foo'], '.bar']

tabatkins · 2017-05-30T18:07:37Z

readme.md

+    [SELECTOR, '.foo'],
+    [PROPERTY, 'border'],
+    [VALUE, '1px solid red'],
+    [VALUE, '1px solid green'],


I like the recognition of list-valued properties here, and the representation as distinct values. A+.

What I personally dislike is the use of shortcuts. I think we need to come up with a format completely without shortcuts.

kof · 2017-05-30T21:10:14Z

readme.md

+[
+  [RULE_START],
+    [RULE_TYPE, 1],
+    [SELECTOR, SCOPED, '.foo'],


Another thought in regard of SCOPED. Actually if we want to let the consumers generate selectors, this thing is just a NAME.

We need a concept of a named rule: foo {color: red}, where foo is any user defined name.

Not scoped selector: .foo -> [SELECTOR, '.foo']
Named: foo -> [NAME, 'foo']

A rule may have just one name, but may have multiple selectors and a name.

Ah, that makes sense. So a "name" is gonna be auto-generated with some prefix, to help ensure there are no accidental name clashes, right? That's why "scoped" rules only need a single class - that's basically by definition. In that case, yeah, a separate command that is morally equivalent to a selector, but should only appear at most once per rule, sounds best.

"name" is gonna be auto-generated with some prefix

This is one possibility, though I was thinking to let consumers generate them. Generating prefixes at build time on the publisher side would mean we need to ensure the uniqueness for the entire world. Leaving it up to consumer in a specific project will reduce the probability for clashes to the project context. Also there are multiple ways to generate an id, counter based is the most efficient, hashes - not so much.

kof · 2017-05-31T10:40:06Z

Updated the spec.

- No separate RULE_TYPE - NAME - REF=>PARENT_SELECTOR - SPACE

tabatkins · 2017-05-31T20:01:46Z

readme.md

+const PROPERTY = 4
+const VALUE = 5
+const PARENT_SELECTOR = 6
+const SPACE = 7


You're gonna want more than SPACE if you're going this way - you want all five of the combinators, at least. Are you expecting this to be extensible by libraries, or always limited to the set of official CSS ones?

Right, maybe we need a COMBINATOR which can have these values: ' ', '>', '>>', '+', '~']

Better ideas?

Or otherwise separate constant for each combinator.

As the combinators amount is limited to 5, I would probably go for separate constants, because this will make the result more compact.

tabatkins · 2017-05-31T20:03:01Z

readme.md

+
+Selector compound e.g. `.foo.bar` => `[SELECTOR, '.foo', '.bar']`
+
+Multiple classes e.g. `.foo .bar` => `[SELECTOR, '.foo'], [SELECTOR, '.bar']`


This isn't right; the description down below is that you generate multiple [SELECTOR ...] tokens to represent comma-separated selectors, like .foo, .bar, which evaluate independently.

(The terms you want, btw, are "compound selector" for things like .foo.bar, "complex selector" when combinators are involved like .foo .bar, and "X selector list" when commas are involved, like .foo, .bar.)

Thanks, so this example should be

Selector list e.g. .foo, .bar => [SELECTOR, '.foo'], [SELECTOR, '.bar']

tabatkins · 2017-05-31T20:08:09Z

readme.md

+
+Denotes a selector or selector compound.
+
+Selector compound e.g. `.foo.bar` => `[SELECTOR, '.foo', '.bar']`


How do plan to handle pseudo-classes with arguments, particularly ones that take selectors as arguments like :matches(.foo, .bar)?

Idea: FUNCTION constant followed by a function name and arguments

[FUNCTION, ':matches', '.foo', '.bar']

When combined with another selector:

.bla:matches(:hover, :active) => [SELECTOR, '.bla', [FUNCTION, ':matches', ':hover', ':active']]

…sed standalone now

kof · 2017-06-03T12:20:55Z

Updated the spec

kof · 2017-06-06T11:52:32Z

@tabatkins btw. this format could be also fixing the interoperability between less, sass and cssinjs!

kof · 2017-06-08T18:15:48Z

@tabatkins @geelen do you have more thoughts about this PR?

geelen · 2017-06-14T00:24:20Z

This is starting to shape up! I noticed one thing missing—dynamic values. For styled components, we need the ability for parts of the CSS to be injected based on props or theme variables, and if the intermediate format doesn't support that then we'd not be able to publish cross-compatible components—we'd have to publish full Styled Components.

So, I think it's worth considering areas where dynamic injections might occur, and a way to invert control so that injections can be evaluated as a snippet is executed. It could be as simple as something like:

.foo-123456 {
  color: ${ props => props.red ? 'red' : 'blue' };
  margin: 0.25em;

  ${ props => props.big && css`
    font-size: 1.25em;
    margin: 0.5em;
  }
}

[
  [RULE_START, 1],
    [RULE_NAME, 'foo'],
    [PROPERTY, 'color'],
    [VALUE, [ DYNAMIC, 0 ]],
    [DYNAMIC, 1],
  [RULE_END]
]

Then the specification also defines evaluation contexts something like:

function toCSS( rulesToSelectorsFn, ...dynamicFns ) {}

By default rulesToSelectorsFn could be rule => `._${rule}_${hash(rule)}` but that could be overridden... somehow. Dynamic interpolations would then just be referenced by their index into the dynamicFns array. When something like our babel transform generates this intermediate format, we wire up this array to make sure things are in the right order.

geelen · 2017-06-14T00:26:17Z

Might be good to get @philpl's thoughts here now too

kof · 2017-06-14T00:32:13Z

Definitely, I wanted just to cover basics first.

geelen · 2017-06-14T00:49:32Z

Then my only feedback is whether any rules should have any nested values (i.e. FUNCTION) at all. Would there be benefits to keeping everything flat? Could we collapse [SELECTOR, '.bla', [FUNCTION, ':matches', ':hover', ':active']] into simply [SELECTOR, '.bla:matches(:hover, :active)']? Alternatively:

[
  [RULE_START, 1],
    [COMPOUND_SELECTOR_START],
      [SELECTOR, '.foo'],
      [FUNCTION_SELECTOR, ':matches'],
        [SELECTOR, ':hover'],
        [SELECTOR, ':focus'],
      [FUNCTION_SELECTOR_END],
    [COMPOUND_SELECTOR_END],
    [PROPERTY, 'color'],
    [VALUE, 'red']
  [RULE_END]  
]

That way any SELECTOR could be a RULE and namespacing would apply.

geelen · 2017-06-14T00:50:34Z

readme.md

+    [PROPERTY, 'color'],
+    [VALUE, 'red'],
+    [RULE_START, 1],
+      [PARENT_SELECTOR, '.bar', '.baz', SPACE_COMBINATOR, '.bla'],


This could also be replaced with the idea of a COMPOUND_SELECTOR

kitten · 2017-06-15T11:42:32Z

By css flattener, I mean sth that potentially takes this css last and replaces nested rules with flattened ones. If nested rules will actually be parsed by a reference implementation? If not, it'll probably come down to a separate implementation that outputs this format/ast.

As to the second point: this is exactly what I'll start working on. One library which can preprocess and extract css bits in libraries like SC, glamorous and Glam.

kof · 2017-06-15T11:50:39Z

By css flattener, I mean sth that potentially takes this css last and replaces nested rules with flattened ones.

We got nesting into this spec already, meaning RULE_START can happen inside of another rule and to reference the parent selector we got PARENT_SELECTOR. Or maybe I don't quite understand what you mean and need an example.

As to the second point: this is exactly what I'll start working on. One library which can preprocessing and extract css bits in libraries like SC, glamorous and Glam.

Sounds great!

kitten · 2017-06-15T11:55:38Z

@kof that sounds like what I mean :) maybe I'll start with writing a minimal parser and we can think about a reference implementation later ;)

added COMPOUND_SELECTOR_START added COMPOUND_SELECTOR_END added COMPOUND_VALUE_START added COMPOUND_VALUE_END added FUNCTION_START added FUNCTION_END

kof · 2017-06-15T13:56:45Z

Spec updated: removed nesting, array tuples length are now max 2. So now we could actually apply further optimizations, please vote with thumbs up and down to the next comments.

kof · 2017-06-15T14:00:56Z

Should we go for single array? As consequence we will only be able to express this:

[MARKER]
[MARKER, value]

Right now it seems to work nicely.

[
  [RULE_START, 1],
    [SELECTOR, 'body'],
    [PROPERTY, 'color'],
    [VALUE, 'red'],
  [RULE_END]
]

will become

[
  RULE_START, 1,
    SELECTOR, 'body',
    PROPERTY, 'color',
    VALUE, 'red',
  RULE_END
]

kof · 2017-06-15T14:34:09Z

Should we go for all string values? Benchmark shows a considerable perf benefit in v8, if it is not flowed: https://esbench.com/bench/592d599e99634800a03483d8

[
  1, 1,
    2, 'body',
    3, 'color',
    4, 'red',
  5
]

will become

[
  '1', '1',
    '2', 'body',
    '3', 'color',
    '4', 'red',
  '5'
]

I am not sure if its worth it from the performance perspective (because only v8 and on micro level)
Tested storage savings, using 100kb probe it shrinks down to 80kb => 20%, not sure if its worth. Probe was [1,1,2,"body",3,"color",4,"red",5] => 1\n1\n\n2\n\nbody\n\n3\n\ncolor\n4\nred\n5
We will need a separate array for fn refs or any other refs

kof · 2017-06-15T15:17:06Z

Btw. we potentially have not only fn refs, but any other refs, objects, imported primitives, whatever. If static analyzer is not able to completely follow the import which might be also a result of a complex function invocation, we will need to inline the ref in place or push all refs into a separate array. Right now the only reason to maintain separate array is the perf benefit in v8 and 20% storage savings.

kitten · 2017-06-15T20:07:56Z

@kof the perf will likely not be worse in any other engine due to a homogeneous array. So I'd strongly advise it.

For the refs we can just create a bucket. Probably a WeakMap, where it's available? Since we know the type from the AST, we don't need to separate the map for separate types

kof · 2017-06-15T20:50:30Z

will likely not be worse

not worse, just no benefit

Probably a WeakMap, where it's available

I don't see how a WeakMap can be useful here.

kitten · 2017-06-15T20:52:43Z

@kof Yea, actually a normal Map would suffice, and a WeakMap might actually not be working correctly for our needs ^^" It was more of an example. The point is, we can create a bucket and hold all of our referenced values in there

kof · 2017-06-15T20:55:16Z

The point is, we can create a bucket

Don't know whats a bucket in js. I guess a refs array would do + position as a pointer in the main array.

But still not sure if its worth it vs. just referencing in place.

geelen · 2017-06-16T05:17:14Z

Yeah I wouldn't chase down perf ideas until we're sure this format can express everything it needs to. I think the idea that everything can be 2-tuples is useful because it's a design constraint that potentially speeds things up, but I'd just use nested, non-homogenous arrays to represent it. That way, if we find something that can't be done easily, we can go to 3-tuples or real references etc etc.

The performance criteria we should be judging this on is what's fastest to download + parse + convert into real CSS. 2-tuples might save us some branching in a tight loop, but it might require more structure as we're processing it. Potentially, there may be no need to deconstruct things into to [[PROPERTY, 'color'], [VALUE, 'red']], we could just store dumb strings like "color: red;". Maybe not, but it'll be much easier to understand the tradeoffs once we have one working implementation.

kof · 2017-06-16T08:09:44Z

we could just store dumb strings like "color: red;".

I think we need to deconstruct things heavily, otherwise you want be able to for e.g. vendor-prefix props/values upon consumption efficiently.

I was even thinking about deconstructing numeric values and its units.

kof · 2017-06-16T08:11:56Z

Btw. even in a flatten array we still can have longer than 2 value pairs, we basically can't have dynamic amount of members, but rather a statically predefined for a certain marker.

kof · 2017-06-16T08:19:51Z

Ok, lets flatten the format and try other optimizations like homogeneous array after we have one reference implementation and see what else is missing, I will create for them separate issues.

kof · 2017-06-16T08:58:15Z

I think we can merge this PR and create new one for the next things. Thumbs up?

kof · 2017-06-21T20:07:05Z

merged 🎉

kof mentioned this pull request May 30, 2017

Intermediate format #13

Closed

kof force-pushed the first-draft branch 4 times, most recently from 53e5f69 to d44662a Compare May 30, 2017 13:17

first draft

cc407e3

kof force-pushed the first-draft branch from d44662a to cc407e3 Compare May 30, 2017 13:41

tabatkins reviewed May 30, 2017

View reviewed changes

kof commented May 30, 2017

View reviewed changes

Updates based on feedback

7ab13e4

- No separate RULE_TYPE - NAME - REF=>PARENT_SELECTOR - SPACE

kof force-pushed the first-draft branch from e6c7c92 to 7ab13e4 Compare May 31, 2017 11:07

tabatkins reviewed May 31, 2017

View reviewed changes

kof added 6 commits June 3, 2017 13:14

add all combinators, NAME -> RULE_NAME

e1e5a96

fix selector list example, better structure, PARENT_SELECTOR can be u…

01c8eb8

…sed standalone now

functional pseudo selectors and values

df6c73e

wordking selectors list

b6a6c30

remove RULE_TYPE

2697017

better wording

2464877

kof force-pushed the first-draft branch from 26f8ecb to 206ce48 Compare June 3, 2017 12:16

selectors -> selector

69f9aa5

kof force-pushed the first-draft branch from 206ce48 to 69f9aa5 Compare June 3, 2017 12:20

geelen reviewed Jun 14, 2017

View reviewed changes

flattened, max 2-values tuples

4dfae65

added COMPOUND_SELECTOR_START added COMPOUND_SELECTOR_END added COMPOUND_VALUE_START added COMPOUND_VALUE_END added FUNCTION_START added FUNCTION_END

kof force-pushed the first-draft branch from 772147a to 4dfae65 Compare June 15, 2017 13:50

kitten mentioned this pull request Jun 15, 2017

Integration with typescript styled-components/babel-plugin-styled-components#41

Closed

This was referenced Jun 16, 2017

Classnames #14

Closed

Pseudo selectors #11

Closed

Nested styles #10

Closed

Global styles #9

Closed

Multi values #5

Closed

Fallbacks support #2

Closed

At rules support #1

Closed

kof merged commit 9be52bc into master Jun 21, 2017

geelen mentioned this pull request Jun 23, 2017

Optimization: a Stack/Heap approach #22

Open

kof deleted the first-draft branch July 1, 2017 11:44


		Selector compound e.g. `.foo.bar` => `[SELECTOR, '.foo', '.bar']`

		Multiple classes e.g. `.foo .bar` => `[SELECTOR, '.foo'], [SELECTOR, '.bar']`


		Denotes a selector or selector compound.

		Selector compound e.g. `.foo.bar` => `[SELECTOR, '.foo', '.bar']`

First draft #17

First draft #17

Conversation

kof commented May 30, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kof May 30, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kof May 30, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kof May 30, 2017 • edited Loading

Choose a reason for hiding this comment

kof commented May 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kof Jun 3, 2017 • edited Loading

Choose a reason for hiding this comment

kof commented Jun 3, 2017

kof commented Jun 6, 2017

kof commented Jun 8, 2017

geelen commented Jun 14, 2017

geelen commented Jun 14, 2017

kof commented Jun 14, 2017

geelen commented Jun 14, 2017

Choose a reason for hiding this comment

kitten commented Jun 15, 2017 • edited Loading

kof commented Jun 15, 2017

kitten commented Jun 15, 2017

kof commented Jun 15, 2017

kof commented Jun 15, 2017

kof commented Jun 15, 2017 • edited Loading

kof commented Jun 15, 2017 • edited Loading

kitten commented Jun 15, 2017

kof commented Jun 15, 2017 • edited Loading

kitten commented Jun 15, 2017

kof commented Jun 15, 2017 • edited Loading

geelen commented Jun 16, 2017

kof commented Jun 16, 2017

kof commented Jun 16, 2017 • edited Loading

kof commented Jun 16, 2017

kof commented Jun 16, 2017

kof commented Jun 21, 2017

kof May 30, 2017 •

edited

Loading

kof May 30, 2017 •

edited

Loading

kof May 30, 2017 •

edited

Loading

kof Jun 3, 2017 •

edited

Loading

kitten commented Jun 15, 2017 •

edited

Loading

kof commented Jun 15, 2017 •

edited

Loading

kof commented Jun 15, 2017 •

edited

Loading

kof commented Jun 15, 2017 •

edited

Loading

kof commented Jun 15, 2017 •

edited

Loading

kof commented Jun 16, 2017 •

edited

Loading