#16049 closed defect (bug) (fixed)
Admin bar ellipsis
Reported by: | 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)
Change History (13)
#1
@
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
@
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?
#3
follow-up:
↓ 5
@
13 years ago
demetris is right, we do prefer decimal. Let's do …
to be consistent.
#4
follow-ups:
↓ 6
↓ 7
@
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
@
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.
#6
in reply to:
↑ 4
@
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:
↓ 8
@
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
@
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
Changes … to …