Opened 3 years ago

Closed 2 years ago

#14082 closed defect (bug) (wontfix)

wp_nav_menu inserts newline char (carriage return) between <li>

Reported by: dmichalakos Owned by:
Priority: normal Milestone:
Component: Menus Version: 3.1
Severity: normal Keywords: close
Cc: wojtek.szkutnik@…

Description

Hello, I tried to create an inline menu, and found that wp_nav_menu inserts newline characters between the li tags.

The result is leaving a space between the elements,
i.e. list1 list2 list3 list4
where it should be list1list2list3list4

This is a quick fix:

$menu = wp_nav_menu(
    array(
            'theme_location'=>'language_menu',
            'container'=>null,
            'menu_id'=>'language-menu',
            'menu_class'=>null,
            'echo'=>0
        )
);
$menu = str_replace("\n", "", $menu);
$menu = str_replace("\r", "", $menu);
echo $menu;

Attachments (1)

14082.diff (521 bytes) - added by wojtek.szkutnik 3 years ago.

Download all attachments as: .zip

Change History (19)

  • Keywords wp_nav_menu added

I believe you're referring to an Internet Explorer rendering bug.

  • Version changed from 3.0 to 3.0.1

no, it's not an IE thing. it's present in any browser, any os. just add borders to the <li> tags rendered by wp_nav_menu() and you'll see the spaces.

  • Cc wojtek.szkutnik@… added
  • Keywords has-patch dev-feedback gosc added; newline li wp_nav_menu removed

I'm pretty sure it causes much more trouble on IE than on other browsers. If we want it fixed, including the str_replace might be a good idea. However, as far as I understand, it's not a WP bug, but an IE one. If the browser behaves in a buggy way, should we fix it inside WP or wait for IE to be fixed?

  • Keywords gsoc added; gosc removed

Generally this only occurs if you use display: inline, yeah? Floating the block-level elements instead of turning them into inline elements should prevent the need for squished HTML.

On all decent browsers - certainly. I'm not sure about IE :P

comment:8   Olen3 years ago

This is definitely not an IE bug. Carriage returns are treated as white space, this is part of the HTML standard (section 9.3.2). Floating isn't really an option because it would require positioning within another container to get certain layout to work correctly. WordPress should simply not insert carriage returns.

Technically, showing spaces when display:inline is set is correct behavior.

In most cases, floating display:block on li's, use overflow:hidden and width:100% (any height or width declaration will do) on the ul (http://www.quirksmode.org/css/clearing.html). Same effect as inline without spaces... Quite common best practice now-a-days.

This certainly isn't a WordPress core issue. It's a CSS concern. It's not even a browser bug.

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Closing as invalid.

Use floats or another technique instead of inline, if that's what you're after.

Correct me if I'm wrong but using floats still requires extra markup. If I want a horizontal menu centered horizontally, using floats will require me to set an absolute size on the width of the UL in order to get it in the middle, which isn't really an option.

  • Resolution invalid deleted
  • Status changed from closed to reopened

as Olan says, this can't be left like this. if want to center my menu, i'll have to use display: inline on the current li and text-align: center on the parent ul. if i float the li, then centering won't be possible.

  • Summary changed from wp_nav_menu inserts newline char between <li> to wp_nav_menu inserts newline char (carriage return) between <li>
  • Version changed from 3.0.1 to 3.1

I believe the proper styling would be inline-block plus text-align: center.

  • Keywords close added; has-patch dev-feedback gsoc removed
  • Milestone set to Awaiting Review

IE support inline-block only for native inline elements. so your suggestion is not cross-browser compatible.

It's still fairly standard to have tabs, line-breaks, and other white space in-between LIs in markup (for readability), and horizontal shrink-wrapped menus are somewhat rare, (probably, in fact, due to the popularity of this style of markup). I mean to point this out as it's not WordPress, but rather the industry, that has established this practice.

Having said that, the markup practices where implemented for human readability. Given that WordPress' output is machine written, and most developers read HTML source through a syntax filter of some sort (Firebug, DOM inspectors), then perhaps the practice is out-dated.

If it is the case that an indented markup style is outdated then should a new coding standard be adopted with respects to HTML source formatting? (Preferably debated on the mailing list?)

In the mean time, it can probably be solved by plugins ;-)

These two plugins use minify (http://code.google.com/p/minify/) on HTML (strips out white-space):

  1. http://wordpress.org/extend/plugins/wp-minify/
  2. http://wordpress.org/extend/plugins/w3-total-cache/

(Or role your own smaller, more specific plugin.)

I haven't tested them, but they'll likely solve your concerns without changes to core.

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

The quick fix and the plugins and such all work for me. Closing.

Note: See TracTickets for help on using tickets.