Morning webprutser, will check out the link
glad some of my ramblings are helping clarify some things,
It also makes me wonder what the essential difference - in function - is between block and inline elements. The way I looked at it, the only difference was the way they were displayed.
Now that's a wonder and a half, but if you can get the difference you'll be laughing :)
You have to get to grips with understanding what HTML is first, so forget about CSS display for a minute or 10, in simple terms a block LEVEL element is an element which can logically contain other BLOCK elements. The new wording/description in the HTML specs describes a lot of these elements as FLOW elements, so it's a lot more confusing to explain than it used to be, but I'll try
First you need
this bit [w3.org] or you'll be going round in circles all day
<!--================== HTML content models ===============================-->
<!--
HTML has two basic content models:
%inline; character level elements and text strings
%block; block-like elements e.g. paragraphs and lists
-->
<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
<!ENTITY % flow "%block; | %inline;">
it looks complicated but it's not really
- block and inline level - is is as per their descriptions.
- "<!ENTITY % block" actually spells out which elements or groups of element belong in the block content model
- "<!ENTITY % flow" is saying that Flow elements include both block and inline level elements
- anything not falling into the Block or Flow Entities will be an inline level element
Take the <p> element, it is a block level element, it belongs to the block content model, the <!ENTITY % block.. list tells us this, P is the first element listed in the group
That's a logical assumption anyway even if you didn't see this before, look at the description at the top of that section.. a <p> is not a "character level text string" it's a block of sentences, now looking at the <p>'s
definition in the specs [w3.org]:
<!ELEMENT P - O (%inline;)* -- paragraph -->
<!ATTLIST P
%attrs; -- %coreattrs, %i18n, %events --
>
we see (top line, after the O) that particular block level element can only contain inline elements... indeed in that same link a bit later it says quite clearly:
The P element represents a paragraph. It cannot contain block-level elements (including P itself).
this again is quite logical, if you're typing a paragraph in a WORD document you would not break it e.g. to put in a list.. you would end the paragraph (press enter, </p>) input a list then press enter (open <p>
) again to begin a new paragraph. The act of pressing "Enter" tells the WORD document to insert some whitespace.. it would be the equivalent of closing a </p> tag in HTML. In a written paragraph the only thing you likely want to insert without breaking lines is some highlighting or text, underlining or a reference (ref: this might equal a reference link in web terms). As expected all the previous things when translated to HTML elements are inline elements, span for the highlight, span or <u> for the underline and <a> for the reference/link
HTML is a markup language so it's best to think about as just that, not how it will eventually display.. you are expressing to the machine (browser) the context of the parts of your Document in a language it will understand
INLINE LEVEL elements are somewhat easier to understand they really can only contain other inline level elements you wouldn't think about nesting a <p> in an <em> element for instance would you?
A couple of elements that might help clarify how browsers interpret Markup..
<ul> [w3.org] is defined as UL - we can see from the content model quote above it belongs to the block level content model and it's defintion we are told it can
only contain <li> elements.. that's HTML101 but you do still see people getting confused over this and trying to put <h3>'s for example directly into a <ul> element without nesting it in an <li>
the <li> element (same link as the ul above) is defined as a LI - and it is a block too, it belongs in the %lists part of the HTML content model (again very top quote and link) according to it's definition it can contain
FLOW Elements, this means it can contain both "block and inline level" elements, i.e. any element in the normal flow - the fact that an <li> can contain other block level elements confirms that it belongs to the block level document model.
i.e. it's quite OK to have <li> elements contain <h>eadings and <p>aragraphs which again if you were writing a list makes perfect sense.
another element is the
<blockquote> [w3.org] it too belongs in the block level object model, per above, it is defined as blockquote,
only able to contain BLOCK level elements.. this one throws people at times as it will fail the validator if a one line "quote" is nested inside it without a wrapper block element.. if you think about it a one line quote is a <q> or <cite> both of which are inline level.. so when you are writing a blockquote you are usually separating a
block of text and that text could logically contain headings paragraphs and lists, it's name kind of gives a clue too ;) - So again if you were typing that WORD document you would break a paragraph (press enter).. insert the blockquote (press enter) and then reopen a new paragraph to continue
What catches people out with validating a blockquote, because they haven't wrapped the internal text in a relevant block element, is that BLOCKQUOTE is
almost a "non-element" it might be thought of, or abused as presentational by some, in order to get the indent (frequently is in wysiwyg/editor entered text - hmm like entering code in this forum ;)).. BUT in real terms <blockquote> serves exactly the same purpose in HTML as the <ul> or <ol> elements, which is to TELL THE BROWSER what that block of text is and to indicate a default presentational hint, the indent, to it.
To explain the validation, a blockquote must have it's internal content wrapped in <p> <div> <ul>, whatever really, as long as it's a
block level element, in other words the content inside it should be marked up as if the blockquote element were not there! The blockquote element itself is for browsers only, so they understand that it should be presented slightly differently BY DEFAULT, exactly the same way that it knows to apply bullets to an <ul> element or numbers to an <ol> by default, the li element by default knows it should have a bullet, but it's the parent <ul> or <ol> element that actually tells the browser which type to apply - blockquote is easier for the browsers, that tells them to indent everything inside it by default.
All the above is MARKUP - the communication between your document/page and the web browser, nothing to do with size of indent, paragraph spacing, etc.. i.e. not the styling
Now you're probably wondering what she's rambling on about eh.. ;)
The point of this little
deflection exercise here is to try and explain a little about HTML before getting to it's relationship with CSS, - I think what I'm hoping you can see is that INLINE and BLOCK
LEVEL elements are NOTHING to do with how the element should be
styled, yes not displayed but styled, and that the visual DEFAULT DISPLAY of browsers, of plain HTML, is no more than white space, where you would expect it, to keep a plain Text Document at least in some way legible
Plain HTML will produce a very basic Word processed like document, it knows to have carriage returns and a line feed where the <p> is closed.. If you know how to use a word processor you know you type your Document in plain text then when finished you can
go back and reformat headings, paragraph spacing, list indents, colors etc.. that's what CSS is to HTML, formatting beyond the basic output
to carry on the anomaly, in a Word Document if you want text side by side you can draw a text box, move it where you want, and then move a whole section of your existing document inside it, or a single image.. or whatever you're trying to place somewhere different.. that text box is a generic container, in other words in HTML it would be equivalent to a DIV ;)
You could of course format a Word Document using a table too, and if you did it would then be much clearer that you then have a lack of flexibility to move objects around.. this is just a theoretical reference as I'm sure that there's not a lot of seasoned Word Processor users who would choose to format a Word document this way, however the outcome of such a theoretical exercise would show exactly the same reasons why tales for layout are just plain wrong..
as an exercise you could try taking a tabular laid out page and remove any CSS or inline styles (old fashioned deprecated ones too), background images or indeed inline presentational only images.. now try reading that document in a browser.. what do you think?
OK you can start thinking about CSS again now :) What CSS does is to take the already existing correct, and valid markup and
suggest, within the browsers capabilities, an alternative way to display it. CSS has the ability to display an INLINE LEVEL element as a square/rectangular box (display: block;
) or indeed a BLOCK LEVEL element as inline text.. e.g. making an <h2> element display as "run-in" to the following <p>
the CSS
display property values [w3.org]:
inline | block | list-item | run-in | inline-block | table | inline-table | table-row-group | table-header-group | table-footer-group | table-row | table-column-group | table-column | table-cell | table-caption | none | inherit
are a way to tell the browser to display an element "like" it already knows how to display some other items by default
While some of the above values don't have full cross browser support, perhaps the easiest one to use as example is
display: list-item;
which simply tells the browser you would like whatever element to display like a <li> element with a bullet! If you have applied that CSS display value to a <p> for instance, it doesn't change the fact that the element is a paragraph it simply gives it a bullet, and if it wasn't already a block level element it would generate a block box around to make it look like a <li> element
as to why you want a bullet on a <p> I don't quite know but this a theoretical example to point out that if you did decide that you wanted a bullet or icon before a <p> because of your design, you wouldn't or shouldn't be thinking about that at the HTML stage, if it's to be a presentational change only .. leave the MARKUP alone and work the magic with CSS after the fact.
any clearer?..possibly not, it's a long time since I tried to explain HTML lol! but until you get the AHA moment, I think the best way to try this table to CSS conversion is to realise that you CAN & SHOULD MARKUP the page without thinking about the final look of it.. in your case, in fact anyone who is trying to wean off tables, you can do it a table CELL or ROW/section (header, footer) at a time as you do bits you will eventually see that the logic is always the same and it always, always hinges on the correct HTML in the first place ;)
OK off to look at your page now to see if we can help make this easier for you.. see you later
Suzy
