lukesutton / uut Goto Github PK

There are two ways we could define media queries. One is a media query block that wraps a bunch of styles. The other is defining media queries inline in a block then extracting them. They could also be hoisted out and grouped together ala SASS.

A bit more complicated than other properties, since the syntax for specifying the shadows can be a bit involved.

Coverage of media queries is only partial at this point. We need to go over what's missing and add them. Pretty straight forward.

I'm probably not going to make the worlds-most-complete test suite for the 1.0 release, but it's prudent to do at least some testing. Already I've turned up and fixed some issues because of tests, so 👍

It's likely they may need to use something clever like generics to work. Existing property values could be extended to take a CSSVariable, but for type safety, we need to make sure invalid types can't be provided.

This is a bit of a mystery, since there is a lot of ambiguity around how to write and process Swift documentation. There is the Apple way, which formats nicely in Xcode, but then there are other approaches as well.

• Investigate documentation formats and tooling
• Test some out
• DOCUMENT!

Properties are made available in different CSS specs. It might be useful to be able to inspect a collection of styles and see what the CSS level is i.e. is it purely CSS-2. This could be done via types, perhaps something as simple as making the property structs extend a protocol e.g. extension Properties.FontSize: CSS1 {}

Support for this is mostly gated behind vendor-specific prefixes, so this requires investigating methods for outputting different levels of browser support. Currently we only output what the spec dictates.

Firstly, having styles and properties being responsible for their own compilation is a bit messy. Secondly, it's inflexible, since it makes it difficult to do additional processing. Instead we should step back from this and just set a few rules for the base styles and properties.

• Declarative; just a bunch of nested value-types
• Well-typed e.g. only use String where the input is actually a string
• Canonical; only use property names and values per the specs, nothing browser specific

Compilation is then abstracted away and can be implemented in different ways. It would be relatively easy to make an architecture that is pluggable, where middleware functions can provide intermediate steps. A rough sketch:

1. Map over styles, flattening out children and modifiers
2. Optionally apply middleware that operate on the collection of flattened styles
3. Compile to string
4. Process string e.g. minification

The types for each step are:

1. [Style] -> [Style]
2. [Style] -> [Style]
3. [Style] -> String
4. String -> String

Processing could be made even richer if middleware received an intermediate-representation rather than the standard styles. Processors would then need less knowledge of the style-types, just the IR.

The types in that case could be:

1. [Style] -> [IRStyle]
2. [IRStyle] -> [IRStyle]
3. [IRStyle] -> String
4. String -> String

This is a maybe, since it is more work and does mean losing the type information available in the Style type.

We don't have any of these at all.