rolfen · October 31, 2017 09:37
diff --git a/css.whatswrong.txt b/css.whatswrong.txt
 - Side effects (usually unwanted)
 - Sometimes impractical: eg: vertical-align
 - Sometimes too high level / opinionated and inflexible (related to all of above)
 - Cascading - most of the inhertiance is unwanted
 - Global-variable-like issues
 - Overriding

 __Improvements

 I think it would be an important improvement, to be able to compound CSS blocks. A bit like less mixins, but at a native level. At the moment, if we are not using a pre-processor, we have to add multiple classes on elements (eg: <div class="col-2 pad-1 size-3">). That is neither powerful nor semantic.

 __What must change

 No more implicit styling (eg: A behaves different than DIV by default and nothing shows in the developer tools. Button elements cannot be made to behave like block elements).

 We need better, more "fine grained" control over relationships. For example an HR will take up the width of the parent container minus padding, by default. We need a way to specify that the HR would take up the width of a parent container, maybe twice or thrice removed further up in the hierarchy, or maybe even somewhere else in the DOM. And often we'd want the HR to take up the full width and ignore the padding.

 Nowadays this often forces the front-end developer to rewrite things, shuffle things around, use margins on several children instead of padding, for example. All valid, if not time consuming solutions. But it would be much better if we could have a better, finer, more advanced control of how elements interact with each other.

 Maybe all this logic should be taken out of the representation / CSS and be open for people to build their own solutions to manage relationships / inheritance / side effects / whatever.

 Maybe properties should be decoupled from their implementations/effects. So say padding:5px will only be a declaration of intent, then how it is applied, the effect, could be customized depending on the div. We could provide custom (JavaScript?) functions that define the effects of such a declaration.

 I am guessing this will bring the need of having multiple layers, encapsulation. For example if "we" "free up" the possibilty of defining "low-level" relationshiops, for example between a border and another far removed in the DOM, or even between one pixel and another, then we would want to build "layout systems" on top of that to manage abstract these fine-grained, "low-level" relationships - sort of like what functions or objects do in programming languages. By "layout systems" I mean things like "box model" and "flexbox layout model" that we now have in CSS.
 
 __What we want to keep:
 
 Separation of content and presentation.
 
 __Other:
 
 This is not a problem with CSS but rather with the whole DOM layout model. When an element's position changes, the change affects another element, which in change affects another element. It's like recursion. Can we avoid this? Can we sort of have the React paradigm, where everything is a function of the state - so if we change something in the state (a number somehwere) then the whole layout changes BUT the state does not otherwise change.

 Actually I'm not sure that we have this "recursion" problem in the DOM. Changing a CSS value will never change another value somewhere else. But it will change the result of properties such as clientTop. If we read these properties and create other changes based on them using JavaScript then we could run into this recursion problem.
	- Side effects (usually unwanted)
	- Sometimes impractical: eg: vertical-align
	- Sometimes too high level / opinionated and inflexible (related to all of above)
	- Cascading - most of the inhertiance is unwanted
	- Global-variable-like issues
	- Overriding

	__Improvements

	I think it would be an important improvement, to be able to compound CSS blocks. A bit like less mixins, but at a native level. At the moment, if we are not using a pre-processor, we have to add multiple classes on elements (eg: <div class="col-2 pad-1 size-3">). That is neither powerful nor semantic.

	__What must change

	No more implicit styling (eg: A behaves different than DIV by default and nothing shows in the developer tools. Button elements cannot be made to behave like block elements).

	We need better, more "fine grained" control over relationships. For example an HR will take up the width of the parent container minus padding, by default. We need a way to specify that the HR would take up the width of a parent container, maybe twice or thrice removed further up in the hierarchy, or maybe even somewhere else in the DOM. And often we'd want the HR to take up the full width and ignore the padding.

	Nowadays this often forces the front-end developer to rewrite things, shuffle things around, use margins on several children instead of padding, for example. All valid, if not time consuming solutions. But it would be much better if we could have a better, finer, more advanced control of how elements interact with each other.

	Maybe all this logic should be taken out of the representation / CSS and be open for people to build their own solutions to manage relationships / inheritance / side effects / whatever.

	Maybe properties should be decoupled from their implementations/effects. So say padding:5px will only be a declaration of intent, then how it is applied, the effect, could be customized depending on the div. We could provide custom (JavaScript?) functions that define the effects of such a declaration.

	I am guessing this will bring the need of having multiple layers, encapsulation. For example if "we" "free up" the possibilty of defining "low-level" relationshiops, for example between a border and another far removed in the DOM, or even between one pixel and another, then we would want to build "layout systems" on top of that to manage abstract these fine-grained, "low-level" relationships - sort of like what functions or objects do in programming languages. By "layout systems" I mean things like "box model" and "flexbox layout model" that we now have in CSS.

	__What we want to keep:

	Separation of content and presentation.

	__Other:

	This is not a problem with CSS but rather with the whole DOM layout model. When an element's position changes, the change affects another element, which in change affects another element. It's like recursion. Can we avoid this? Can we sort of have the React paradigm, where everything is a function of the state - so if we change something in the state (a number somehwere) then the whole layout changes BUT the state does not otherwise change.

	Actually I'm not sure that we have this "recursion" problem in the DOM. Changing a CSS value will never change another value somewhere else. But it will change the result of properties such as clientTop. If we read these properties and create other changes based on them using JavaScript then we could run into this recursion problem.