#4185 - Dangerous CSS

By Chris Graham
Added 26th Mar 2020, 5:49 PM
4 views

Identifier	#4185
Issue type	Major issue (breaks an entire feature)
Title	Dangerous CSS
Status	Completed
Handling member	Chris Graham
Addon	General / Uncategorised
Description	I just found this is in the CSS... , ::before, *::after { box-sizing: border-box; } This essentially means that any non-trivial third-party HTML cannot be pasted into the WYSIWYG, templates, Comcode pages, etc, because it breaks a basic assumption of how default CSS layout is going to work. At the very least we need to discuss this.
Steps to reproduce
Funded?	No

The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".

Rating

Unrated

Comments

By Guest posted 28th Apr 2020, 5:59 AM

I agree it's too aggressive but the browser default box sizing model is an absolute pain, so `* { box-sizing: border-box }` has been widely adopted by front-end developers and major CSS frameworks like Bootstrap.

Some front-end experts recommend the following [1]:
/* apply a natural box layout model to all elements, but allowing components to change */
html {
box-sizing: border-box;
}
*, *:before, *:after {
box-sizing: inherit;
}

WordPress' default theme also do this[2]. So we can revert to default box-sizing on parent elements containing third party HTML. Is that a good enough middle ground?

Otherwise we are left with removing the wildcard approach and applying border-box on a case by case basis. :( Which will also involve modifying all my new v11 CSS which assumes border-box.

1: https://www.paulirish.com/2012/box-sizing-border-box-ftw/
2: https://github.com/WordPress/WordPress/blob/master/wp-content/themes/twentytwenty/style.css#L147

By Guest posted 28th Apr 2020, 8:51 PM

That inherit improvement is bone-headed. It adds CSS complexity to provide the ability to isolate a hierarchy without needing '!important' -- but the side-effect of that is any custom HTML is going to get everything inherited each time it sets it's own value.

E.g. it would break anything that tries to use both box sizing models...

<div style="box-sizing: border-box; width: 100%; padding: 10%>
<div style="width: 80%; padding: 10%">Hello</div>
</div>

By Guest posted 28th Apr 2020, 9:01 PM

So here's my view...

I have no disagreement that the original CSS box model is stupid, but it's the aggressiveness that bothers me.
We'll justify your rule under the basis of avoiding having to litter CSS with box-sizing declarations in order to gain the simple ability to mix percentages and px padding/margin.

However, implement and test so you can undo it with...

*:not(.trad-box-model, .trad-box-model *),
*:not(.trad-box-model, .trad-box-model *)::before,
*:not(.trad-box-model, .trad-box-model *)::after {
box-sizing: border-box;
}

The idea being anything under a ".trad-box-model" selector wouldn't have the styling applied.

Hopefully it doesn't hurt performance much?

Tweak my suggestion and link to the commit if you want/need to tune this.

Also look into this...
input[type="radio"],
input[type="checkbox"] {
box-sizing: border-box;
padding: 0;
}
Because that seems to be not needing "box-sizing: border-box;" given your global rule.