[wp-trac] [WordPress Trac] #16049: Admin bar ellipsis

[WordPress Trac]

#16049: Admin bar ellipsis
-----------------------------------------------+---------------------------
 Reporter:  GaryJ                              |       Owner:
     Type:  defect (bug)                       |      Status:  new
 Priority:  normal                             |   Milestone:  Future
Component:  Administration                     |  Release
 Severity:  normal                             |     Version:  3.1
 Keywords:  has-patch needs-testing 3.2-early  |  Resolution:
-----------------------------------------------+---------------------------

Comment (by GaryJ):

 Replying to [comment:4 westi]:
 > We can review this for 3.2.
 >
 > We don't really support serving as XML out of the box and 3.1 is way
 past the time this could have been changed.

 It was only amended from '...' 3 weeks ago ([16952]).

 > Named entities are so much clearer than magic numbers and ideally where
 a named entity exists it is much more readable to use it.

 As mentioned, there are 36 uses of `…` and only 22 uses of
 `…` in trunk, so a numerical entity appears to be favoured for an
 ellipsis.

 There are around 1200 strings matching `/&[a-zA-Z0-9]+;/` (named entities)
 and closer to 1100 uses of strings matching `/&#\d+;/` (decimal entities)
 and 8 matches for `/&#x\d+;/` (hexadecimal entities) within trunk. A fair
 proportion of the decimal entities appear to be equivalent to `»` et
 al, so there's already some inconsistency between ideals of wanting named
 entities, and what's currently in the code.

 I understand that you don't support XML parsing by default (but no-one
 appears to be able to give a reason, other than "we never have"), but with
 existing entities being approximately split in half between named and
 decimal there's a chance to gain consistency and eliminate a hurdle to
 being ready to be XML parsable in one (mighty) go. Named entities ''are''
 friendlier, but some users want to push WP forward with technology that
 just doesn't support them. They shouldn't be artificially held back just
 because the code happens to be easier to read.

 > ''If'' we are to switch to supporting serving as XML out of the box in
 future there is alot more changes required than just this.

 Oh, I understand this - my point was that this one particular occurrence
 could have been switched with no negative effects, irrespective of how
 late in the cycle it happened to be.

 > For your requirements you should be able to use the
 {{{add_admin_bar_menus}}} hook to remove and replace the string I believe.

 You are, of course, absolutely right, and I must sincerely thank you for
 pointing that out. I was looking for a filter, and simply hadn't
 considered the idea of removing the whole menu and inserting an amended
 duplicate in it's place.

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