i found that there is a rule regarding "pure space" directly inside a block element or directly inside an inline element. For the following example, in compliance strict mode: <body> <div> hello world </div> <div> <img src="pic.jpg"> <img src="pic.jpg"> </div> </body> HTML: there are tons of spaces after the first <div>, and they are the newline and space characters. But none is honored. None is rendered. (I think they are stored in the DOM tree, but it is just not rendered on the displayed, because they are directly inside a block element). Also between the two <div></div> ... <div></div> there are tons of spaces in the "..." region, but none is rendered. And the same goes for spaces before the first <img> tag and after the second <img> tag. (i tested using a body width of 300px, with two images of width 150px, and the spaces after the second <img> is not causing any vertical enlargement of div area if i set a visible border on the div. to see both images on the same line in this case, the <img> tags will need to be side by side, without any space or newline in between) So the rule is, any pure space directly inside a block element is ignored when the browser displays it, it would seem. Now, when the anonymous inline begins, such as in the case of "hello" and then "world", and in the case of the first <img> and the second one, since it begins an anonymous inline element, any pure space in between will be rendered. That goes for newline, indentation by tab or space characters, etc. And that's why we can freely indent the <div> with lots of spaces and newline without any side effect. This seems like the rule, applicable on IE7, Firefox 2, and Safari 3. This being the general rule it seems, does the spec actually say something about this?
does it say it is ignored? at least the white space inside the inline elements are not ignored... only the ones inside the block element and outside the inline element is totally ignored. the ones inside the inline is collapsed into 1 space usually in English. There is a line in the 4.01 spec: "This specification does not indicate the behavior, rendering or otherwise, of space characters other than those explicitly identified here as white space characters." so does that mean the spec doesn't say anything about the white spaces directly under the block elements, but all major modern browsers totally ignore it, including IE7, Firefox 2, and Safari 3.
All white-space between, or within block elements is ignored, unless it is part of the inline box created by inline elements or #PCDATA. All inline white spaces are collapsed to a single space character, 0x20. The specs require that an empty <p> element be ignored completely, and "strongly suggests" that other empty block elements be ignored. cheers, gary
Sorry, can't find the note. View the definition for p, though. http://www.w3.org/TR/html4/struct/text.html#h-9.3.1 Notice I overstated "should" as "must". cheers, gary
I thought that part of the spec says "empty paragraph should be ignored". but for the cases: <h1> hello world </h1> or <p> hello world </p> it doesn't say the spaces before the "hello" should be ignored...
It's also because of cdata behavior - see your OTHER thread on this topic for my 'response'. http://forums.digitalpoint.com/showthread.php?t=774556 Specifically though, the rules for cdata: http://www.w3.org/TR/html401/types.html#type-cdata Bottom line is that cdata is an attribute of it's surrounding tags - whitespace around attributes 'may' be ignored by user agents (I do dislike the wording), while other white-space characters in cdata is changed to spaces... Once it becomes spaces, THEN the rules for 'text' come into play condensing multiple spaces to single. It is one of the difficulties understanding the specifications when you start reading them - they use the term 'may' a lot to imply 'do' or 'should' - and a lot of times the behavior you are trying to understand might not be in the section about that element type, but in it's parent, it's parent parent, all the way up five or six 'inherits' of type - this is where backtracking in the DTD and understanding DTD nomenclature comes in handy.