Closed rksm closed 7 years ago
The motivation behind separating styleClasses
and morphClasses
is to distinguish between a property that is directly mapped to a CSS class and an entity, that is solely used within morphic.
StyleRules are a simplified CSS like styling mechanism that ensures consistency of morph properties among morphs by directly traversing them and setting their properties according to their name or assigned morphClasses. I wanted to avoid a property that is interpreted in two different (possibly conflicting) ways, which is why I decided to split them into styleClasses
and morphClasses
for now.
Hmm I can't think of a use case where a separation of those properties is needed. Also, why not at least re-use the class-based auto extension of styleClasses?
I would be fine with merging these two together then. Will push a change soon.
@merryman
Style rules commit 69031e6 introduced a property "morphClasses", a manually assigned list of names for assigning style rules to morphs.
What was the motivation behind that? Was there any reason to not use the existing styleClasses property?