You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
Actual Behavior: It renders as a row no matter which order the mods are used.
Possible fix:
We currently store Attributes as follows:
The only current benefit of
CSS
being aMap
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, settingflexCol . flexRow
would return inThen only the remaining classes would be rendered:
I'm not 100% sure this approach would work, but this has bothered me for a while.
The text was updated successfully, but these errors were encountered: