Change Details

OK, I think I'll directly create a task, because I don't believe that using `padding-bottom` for paragraphs was an informed decision. Context: T360917, T352875, T351754, etc. This task was partly inspired by T352875#9674743 by @Xover, in which they said: > Please don't use tricks like combining margin-top and padding-bottom. You're doing it to defeat margin collapsing, //which is how the CSS box model is supposed to work//. > for a project like Wikisource that actually needs to vary this stuff from page to page doing this just makes it feel like the skin is fighting us every step of the way. I can deal with the 7px (.5rem) top and bottom margin if it's consistent across Vector 2010/2022, but a completely different way to achieve the effect between the two, with different values, and in a way deliberately designed to defeat basic box model behaviour…? Now I just want to throw a complete style reset in MediaWiki:Common.css and call it a day. The whole idea behind using `margin`s, not `padding`s, for elements in text flow is that margins //[collapse](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_box_model/Mastering_margin_collapsing)//, i.e. the bottom margin of the upper element overlaps, partially or entirely, with the top margin of the lower element. This allows to have stable margins between whichever elements. E.g.: tables have `1em` margins while lists have `0.5em`. If you make them adjacent, table + list or list + table, tables will always have `1em` around them, not `1.5em` and not `0.5em`. There is simply no way you can ensure stable vertical margins in a text flow for elements of a certain type (which is how it's supposed to be designed), unless you either 1. use some incredibly dirty rule like `p + * { margin-top: 0.5em }`, which defeats the whole idea of fine-tuning margins in a way your design suggests; 2. or hardcode every possible combination of siblings, e.g. [p + ul](https://phabricator.wikimedia.org/T352875), [p + pre](https://phabricator.wikimedia.org/T358893), [p + blockquote](https://phabricator.wikimedia.org/T358921), p + table, and so on (we already have tasks for three of them, and there is no point in creating one for each of the rest). And even if you do any of that, you will be left with //nested// elements, which the margin collapsing mechanism also covers but padding does not, so you will have to add even more ad hoc rules like `p + div > table`, the potential number of which approaches infinity. And then there are //empty// elements, which the margin collapsing mechanism... If you decided to refrain from using simple `margin: 1em 0`, which would ensure even margins, then instead of using `padding-bottom: 0.5em` for `p` , you could [use a negative margin](https://phabricator.wikimedia.org/T352875#9424919) for the next sibling in exceptional cases, e.g. `p + ul, p + ol { margin-top: -0.5em }`, together with `:first-child` / `:last-child` pseudo-classes as required. Other options might exist which I'm unaware of. And I don't even mention the sheer volume of CSS readjustment that all wikis are now having to undergo, which was the central part of @Xover's rant and the subject of several tasks, many more to come.

OK, I think I'll directly create a task, because I don't believe that using `padding-bottom` for paragraphs was an informed decision. Context: T360917, T352875, T351754, etc. This task was partly inspired by T352875#9674743 by @Xover, in which they said: > Please don't use tricks like combining margin-top and padding-bottom. You're doing it to defeat margin collapsing, //which is how the CSS box model is supposed to work//. > for a project like Wikisource that actually needs to vary this stuff from page to page doing this just makes it feel like the skin is fighting us every step of the way. I can deal with the 7px (.5rem) top and bottom margin if it's consistent across Vector 2010/2022, but a completely different way to achieve the effect between the two, with different values, and in a way deliberately designed to defeat basic box model behaviour…? Now I just want to throw a complete style reset in MediaWiki:Common.css and call it a day. The whole idea behind using `margin`s, not `padding`s, for elements in text flow is that margins //[collapse](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_box_model/Mastering_margin_collapsing)//, i.e. the bottom margin of the upper element overlaps, partially or entirely, with the top margin of the lower element. This allows to have stable margins between whichever elements. E.g.: tables have `1em` margins while lists have `0.5em`. If you make them adjacent, table + list or list + table, tables will always have `1em` around them, not `1.5em` and not `0.5em`. With `padding`, there is simply no way you can ensure stable vertical margins in a text flow for elements of a certain type (which is how it's supposed to be designed), unless you either 1. use some incredibly dirty rule like `p + * { margin-top: 0.5em }`, which defeats the whole idea of fine-tuning margins in a way your design suggests; 2. or hardcode every possible combination of siblings, e.g. [p + ul](https://phabricator.wikimedia.org/T352875), [p + pre](https://phabricator.wikimedia.org/T358893), [p + blockquote](https://phabricator.wikimedia.org/T358921), p + table, and so on (we already have tasks for three of them, and there is no point in creating one for each of the rest). And even if you do any of that, you will be left with //nested// elements, which the margin collapsing mechanism also covers but padding does not, so you will have to add even more ad hoc rules like `p + div > table`, the potential number of which approaches infinity. And then there are //empty// elements, which the margin collapsing mechanism... If you decided to refrain from using simple `margin: 1em 0`, which would ensure even margins, then instead of using `padding-bottom: 0.5em` for `p` , you could [use a negative margin](https://phabricator.wikimedia.org/T352875#9424919) for the next sibling in exceptional cases, e.g. `p + ul, p + ol { margin-top: -0.5em }`, together with `:first-child` / `:last-child` pseudo-classes as required. Other options might exist which I'm unaware of. And I don't even mention the sheer volume of CSS readjustment that all wikis are now having to undergo, which was the central part of @Xover's rant and the subject of several tasks, many more to come.

OK, I think I'll directly create a task, because I don't believe that using `padding-bottom` for paragraphs was an informed decision. Context: T360917, T352875, T351754, etc. This task was partly inspired by T352875#9674743 by @Xover, in which they said: > Please don't use tricks like combining margin-top and padding-bottom. You're doing it to defeat margin collapsing, //which is how the CSS box model is supposed to work//. > for a project like Wikisource that actually needs to vary this stuff from page to page doing this just makes it feel like the skin is fighting us every step of the way. I can deal with the 7px (.5rem) top and bottom margin if it's consistent across Vector 2010/2022, but a completely different way to achieve the effect between the two, with different values, and in a way deliberately designed to defeat basic box model behaviour…? Now I just want to throw a complete style reset in MediaWiki:Common.css and call it a day. The whole idea behind using `margin`s, not `padding`s, for elements in text flow is that margins //[collapse](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_box_model/Mastering_margin_collapsing)//, i.e. the bottom margin of the upper element overlaps, partially or entirely, with the top margin of the lower element. This allows to have stable margins between whichever elements. E.g.: tables have `1em` margins while lists have `0.5em`. If you make them adjacent, table + list or list + table, tables will always have `1em` around them, not `1.5em` and not `0.5em`. TWith `padding`, there is simply no way you can ensure stable vertical margins in a text flow for elements of a certain type (which is how it's supposed to be designed), unless you either 1. use some incredibly dirty rule like `p + * { margin-top: 0.5em }`, which defeats the whole idea of fine-tuning margins in a way your design suggests; 2. or hardcode every possible combination of siblings, e.g. [p + ul](https://phabricator.wikimedia.org/T352875), [p + pre](https://phabricator.wikimedia.org/T358893), [p + blockquote](https://phabricator.wikimedia.org/T358921), p + table, and so on (we already have tasks for three of them, and there is no point in creating one for each of the rest). And even if you do any of that, you will be left with //nested// elements, which the margin collapsing mechanism also covers but padding does not, so you will have to add even more ad hoc rules like `p + div > table`, the potential number of which approaches infinity. And then there are //empty// elements, which the margin collapsing mechanism... If you decided to refrain from using simple `margin: 1em 0`, which would ensure even margins, then instead of using `padding-bottom: 0.5em` for `p` , you could [use a negative margin](https://phabricator.wikimedia.org/T352875#9424919) for the next sibling in exceptional cases, e.g. `p + ul, p + ol { margin-top: -0.5em }`, together with `:first-child` / `:last-child` pseudo-classes as required. Other options might exist which I'm unaware of. And I don't even mention the sheer volume of CSS readjustment that all wikis are now having to undergo, which was the central part of @Xover's rant and the subject of several tasks, many more to come.