:visited can only be applied via CSS selectors, not inline.
- CO-02: Composition errors based on attribute values aren't checkable at compile time.
- CO-03: The type-system of Scala compiler must be leveraged as much as possible.
- CO-04: Where a style is referenced or applied, the dev shall be able to navigate to its definition in a single action in IntelliJ/Eclipse.
- CO-05: Solution shall not impose compliance to the CSS spec. (ie. it shall not prevent CSS hacks.)
- CO-06: Browsers cascade styles (even inline styles) to children and there is nothing we can do about it.
- FR-01: Dev shall be able to define a style that requires a specific configuration of children such that the compiler will enforce that the children are styled.
- FR-02: Dev shall be able to define a style that depends on required input. (ie. a function)
- FR-03: Dev shall be able to define a style that depends on browser/page state (eg.
- FR-04: Dev shall be able to define a style that depends on the current plaform (eg. IE 8, mobile)
- FR-07: Dev shall be able to define custom CSS attributes.
- FR-17: Dev shall be able to define a style that affects unspecified, optionally existant children. (Must like & in LESS. Required for FR-15.)
- FR-20: For styles that require repeated declaration with different keys (eg
-moz-), Dev shall be able to specify the style and its variants with a single declaration.
- FR-21: Dev shall be able to create a group of styles that can be included into an external project's styles in Ω(1) LoC.
- FR-05: Dev shall be able to compose styles to form a new style.
- FR-06: Dev shall be able to define a style that extends an existing style.
- FR-10: Dev shall be able to specify a composition strategy when merging styles.
- FR-11: Solution shall provide a composition stategy that prevents composition.
- FR-12: Solution shall provide a composition stategy that overrides (i.e. discards one side and chooses the other).
- FR-13: Dev shall be able to create a composition stategy that merges attribute values.
- FR-14: Dev shall be able to specify different composition strategies per attribute type. (i.e.
- FR-18: When looking at a style definition, Dev shall be able to passively understand if any attributes are being overridden.
- FR-19: When looking at a style definition, Dev shall be able to passively understand which attributes are being overridden. [pri=low]
- FR-08: Scalac shall prevent compilation without proof that a referenced style exists.
- FR-09: Scalac shall prevent compilation without proof that attributes used in a style are either part of the CSS spec or custom as per FR-7.
- FR-15: Dev shall be able to apply a baseline style (a “css reset”) to a whole page.
- FR-16: Solution shall provide one or more “css resets” that devs can override to customise, then apply to their whole page. [pri=low]
- PR-01: It would be better not to push psuedo-selector logic upon devs and have them write code for what the browser already does.
- PR-02: It would be nice to edit a logical style in the browser directly. If styles are inline then one can only modify a single tag's style at a time.
- PR-03: Solution should not require scalajs-react. scalajs-react should depend on Solution with provide a small bridge.
- PR-04: When generating CSS, if the target platform is known, Solution should omit unapplicable platform-specific CSS (FR-20).
- QR-01: A page of 1000 DOM elements with 400 different styles, 20% of elements having 3 styles, 10% having 5, should render in ≤ 2 sec.
- QR-02: The time between changing the styles in Scala, and seeing the result in the browser should be ideally ≤ 3 sec.