Menu list broken by form button

Discussion in 'HTML' started by Paul Furman, Jul 11, 2007.

  1. Paul Furman

    Paul Furman Guest

    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?

    --
    Paul Furman Photography
    http://www.edgehill.net/1
    Bay Natives Nursery
    http://www.baynatives.com
    Paul Furman, Jul 11, 2007
    #1
    1. Advertising

  2. 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; }

    --
    Jukka K. Korpela ("Yucca")
    http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Jul 11, 2007
    #2
    1. Advertising

  3. Paul Furman

    dorayme Guest

    In article <FTZki.189873$>,
    "Jukka K. Korpela" <> wrote:

    > "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
    dorayme, Jul 11, 2007
    #3
  4. Paul Furman

    Neredbojias Guest

    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?

    --
    Neredbojias
    A self-made man who worships his creator
    Neredbojias, Jul 11, 2007
    #4
  5. Paul Furman

    Ben C Guest

    On 2007-07-11, Neredbojias <> wrote:
    > 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?


    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.
    Ben C, Jul 11, 2007
    #5
  6. Neredbojias wrote:
    > 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?
    >


    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; }

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Jul 11, 2007
    #6
  7. 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. 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.

    --
    Jukka K. Korpela ("Yucca")
    http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Jul 11, 2007
    #7
  8. Paul Furman

    Neredbojias Guest

    Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 09:15:32
    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 <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.


    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
    Neredbojias, Jul 11, 2007
    #8
  9. Paul Furman

    Neredbojias Guest

    Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 12:24:28
    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 <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; }


    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
    Neredbojias, Jul 11, 2007
    #9
  10. Paul Furman

    Ben C Guest

    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.
    Ben C, Jul 11, 2007
    #10
  11. Scripsit Ben C:

    >> 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/
    Jukka K. Korpela, Jul 11, 2007
    #11
  12. Paul Furman

    Neredbojias Guest

    Well bust mah britches and call me cheeky, on Wed, 11 Jul 2007 21:14:44
    GMT Ben C scribed:

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


    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
    Neredbojias, Jul 12, 2007
    #12
  13. Paul Furman

    Ben C Guest

    On 2007-07-11, Jukka K. Korpela <> wrote:
    > 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.
    Ben C, Jul 12, 2007
    #13
  14. Scripsit Ben C:

    >> 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/
    Jukka K. Korpela, Jul 12, 2007
    #14
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steven D'Aprano

    Why are "broken iterators" broken?

    Steven D'Aprano, Sep 21, 2008, in forum: Python
    Replies:
    8
    Views:
    633
  2. Cameron Simpson

    Re: Why are "broken iterators" broken?

    Cameron Simpson, Sep 22, 2008, in forum: Python
    Replies:
    0
    Views:
    567
    Cameron Simpson
    Sep 22, 2008
  3. Fredrik Lundh

    Re: Why are "broken iterators" broken?

    Fredrik Lundh, Sep 22, 2008, in forum: Python
    Replies:
    0
    Views:
    588
    Fredrik Lundh
    Sep 22, 2008
  4. Hiten
    Replies:
    1
    Views:
    609
    Vidar Petursson
    May 26, 2004
  5. CM
    Replies:
    2
    Views:
    78
    Joshua Landau
    Jul 8, 2013
Loading...

Share This Page