Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#16049 closed defect (bug) (fixed)

Admin bar ellipsis

Reported by: garyj's profile GaryJ Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Administration Keywords:
Focuses: Cc:

Description

The … character in wp_admin_bar_my_sites_menu() has no chance of being filtered before being output.
I'd like to see the menu item blog titles have a filter, or the … changed to the hexadecimal ☆ so it's XHTML parsable as application/xhtml+xml.

Attachments (2)

admin-bar.php.patch (840 bytes) - added by GaryJ 13 years ago.
Changes … to …
admin-bar.php.2.patch (839 bytes) - added by GaryJ 13 years ago.
Change … to …

Download all attachments as: .zip

Change History (13)

@GaryJ
13 years ago

Changes … to …

#1 @demetris
13 years ago

I think we prefer decimal for numerical references, but don’t quote me on this.

(There is also a few more hellip instances lying around, but changing them would disturbe internationalized strings.)

#2 @GaryJ
13 years ago

Bah - description should refer to … and not ☆

As per http://www.w3.org/TR/charmod/#C048 - the W3C state that:

Content SHOULD use the hexadecimal form of character escapes rather than the decimal form when there are both.

I'd be happy with the decimal numerical entity if there was some objection to hexadecimal (though, there isn't any). I realise we might be in a string freeze now, so the other instances can't be changes until the next cycle at the earliest, but as this particular instance isn't translated, can it squeeze through for the new admin bar?

Version 0, edited 13 years ago by GaryJ (next)

#3 follow-up: @nacin
13 years ago

demetris is right, we do prefer decimal. Let's do … to be consistent.

#4 follow-ups: @westi
13 years ago

  • Keywords 3.2-early added
  • Milestone changed from Awaiting Review to Future Release

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.

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

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.

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

#5 in reply to: ↑ 3 @GaryJ
13 years ago

Replying to nacin:

demetris is right, we do prefer decimal. Let's do … to be consistent.

Fair enough - was just following the W3 Recommendation. There appears to be more than 30 occurrences of … throughout trunk already.

Last edited 13 years ago by GaryJ (previous) (diff)

@GaryJ
13 years ago

Change … to …

#6 in reply to: ↑ 4 @GaryJ
13 years ago

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

#7 in reply to: ↑ 4 ; follow-up: @demetris
13 years ago

Replying to westi:

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

Using entities at all in the year 2011 is not something I would describe as ideal in any way. :-D

Why not just start using straight UTF-8 in strings? I’ve thought about it a few times and I cannot see any reason against:

  • It’s not an issue for XML processors
  • It’s not an issue for WP translators (translations are UTF-8 anyway)
  • It’s not an issue for modern text editors

Am I missing something?

#8 in reply to: ↑ 7 @westi
13 years ago

Replying to demetris:

Replying to westi:

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

Using entities at all in the year 2011 is not something I would describe as ideal in any way. :-D

Why not just start using straight UTF-8 in strings? I’ve thought about it a few times and I cannot see any reason against:

  • It’s not an issue for XML processors
  • It’s not an issue for WP translators (translations are UTF-8 anyway)
  • It’s not an issue for modern text editors

Am I missing something?

It is an issue for sites serving themselves as something other than UTF-8.

i.e. if the blog charset is set to something else like Big5 or one of the GBxxxxx charsets

#9 @GaryJ
13 years ago

  • Resolution set to fixed
  • Status changed from new to closed

I see that [17295] has eliminated this issue, thanks :-)

#10 @GaryJ
13 years ago

  • Keywords has-patch needs-testing 3.2-early removed

#11 @ocean90
13 years ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.