[wp-trac] [WordPress Trac] #14844: wp_nav_menu producing unexpected results

[WordPress Trac]

#14844: wp_nav_menu producing unexpected results
--------------------------+-------------------------------------------------
 Reporter:  holypixel     |       Owner:                         
     Type:  defect (bug)  |      Status:  new                    
 Priority:  normal        |   Milestone:  Awaiting Review        
Component:  Menus         |     Version:  3.0.1                  
 Severity:  normal        |    Keywords:  reporter-feedback close
--------------------------+-------------------------------------------------

Comment(by filosofo):

 Replying to [comment:5 holypixel]:
 > I realise that they all link to the item D page, however the links
 themselves are uniquely identified by the menu-item-id. It is using the
 menu-item-id as opposed to the target page or url that I propose using as
 the identifier.

 HTTP is stateless.  That means that no information is kept from one page
 request to the other.  Say you're looking at page A, and you click a link
 with ID X that requests page B.

 When you request page B the server doesn't know that you just clicked a
 link with ID X.  It just knows about the resource you're requesting at
 that moment (page B) and some additional information usually transmitted
 in the HTTP headers, such as the referrer (page A) and cookies.

 So to let the server know that you're requesting Item D by following the
 right-hand Item D menu item link, you basically have two options:
  * Change the Item D menu links so that they are different from each
 other, perhaps by adding arguments or fragments:
     * `http://example.com/item-d-page/?from-clicking=id-item-123`
     * `http://example.com/item-d-page/#id-item-123`
  * Capture the click event using JavaScript and set a cookie that saves
 the ID of the last link clicked.

 Perhaps you can see that implementing these potential solutions
 systematically would be too convoluted and obscure for core WordPress;
 they are solutions best implemented by plugins.


 > It is either broken or I am seriously not understanding something.
 Throughout our discussion you have said that wordpress cannot
 differentiate between the menu items if they are multiple instances due to
 the fact that their target's are the same. If that is the case, then why
 even bother having the current-menu-item, current-menu-parent or current-
 menu-ancestor classes, if all they do is mirror the curren-page style of
 classes?

 The classes reflect the state of the ''current page'' (remember that HTTP
 is stateless).  They do not reflect your browsing history (such as the
 fact that you clicked a particular link to arrive at this current page).
 So when you are viewing the Item D page, the server that generated its
 markup does not care or know about the ID of the link you followed to view
 that page; it just knows that ''this'' is the Item D page so ''those''
 Item D menu links need classes to indicate that they are the currently-
 generated page.

 > To allow multiple instances in the wp_nav_menu system, but not support
 them semantically seems pretty crippled.

 All the other classes reflect the semantics of the menu structure and the
 menu items' relationships to the currently requested page.  ''None''
 reflects the client's browsing history, which is what you're asking for.
 In fact, it would be considered bad practice if the idempotent GET request
 method (what you use to load a page by following a link) resulted in
 markup that changed according to browsing history.  In other words, good
 practice suggests that multiple, identical requests should get identical
 responses (in truth though WP breaks this a lot in the admin).

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14844#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software