Re: margins, ems and context

On 27/01/2011 09:13, Niels Matthijs wrote:
> On 26/01/2011 5:49 PM, Anton Prowse wrote:
>> On 26/01/2011 09:30, Niels Matthijs wrote:
>>> On 25/01/2011 7:08 PM, Anton Prowse wrote:
>>>> The example on your blog:
>>>>
>>>> "when you're playing around with headings and the left and rights
>>>> margins of the heading box keep changing every time you adapt the
>>>> font-size of this heading"
>>>>
>>>> makes me question why you've got horizontal margins on your heading in
>>>> the first place, or at least, why you're defining them in ems.
>>>>
>>>> Can you provide a use case, that is, not just an example of what
>>>> happens but also an explanation of why, specifically, you don't want
>>>> that to happen and why you want something else to happen instead.
>>>>
>>>> In particular, why would having those horizontal margins dependent on
>>>> the font size of the containing block be useful?
>>>>
>>>> Cheers,
>>>> Anton Prowse
>>>> http://dev.moonhenge.net
>>>
>>> Well, this is the use case I regularly run into. html first (not actual
>>> code, just a little abstraction of what I commonly write):
>>>
>>> [div class="whatever"]
>>> [h1]my header[/h1]
>>> [p]some paragraphs[/p]
>>> [ul]...[/ul]
>>> [div class="more"][<a href="#"]read more about whatever[/a][/div]
>>> [/div]
>>>
>>> for the css, I set my basic layout grid like this:
>>>
>>> .whatever>* {margin:0.75em 1em;}
>>
>> Why would you attach horizontal margin to all children of a block
>> instead of using horizontal padding on the block itself (which is
>> precisely what padding is intended for)?
>
> A fair question, which I once asked myself too. The result was a five
> part article:
> http://www.onderhond.com/blog/onderhond/margins-paddings-recap
>
> I assume what you're suggesting is the following:
> .whatever {padding:0em 1em;}
> .whatever>* {margin:1em 0em;}

(I wouldn't use the second rule set, but that's the gist of it.)


> With all due respect, I appreciate the help with css that's given here,
> but like others have pointed out before, that's not really the purpose
> of this mailing list. I think my example is simple and clean enough.

Apologies, I don't think I was very explicit in tying my analysis back 
to your original request.  In actual fact, I wasn't offering help!  I 
was challenging your use case.

You raised the fact that margins specified in ems are related to the 
font size of the element on which they are specified.  You felt that 
this was usually unwanted behaviour, and that instead you usually wanted 
such margins to be related to the font-size of the parent element.  You 
suggested introducing a new CSS property that would "switch" this 
relationship.

You provided a use case: in a container whose child boxes were offset 
from the container's border using horizontal margin, changing the 
font-size on the child boxes causes their em-specified margins to 
change, hence spoiling the columnar alignment.

I explained why I believed that use case to be invalid.  Your problem 
arises through the use of a technique which is different from another 
existing technique which would achieve the same effect (columnar 
alignment) whilst being more faithful to the design of the CSS language. 
  You pointed what what you felt were disadvantages of that latter 
technique:

> - the spacing of an element gets distributed over two different
> selectors, which hampers ease of maintenance
> - if (and it's not uncommon) you want a visual heading attached to the
> sides of the box you need to specify negative horizontal margins the
> same width as the horizontal paddings on its parent.  [And if the
> heading has a different font size from its parent then] calculating
> (and rounding) hell ensues

However, neither of those disadvantages lie at the language design 
level.  (For example, the first can be fixed using a CSS pre-processor, 
as can the second, partially; whilst rounding inaccuracy is an 
implementation-level limitation.)

Meanwhile, Alan Gresley raised other perceived disadvantages of the 
latter technique, providing a example to support his case.  I rejected 
his example since the perceived disadvantages arose because an 
inappropriate technique (a 100%-wide floated child) was being employed 
to achieve a visual effect which could be achieved in a different way 
more faithful to the design of the CSS language.

Hence it remains my option that the use case is not compelling.  I would 
not support the addition of a new CSS property (which is a expensive 
operation on the language design) on the back of that use case.  It may 
be that there are other use cases which can demonstrate the value of 
such a property; I would be interested in seeing them!

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Thursday, 27 January 2011 20:09:05 UTC