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:
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."
>
In article
"Jukka K. Korpela"
> "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".
--
dorayme
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
On 2007-07-11, Neredbojias Neredbojias wrote: Scripsit Jonathan N. Little: Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 09:15:32 Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 12:24:28 On 2007-07-11, Jukka K. Korpela Scripsit Ben C: Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 21:14:44 On 2007-07-11, Jukka K. Korpela Scripsit Ben C:
> 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 (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.
Re: Menu list broken by form button
am 11.07.2007 14:24:28 von lws4art
> 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 (for instance) within the form?
>
My understand a block level element must be between the form and the
form input elements
so you would need to add to the rule
form, form * { display: inline; }
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Re: Menu list broken by form button
am 11.07.2007 19:58:33 von jkorpela
> Neredbojias wrote:
- -
>>> form { display: inline; }
>>
>> One thing I'm not clear on. If that technique is utilized, can one
>> still include a block-level (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. 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
>
>
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.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
Re: Menu list broken by form button
am 11.07.2007 20:13:32 von Neredbojias
GMT Ben C scribed:
>>> form { display: inline; }
>>
>> One thing I'm not clear on. If that technique is utilized, can one
>> still include a block-level (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.
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.
--
Neredbojias
A self-made man who worships his creator
Re: Menu list broken by form button
am 11.07.2007 20:17:02 von Neredbojias
GMT Jonathan N. Little scribed:
>>> form { display: inline; }
>>
>> One thing I'm not clear on. If that technique is utilized, can one
>> still include a block-level (for instance) within the form?
>>
>
> My understand a block level element must be between the form and the
> form input elements
>
>
>
> 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.
--
Neredbojias
A self-made man who worships his creator
Re: Menu list broken by form button
am 11.07.2007 23:14:44 von Ben C
> 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 (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:
hello cruel world
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
>>
>>
>
> 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.
Re: Menu list broken by form button
am 12.07.2007 00:56:10 von jkorpela
>> 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"
OK, thanks.
>> 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.
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?
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/Re: Menu list broken by form button
am 12.07.2007 06:25:12 von Neredbojias
GMT Ben C scribed:
> On 2007-07-11, Jukka K. Korpela
>> 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 (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:
>
> hello cruel world
>
> 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.
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.
--
Neredbojias
A self-made man who worships his creator
Re: Menu list broken by form button
am 12.07.2007 09:10:48 von 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.Re: Menu list broken by form button
am 12.07.2007 13:11:58 von jkorpela
>> 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.
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.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/