Forum Moderators: not2easy
I still use my handy little utility written for a local sidebar (or bookmark) which tells me; which element is which, should I have the need to check. When I recently had cause to go look for the "proof" I found it's not quite so easy for a newcomer to HTML to find this out
So to the HTML specs we go and I find that even delving into the specs it's still not obvious unless you follow the trail back the way. Then the "%flow",1 element description pops up, and I think what's a flow element then?, and why do I never hear about that when it comes to validation? I mean I know you can't nest a block level element inside an inline one, or can you.. and how does all that fit together with CSS display: block and display: inline;?
I never ever really thought about it I just knew, and applied common sense.. a few years back there was a discussion about why the blockquote element didn't validate if it simply had some inline text in it, [ref lost].. to me it just made sense, long before I even got hooked on CSS or had even started understanding the HTML or CSS specs.
Then more recently the same issue/question arose again, only this time it concerned the <form> element reference
It was only when looking to try and explain this, at least in a more "this is why" kind of way, that I realised how blinking hard it is to explain even the HTML basics.
So; it turns out that although it's generally OK to say a block level element can contain other block level and also inline level elements, and that an inline element can only contain other inline elements, it's not always true.. are you surprised?
To try and take a simple example, you might think that the body element can contain anything. I mean the body element exists and you can put anything on your page, right?
The <body> element is a, possibly THE, most natural block level element. But no it's not OK (for validating code and any subsequent CSS application) to directly nest an <img> element directly inside the <body> element, or to directly nest any other inline element in the body for that matter
The <body> element can only contain other block level elements or script elements (or ins/del - but they are anomaly unto themselves and can be either block or inline ... don't ask yet!**)
The paragraph <p> element and the <hn> elements are considered block level elements, they break lines before and after themselves, but they cannot contain other block level elements. It makes sense in one way; if you were reading a "paragraph" element you would take a breath (i.e. break the line) before reeling off that list, <ul>/<ol>.. yes/no?
so is there a rule of thumb?
I'm afraid not, or not one that I've seen explained perfectly clearly (do tell if you have a source), those "warnings" you get from the validator are your best guide and they will keep happening unless you just know and/or apply some thought, or trackback the specs
CSS - {display: inline;} or {display: block;}
Then let's add in the CSS, even after you get to grips with the basics of HTML, some think it's OK to change the nature of the element using the display: property via the CSS
e.g. let's make a link, (anchor), the <a> element into a block level element.. so we can write into our CSS:
a {display: block;}
sure enough that makes the link into a block (it has a break before and after it) So can we now nest a table inside it in order to make the table clickable?.. sorry no!
It might look and render OK in a few UA's but don't expect the CSS to work x-browser (and dont expect the hack backs which might make something work that shouldn't!). Why should the link expand to actually surround the table element; there is no guideline in either the HTML or CSS specs which says it should, in fact we just need to go back to basics in the HTML spec to see that the table (or any other block) shouldn't be there in the first place.
The display property, in the true spirit of CSS does not alter anything about the element - EXCEPT its suggested appearance.
So why doesn't the <a> element(tag) expand to include the whole table, if you've told the link to display as a block?
., gain it's not too hard really, the <a> is still actually an inline element and therefore won't accept height as a value, yes it'll do the break lines thing but if something inside it i.e. that <table> (which renders after the fact) tries to forcefeed it a height what should it do? - gain a height or overflow
An inline level element does not accept the height attribute whether applied as an attribute or via CSS! , so I'd say overflow is, and has to be, the "degrade nicely" fallback
If you were a UA trying to interpret the specs what would you do.. me, well I'd fall back on the basics and the basics say no block element inside an inline one so all I have to do is degrade gracefully, follow the rules and not give that <a> anything but a line-height, and let the table overflow.. I don't have to pass no ACID test ;)
Once the table overflows it's possible that it will only be "clickable" within the actual line-height of the <A> area, but that's all I as a render agent had to do.. I wasd instructed to make the inline <a> element clickable (not the table inside it).
If some are wondering why something still doesn't quite work cross browser, when it's works like they want in {insert favourite browser}. It's more than likely back to the fact that the specs are not a manual; they are a RECOMMENDATION. The UA's are free to interpret them, as best they can, so their parsers can parse it as best they can
I have never, but should've, said; I always respected that - it's not until you actually go there with the specs (not that everyone need to) that you get a VERY SMALL glimpse of what a render engine has to cope with
Conclusion:
If you want the CSS to work, it's best if you have valid HTML to start with.
KUDOS to the UA's so far
I still use my handy little utility written for a local sidebar (or bookmark) which tells me
I assume you are referring to the old/original Netscape sidebar HTML quick reference tool? I use that all the time too!
thinking back I remember having thought why can't an inline element, say e.g. a <strong>, be nested inside a blockquote (block level element )and have it still validate.. 'twas more a random thought than a right or wrong thing I suppose
..and I also suppose, (thanks to those who responded privately) Yes the conclusion that it's Kudos to the UA's AND the W3C that so much thought has gone into implementing it logically as opposed to how people wanted it that is going to take this into the future...
If you want the CSS to work, it's best if you have valid HTML to start with.
KUDOS to the UA's so far
I don't know about anyone else but I've found the distinction between block and inline level elements to be largely unexplained, and something that is just 'known' as far as HTML goes anyway.
A model of understanding - for comment
Isn’t understanding assisted by thinking in terms of the print origins of html? (And I don’t think the recommendations should explain this, although I’m not sure where responsibility falls.)
The <body> element is a, possibly THE, most natural block level element. ...[clipped]
Descendants of body
For me the relevant elements all have a print application that makes it logical for them to be direct descendants of body. However, this thread prompted me to check the recommendations for whether they also all have default "styling" that reflects print composition conventions as well. To me it seems the html inventors provided for elements allowed to be descendants of body (and therefore able to be inserted without regard for composition) by providing a sort of “automated” page composition/layout as well. And that supports viewing the body as defining the composition area rather than acting as a container.
Except ins/del: I couldn’t validate html strict with them as descendants of body, despite it making sense on the print analogy as it may be necessary to signal the status of a whole "page". More confusingly my favourite source for this information is blooberry who gives body as the parent of ins/del as well. That's you, he, and the w3 - any suggestions (aside from a conspiracy) why I can't validate?
The paragraph <up> element and the <hen> elements are considered block level elements, .... It makes sense in one way; ... you would take a breath ... before reeling off that list, ... yes/no? ... and how does all that fit together with CSS display: block and display: inline;?
It also makes sense in terms of the print model. I think confusion arises when the descriptive/structural quality of the element is ignored and the css display type is considered without reference to the parent and content model. Hence "surprise" when (eg) a list cannot be placed inside a paragraph. That is, assuming that css display:block means p should be treated as a "container", not a paragraph, and as a container should hold further block elements - despite p actually having an inline content model consistent with the behaviour of a paragraph in the print context.
inline elements and body
I think this also explains expectations to place inline elements directly into body: CSS display:block means body is perceived as a container - when this could be avoided by treating it as identifying the area available to compose/layout the elements of your page.
In print, letters do not exist alone, but are grouped into headings, para's, etc. which can be a child of body Inline elements like <i> and <b> never exist in isolation because their print role is to signal the contained text differs from the material surrounding it - like <i> used to indicate a phrase from a different language. On the print analogy allowing inline elements to be inserted directly (and so in isolation) into body would be a redundancy.
On images, traditionally, expense wasn't wasted on an image that didn't relate to, and inform, the text or data, etc. So if an image relates to some element already on the page, again, no requirement for it to be able to be placed in isolation directly into body.
display:inline also avoids the down-side of images as replaced elements, with optional width and height. That allows huge opportunity for styling. (How could the authors of html have foreseen css2? Better, design a system, that might be imperfect, but could support these developments? Whew!), but it does leave the img without an identifiable containing box (or dimensions) until the measurements are computed. Requiring an image to be placed inside a block level element gives the UA some chance of figuring where to start drawing it – which relates its print use to the print media's inability to adjust “”on the fly”.
blockquote
My texts on formal writing tell me quotes should be spaced and indented away from the main body of text with the source clearly identified. That makes display:block logical (and the cite attribute), but identifying a section of material for recognition as not your original thought is not the same as describing/structuring the material being quoted. As that could be a table to several pages of text, it needs to be marked up as well. With the result that bare text cannot be placed directly inside a blockquote and a blockquote can be placed directly into body. On the print analogy, blockquotes seem very sensible elements ;)
It was only when looking to try and explain this, at least in a more "this is why" kind of way, that I realised how blinking hard it is to explain even the HTML basics.
For visual users, if the display, parent and content models correlate with what we know about the element from print, then remembering and implementing should get easier. And that should help resolve issues created when changing css display, or modifying the document flow.
Of course, it's not quite that straight forward, and I'm not sure how much this helps coders who read in languages with different print conventions.
