The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

P tags within unordered lists?

I can't remember the rules here - can I put a block element like a paragraph in an li? Or actually, now that I think about it, probably what would be better would be to use a definition list - which means I'd want to put my p tags in the dd tag.

What I'm wanting to do is create a kind of glossary. The dt tag would hold the type of item, and the dd would be the actual note about the item. The notes may have more than one paragraph, though, which is the reason for the question. If I can't use p tags, what's the best solution? A span that's styled like a p?

Thing is, watch out for stuff like <button>... it can have an inline as a parent, and a block as a child, but know that this:

<a href="#"><button><div>blahblahblah</div></button></a>

would be illegal because the inline a is still getting a block div as a descendant.

No, that's not illegal.
The button element type is a (replaced) inline element but it can have block-level children. In CSS terms you can think of it as an inline-block. And since button is inline and a valid child of an a, it doesn't matter what its content is (except that it can't be another a – since links aren't allowed to be nested and buttons aren't allowed to contain links – or a form, fieldset or form control).

It's quite like the object element type, which is also (replaced) inline and can have block-level children.

This says the button element requires opening and closing tags (the two hyphens), and may contain zero or more %inline or %block elements (the %flow entity), except that it may not contain an a, a %formctrl (form control), a form, or a fieldset.

Which simply repeats what Tommy said, using the word from on high.

cheers,

gary

Anyone can build a usable website. It takes a graphic
designer to make it slow, confusing, and painful to use.

except that it may not contain an a, a &#37;formctrl (form control), a form, or a fieldset.

That's right, and since it's expressed as an exclusion (after the content model and preceded by a minus sign) this applies for all descendants, not only immediate children. So you can't cheat and do <button><span><a>...</a></span></button>.

Originally Posted by Stomme poes

What I wish they would say (or do they, in some secret code?) is when an element is a BLOCK and when it is an INLINE (or something else). Instead, it states what they may contain.

Those aren't really HTML concepts; they are just something we often use to simplify things. You can look at the parameter entity declarations for %inline; and %block; in the DTD to get a good hint, as Gary said.

What we call inline elements can usually only contain text and other inline elements (button and object are exceptions to that rule). Block-level elements vary more: some can only contain other block-level elements (form, blockquote); others can only contain text and inline elements (p, address) and others can contain both (div, li). Since it's not semantically appropriate to block-level and inline elements on the same structural level, the latter should be read as 'either', rather than 'both'.

The important thing is what each element is allowed to contain, and that's what the DTD expresses. There's a slight learning curve, but once you've grasped how to read a DTD it tells you almost all you need to know. (There are some limitations that cannot be expressed in DTD syntax.)

Since it's not semantically appropriate to block-level and inline elements on the same structural level, the latter should be read as 'either', rather than 'both'.

I read in the specs that if block contains both inline and other blocks, that an anonymous block is generated around any loose (anonymous inlines) or inline (explicitly inline) content.
Should this be ignored re semantics?