- From: Jeremy Nicoll <jrnicoll@hotmail.com>
- Date: Thu, 07 Sep 2006 22:22:57 +0000
- To: www-style@w3.org
>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