transform props

[bsima]

Note that this doesn't allow mixing unit types, even though it's allowed in the CSS spec:

*Clay Prelude> render $ transformOrigin [px 3, px 4, pct 50]

<interactive>:33:39: error:
    • Couldn't match type ‘Percentage’ with ‘LengthUnit’
      Expected type: Size LengthUnit
        Actual type: Size Percentage
    • In the expression: pct 50
      In the first argument of ‘transformOrigin’, namely
        ‘[px 3, px 4, pct 50]’
      In the second argument of ‘($)’, namely
        ‘transformOrigin [px 3, px 4, pct 50]’

Also not supported is top/left/bottom/right. I was not sure how to implement those things. If you have any ideas, please advise. Otherwise I'm not sure how important they are since the rest of the library works without them.

[turion]

Note that this doesn't allow mixing unit types, even though it's allowed in the CSS spec:

Yes, a similar problem arose before. That's too much restrictiveness in the Size type. We thought about adding a Size Any type construction which could be constructed from, well, any size. It can be implemented with GADTs. Could be an addition to this PR, or a separate one if you want ;)

[bsima]

Manuel Bärenz @.***> writes:

.code- +tags

What are these?

What are tags files? Pretty standard tooling https://en.wikipedia.org/wiki/Ctags#Tags_file_formats

I generate them in ghci with :etags or :ctags and then in emacs M-. or in vim Ctrl-] jumps to the definition

@@ -57,6 +60,38 @@ transforms xs = prefixed (browsers <> "transform") (noCommas xs)

---

+newtype TransformationStyle = TransformationStyle Value

Why not TransformStyle?

Because the other type in the file was Transformation but your suggestion sounds better I suppose

Ok I fixed that and realized I forgot to export some functions, then had to rename them to avoid clashing with Clay.Box

To github.com:bsima/clay.git

• 1681757...8f1ba0c transform-props -> transform-props (forced update)

[bsima]

Manuel Bärenz @.***> writes:

Note that this doesn't allow mixing unit types, even though it's allowed in the CSS spec:

Yes, a similar problem arose before. That's too much restrictiveness in the Size type. We thought about adding a Size Any type construction which could be constructed from, well, any size. It can be implemented with GADTs. Could be an addition to this PR, or a separate one if you want ;)

Definitely a separate PR, untangling that from the grid support PR will be a chore but I've got my eye on it.

[turion]

Because the other type in the file was Transformation but your suggestion sounds better I suppose

True. I like the convention of being close to the CSS names more, though. That's the direction we should go with new things in general.

[turion]

Thanks!