Forum Moderators: not2easy
I am trying to create a div container with 4 spans set at 25% width, works fine until i put a border around the div then the final span places itself onto the next line.
Example with no border
<html>
<body>
<div style="width:400px">
<span style="width:25%;background-color:blue"></span>
<span style="width:25%;background-color:red"></span>
<span style="width:25%;background-color:yellow"></span>
<span style="width:25%;background-color:green"></span>
</div>
</body>
</html>
Example with border
<html>
<body>
<div style="width:400px;border:1px solid black">
<span style="width:25%;background-color:blue"></span>
<span style="width:25%;background-color:red"></span>
<span style="width:25%;background-color:yellow"></span>
<span style="width:25%;background-color:green"></span>
</div>
</body>
</html>
Can anyone see what I am doing wrong, I thought the 25% calculation would account for the pixel used either side of the div and then substract this when laying out the span tags each at 25%
TIA
-Gs
In your case, since you have set the width to 400px, you could do the math and use pixels for your widths instead of percentages.
An additional note, are spans the right element to use here? Spans are inline elements, and will react differently to css selectors than block elements. Perhaps a div or p would be a better choice, floated. (?)
First: get a full doctype, with nothing in front of it. That shoudl keep IE out of quirks mode.
Second: forget about developing CSS in IE: it will only set you on the wrong foot.
IE is e.g. bad at math. So develop it in a standards compliant browser and only when it's fully done look at it in legacy IE versions and fix what's wrong in a conditional comment.
In standards mode the box model is here: [w3.org...]
The width you set is the width of the content and e.g. borders go around it. So there would be no need to account for the border at all in calculating the 25%.
Note that you take a risk anyway: let's say I reduced the 400px to 399px, now instead of 25% being a nice round 100px, it comes to 99.75px. As browsers will render int on a pixel border (you'd hear howls of anti-aliasing kicking in if it didn't), the individual spans would still be 100px and not fit the 399px wide content of the parent.
Rounding errors, allow for them. (although with 400px and 25% there should be none (but like I said: IE is bad at math)
[edited by: swa66 at 2:38 pm (utc) on June 25, 2009]
I am trying to create a div container with 4 spans set at 25% width
I'm guessing you have set the SPAN elements to block-level since SPANs are, by default, inline-level elements, and 'width' values will have no effect.
Can anyone see what I am doing wrong, I thought the 25% calculation would account for the pixel used either side of the div and then substract this when laying out the span tags each at 25%
The W3C Box Model states that the dimensions of an element are calculated as 'width' value + padding + border - this theory is known as the 'content-box'. When this logic is applied to your example, it is calculated (from left-to-right) as 'border-left:1px' + 'width:25%' + 'border-right:1px'.
An alternative box model (which I personally feel is the more intuitive) is 'border-left:1px' - 'width:25%' - 'border-right:1px' - this model is known as the 'border-box'.
The current 'content-box' model means it can be complicated when it comes to calculating box dimensions (for some people at least). This becomes even tricky when you start to mix unit values (percentage and fixed).
Thanks
-gs
I have never had this issue myself, but it would seem logical to save the standardized doctype that you wish your documents to adhere to, to a local directory. As you say, you then add a relative path in your DTD to the local doctype.
It's more an indication of what you were coding for.
quirks mode is there to allow browsers to do a somewhat decent job with really old html code, if you code new and are using CSS etc. standards mode rendering is what you need, hence the (full) doctype to let browsers know you know the standards too.
It's an indication for what it should be validated against by validators.
TIP: do yourselves a favor and don't develop in IE. Esp not legacy IE versions like IE6 and IE7: they *will* put you on the wrong foot and they will make a very hard path for you to get it working in standards compliant browsers. The other way is far easier: develop in a standards compliant browser and then fix at the very end any issue IE has left.
It's a matter of keeping your sanity in many cases.
[edited by: swa66 at 12:45 pm (utc) on June 26, 2009]
Whilst the browser doesn't actually fetch the DTD file itself, AFAIK, it does have to analyse the public identifier within the DTD to understand how to interpet the document. This means Alternative Future should have no issues with running the application offline.
