Menu list broken by form button

P

Paul Furman

I've got a nav menu that's css formatted to run across the top:

[home about view cart]

When I want to make one of the links a button, the formatting is broken,
causing a double page break from code like this:

<li>
home
</li>
<li>
<form ...
about
</form>
</li>
<li>
view cart
</li>

so it looks like this:

[home
about
view cart]

Any simple way to fix this?
 
J

Jukka K. Korpela

Scripsit Paul Furman:
I've got a nav menu that's css formatted to run across the top:

What's the URL?
When I want to make one of the links a button, the formatting is
broken, causing a double page break from code like this:

Well, then just stop wanting that. Turning links to buttons is a bad idea
anyway; see http://www.cs.tut.fi/~jkorpela/www/links.html
for a detailed explanation, or consider just a few of the reasons:
1) Does Google treat the button as a link?
2) Can the user middle-click on the button to open the linked resource in a
new tab, as he can do with real links?
3) Does the button automatically change color after visiting the linked
resource?

"Doctor, it hurts when I do this!"
"Then don't do that."
<li>
<form ...
about
</form>
</li>

A form is a block-level element by default. Thus, it will be rendered with
line breaks before and after. You could prevent this with

form { display: inline; }
 
D

dorayme

"Jukka K. Korpela said:
"Doctor, it hurts when I do this!"
"Then don't do that."

I hope the OP does not think of this like:

"Doctor, my leg hurts".
"So, limp".
 
N

Neredbojias

Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 05:30:45
GMT Jukka K. Korpela scribed:
A form is a block-level element by default. Thus, it will be rendered
with line breaks before and after. You could prevent this with

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?
 
B

Ben C

Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 05:30:45
GMT Jukka K. Korpela scribed:


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?

You can, but it will result in "line-breaks", or more technically
anonymous blocks around the inline things either side of the block-level
div.

Try it, and it will be obvious what I'm talking about.

Now if you made form { display: inline-block; } on the other hand, then
in a browser that supported that, the form could contain a block-level
div but still share a line with its inline siblings.
 
J

Jonathan N. Little

Neredbojias said:
Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 05:30:45
GMT Jukka K. Korpela scribed:


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?

My understand a block level element must be between the form and the
form input elements

<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->

so you would need to add to the rule

form, form * { display: inline; }
 
J

Jukka K. Korpela

Scripsit Jonathan N. Little:
Neredbojias wrote: - -

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. 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.
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. I don't know what might happen, but specifically for that
reason, I would avoid creating the question.
 
N

Neredbojias

Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 09:15:32
GMT Ben C scribed:
You can, but it will result in "line-breaks", or more technically
anonymous blocks around the inline things either side of the
block-level div.

Try it, and it will be obvious what I'm talking about.

I think I see what you're saying - but will try it, anyway, to, uh, see
better.
Now if you made form { display: inline-block; } on the other hand,
then in a browser that supported that, the form could contain a
block-level div but still share a line with its inline siblings.

Yes. I've tested that extensively in Opera, where it works great.
Unfortunately, it doesn't work in Firefox or ie6. Someone said it worked
in ie7, but until Mozilla gets on the stick, I see no point in pursuing the
issue.
 
N

Neredbojias

Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 12:24:28
GMT Jonathan N. Little scribed:
My understand a block level element must be between the form and the
form input elements

<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->

so you would need to add to the rule

form, form * { display: inline; }

Which would remove some of the desired benefits of "block" from within the
form. Hmm, your answer differs from Ben C's somewhat. How about a div in
a div, the outer div being styled to inline? Something like that is what I
am really questioning in the first place.
 
B

Ben C

Scripsit Jonathan N. Little:


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.


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.
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.
 
J

Jukka K. Korpela

Scripsit Ben C:
It is well-defined by CSS 2.1. See 9.2.1.1 "Anonymous block boxes"

OK, thanks.
Is that expected to happen? I think img already is display: inline by
default.

According to the sample style sheet for HTML in the CSS 2.1 draft, img has
display: inline-block. The sample style sheet is not normative, but what
else could we use here to make our guess?
 
N

Neredbojias

Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 21:14:44
GMT Ben C scribed:
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):

Okay, I think I get it. That's what was happening when I tried similar
experimentally. Didn't really expect it to be valid. Thanks, all, for
the help.
 
B

Ben C

Scripsit Ben C: [...]
Is that expected to happen? I think img already is display: inline by
default.

According to the sample style sheet for HTML in the CSS 2.1 draft, img has
display: inline-block. The sample style sheet is not normative, but what
else could we use here to make our guess?

I don't see where that is. This is the default stylesheet I'm looking
at: http://www.w3.org/TR/CSS21/sample.html.

It has

button, textarea,
input, select { display: inline-block }

but nothing about img, which therefore gets the default display: inline.
 
J

Jukka K. Korpela

Scripsit Ben C:
I don't see where that is.

D'Oh! I can't trust even my own books, it seems. Well, I wrote it in 2003,
and they changed the CSS 2.1 draft late that year. In the version
http://www.w3.org/TR/2003/WD-CSS21-20030128/sample.html
they still had img { display: inline-block; }.

All those changes to the "sample style sheet" reflect the fact that it's
just an eclectic collection of observed browser practices, nice ideas, and
weird ideas. But it may have become somewhat better through years.

Anyway, although img was not a good example, input elements and other form
fields still have display: inline-block. And my point was that
form * { display: inline; }
was unsafe since it applies to _all_ elements inside a form.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,831
Latest member
HealthSmartketoReviews

Latest Threads

Top