Skip to content

Bug: undefined style precedence when set more than once #17

@seanhess

Description

@seanhess

If a user sets a css style via a Mod, and then later changes it via another, the browser ends up choosing one effectively randomly. (It's following a bunch of arcane rules about CSS precedence. It chooses the most "specific", and then anything defined later, which in web-view usually means reverse alphebetized based on class name, but it depends on the order views are loaded).

This matters because users will try to create "base styles" and then compose changes to them.

Expected Behavior: This should render as a flex column.

el (flexCol . flexRow) ""

Actual Behavior: It renders as a row no matter which order the mods are used.

Possible fix:

We currently store Attributes as follows:

data Attributes c = Attributes
  { classes :: CSS
  , other :: Map Name AttValue
  }
  deriving (Show, Eq)

type CSS = Map Selector Class

data Class = Class
  { selector :: Selector
  , properties :: Styles
  }
  deriving (Show, Eq)

type Styles = Map Name StyleValue

The only current benefit of CSS being a Map intstead of a list is to prevent duplicates from being added. We could instead map each style property to a Class, and de-duplicate them on render. So, setting flexCol . flexRow would return in

-- when flexRow resolves
[("display", row), ("flex-direction", row)]

-- then later, when flexCol resolves, it replaces both
[("display", col), ("flex-direction", col)]

Then only the remaining classes would be rendered:

classesToRender :: Attributes c -> [Class]
classesToRender atts = nub $ Map.elems $ atts.classes

I'm not 100% sure this approach would work, but this has bothered me for a while.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions