Re: position / size arithmetic?

>From: David Woolley <david@djwhome.demon.co.uk>
>To: www-style@w3.org
>Subject: Re: position / size arithmetic?
>Date: Sat, 2 Sep 2006 18:31:35 +0100 (BST)
>
>
> >
> >
> > 3, but is there a way to do the following? Say I have a picture that is
> > 50px high, and I want it exactly centered horizontally.  I would like to
>
>margin-left:auto; margin-right:auto
>
>
> > 100% - 10px, where the border of the box is 5px.  This way one could
>
>Size is measured outside of the border, so I don't see that this case
>serves any useful purpose.

   Actually, the standard is that the INSIDE of the box is what determines 
the width - at least by the standard box model.  Most browsers in quirks 
mode will render it like you say, but in strict mode the inside of the box 
without padding and borders is what is considered the width of the box.  
Rather dumb, I think, but that's the case.

>
>Whenever you think you need px units, you should question very carefully
>whether you really do, as the use of such units tends to create
>device dependence and may suggest that text also needs to be an absolute
>size, which is an accessibility no-no.
   Here I am mostly concerned with placing images, and getting around the 
insane constraints of the standard box model (rather than the traditional 
box model which you had indicated).  I hate fixed font sizes and do 
everything I can to make the page scalable.  I often use the measuring unit 
EM in my sizes for this reason.  I know about setting the margins (even the 
shortctut : margin:  0 auto;) to place something in the middle, but it does 
absolutely nothing for making other calculations.  Again, this is mostly 
about placing images - and if the CSS3 spec is going to take care of the 
other problem, that is great by me.
    One of my main concerns in image placement is making a "rounded corners" 
box that does not break very easily and has code that is at least fairly 
easy to read.   If I could create images for the corners, and then create 
divs with repeating backgrounds (either repeat-x or repeat-y, respectively) 
with the measurement specifictions I want, this would make my life a lot 
easier.  The thing is that I can place the corner images just fine in CSS 
using absolute positions in a relatively positioned box, but the divs that 
are used to connect the corners overlap/underlap the corner images.  This is 
fine as long as the corner images are not transparent in any way - if there 
are transparent parts it gets really ugly.  If I could just specify that the 
height of the left div (which connects the NW and SW corners) by the 
following: 100% - 32px (the height of the images would be 16px), and then 
specify that the top of the div is supposed to be 16px from the parent 
element, this would much easier than the convuluted rounded corner stuff I 
see on the web.  The code is ugly and seems to break fairly easily.  For 
now, I just use tables because this is the only thing that I can think of to 
give me the flexibility that I need.  The code is much cleaner than the CSS 
in this example as well.   I could not imagine how this measuring system 
would encourage "fixed sizes" as it is using a dynamic size in the 
computation anyway.

>
> > ensure that the box (including borders) would be 100% of the containing
> > container.
>
>Calculated sizes have been  proposed on many occasions, and I believe
>they are already in the current CSS3 proposal, albeit, as a special
>function.
>The main concern tends to be to avoid getting anything like the power of
>scripting, with the associated security problems.
  I can see the point, however with simple computations like this I cannot 
see much of a security risk.  Browsers already make computations with 
current CSS specifications, and to say that you want something to be 30px 
more than 50% seems to be a very small extenstion of what they already do.  
Any  exploits would be the results of bugs in the code of the browsers, 
which unfortunately can be exploited regardless of whether the attack is in 
scripting language or in plain markup language.
>

Received on Thursday, 7 September 2006 22:23:08 UTC