View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 4185 | Composr alpha bug reports | General / Uncategorised | public | 2020-03-26 21:49 | 2022-08-31 18:36 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | major | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 4185: Dangerous CSS | ||||
| 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. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Sponsorship open | |||||
|
|
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 |
|
|
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> |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-03-26 21:49 | Chris Graham | New Issue | |
| 2020-03-26 21:49 | Chris Graham | Status | Not Assigned => Assigned |
| 2020-03-26 21:49 | Chris Graham | Assigned To | => user4127 |
| 2020-04-28 09:59 | Salman | Note Added: 0006514 | |
| 2020-04-29 00:51 | Chris Graham | Note Added: 0006521 | |
| 2020-04-29 01:01 | Chris Graham | Note Added: 0006522 | |
| 2022-08-15 01:41 | Chris Graham | Assigned To | user4127 => Chris Graham |
| 2022-08-31 18:36 | Chris Graham | Status | Assigned => Resolved |
| 2022-08-31 18:36 | Chris Graham | Resolution | open => fixed |
| 2023-02-26 18:29 | Chris Graham | Category | General => General / Uncategorised |
