On 2007-07-11, Jukka K. Korpela <> wrote:
> Scripsit Jonathan N. Little:
>
>> Neredbojias wrote:
> - -
>>>> form { display: inline; }
>>>
>>> One thing I'm not clear on. If that technique is utilized, can one
>>> still include a block-level <div> (for instance) within the form?
>
> It's not clear (at least by my reading of CSS specs) what should happen if
> an element with display: block appears inside an element with display:
> inline.
It is well-defined by CSS 2.1. See 9.2.1.1 "Anonymous block boxes"
When an inline box contains a block box, the inline box (and its
inline ancestors within the same line box) are broken around the
block. The line boxes before the break and after the break are
enclosed in anonymous boxes, and the block box becomes a sibling of
those anonymous boxes.
For example:
<span>hello <div>cruel</div> world</span>
generates three block boxes, the first and third of which are
"anonymous" (assuming default display: inline for span and display:
block for div):
-------------------------------
| hello |
-------------------------------
===============================
| cruel |
===============================
-------------------------------
| world |
-------------------------------
I've used === for normal block box borders and --- for anonymous block
box borders.
> Hence, I would avoid it and set display: inline for any block inside
> a form.
>
>> My understand a block level element must be between the form and the
>> form input elements
>>
>> <!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->
>
> That's by the HTML 4.01 Strict rules. Browsers don't really care whether you
> are Strict or not (though they may care about a doctype declaration where
> you _claim_ to be Strict), so what matters is whether you facturally have
> blocks inside a form.
It should also be pointed out that rules in the HTML DTD about %block
and %inline etc. and what you can nest inside what have nothing to do
with what's allowed in CSS.
Of course the HTML should be valid, or the browsers' parsers will do
strange and unpredictable things with it, but you can change display
from block to inline and vice-versa on any element without affecting
HTML validity.
CSS doesn't impose any kind of nesting restrictions (beyond stating that
certain properties in certain positions just don't apply). You can put
display: block inside display: inline if you want. You can even put
display: table-cell directly inside display: inline, and it's defined
what happens.
>> so you would need to add to the rule
>>
>> form, form * { display: inline; }
>
> Well, yes, that would take care of the issue in a sense, but I would rather
> use more specific selectors like
>
> form, form div, form p { display: inline; }
>
> Strange things _might_ happen in future browsers, when the default display:
> inline-block (for img, input, select etc., as per CSS specs) is changed to
> display: inline.
Is that expected to happen? I think img already is display: inline by
default.
> I don't know what might happen, but specifically for that reason, I
> would avoid creating the question.
There aren't many differences between inline-block and inline for leaf
boxes like buttons etc. Since there's no subtree of boxes inside such
elements, it mostly comes down to behaviour when you try to set width
and height. The rules are already different there for inline replaced to
inline non-replaced, and although there don't seem to be many rules for
things like buttons they are different again-- you can usually set the
width or height but browsers don't preserve aspect ratio, for example.
Similar Threads
