Some excellent arguments in the previous thread have changed my mind on
certain issues. So I'm posting a revised proposal here. I thought a new
thread rather than a continuation would be better, so it's clear which
proposal people are addressing.
The changes do, of course, raise some further questions. And none of
them are set in stone - feel free to try and persuade me back again if
you think they aren't improvements :-)
A) Clicking the hostname no longer takes you to the root of the site. I
agree, this should remain an in-page navigation option. Lots of sites
provide it already, so it's not all that useful. This means that
clicking it allows editing, just as with the rest of the URL, which is
consistent. Also, removing it allows us to do:
B) URL bar changes to a text box on hover as well as on focus. (We
couldn't do this before, as otherwise the hostname button would be
unclickable.) This makes it much easier to click where you want to to
select part of the URL, because you are clicking where the caret will
actually end up, rather than clicking in one place, the form of the bar
changing on focus, and the caret actually appearing in another place
(albeit between the same, clicked letters).
We could even make it so that the URL bar changes mode when the mouse
was over any part of the chrome, not just the URL bar itself. That means
that if you moved the mouse from the content towards the URL bar, it
would have changed by the time you arrived, and you could aim at the
right spot. The exact algorithm would require some careful tuning.
Perhaps it could fade quickly between the two forms so as not to be too
This means we can also say:
C) It's not so important that things don't shift around when the URL bar
changes modes - because the shift now happens on hover (even just
getting close), rather than on focus, so you can move the mouse, see the
shift, and then click where you want the caret to be and it'll stay there.
This means that:
D) We can show the scheme in the text version, without worrying about
the jumping around. This removes some concerns people had about hiding
the scheme totally. (It's still hidden in the non-text version.)
Removing "click the hostname" also means that:
E) We highlight Effective TLD + 1, not the entire hostname. There's no
need to highlight the entire hostname because "it might be where people
want to go when they click" - that rationale is removed. Sticking with
Effective TLD + 1 removes the spoofing possibilities of highlighting all
F) I have changed to Ben and Rimas's suggestion of _prepending_ the EV
information to the domain name. IE has it on the far right, but I think
prepending it works well, because it's then in the position the domain
name used to be, and yet the domain name is still visible (and
highlighted). But I'd particularly like further discussion on this,
because it raises its own issues.
Location Bar Proposal 1.1
- Don't break stuff people use
- Make the hostname stand out more to reduce spoofing
- Reduce the risk of spoofing in other ways
- Make the contents of the URL bar more understandable
- Make common operations easier
- Find a way of presenting information from EV certificates
1) Hide the scheme when URL bar not focussed/hovered.
The scheme (e.g. "http://", "ftp://") should be hidden for HTTP, HTTPS,
FTP and file URLs. The differences between HTTP and FTP have long since
ceased to matter to the average web user. The difference between HTTP
and HTTPS is, of course, important, but we have other UI to indicate
that. (And if it sucks, we need to fix it.) Eliminating the scheme also
means we could do things like show some HTTPS connections as if they
were HTTP - e.g. for self-signed certificates, which people just use
when they want eavesdropping protection - without our UI being
inconsistent. This is an improvement on the current behaviour, which is
just to throw an error.
2) Hide username and password
If present. This is the "foo:bar" in http://foo:b...@hostname.com.
Usernames and passwords over unencrypted channels, embedded in GET
requests (which are cached) and links, are fundamentally insecure and
their most common use is for spoofing (although we already have some
protection against that). If people type them in, we'll use them to try
and log in, but we won't show them in the location bar.
Yes, this makes them less useful - if you make a typo, you need to
retype everything. I don't think this is a bad trade-off.
3) Highlight hostname
Take the Effective TLD + 1 and highlight it (in some way to be decided).
www. EXAMPLE.COM /foo/bar/baz?q=x
where capital letters indicate some sort of styling such as bold,
underline, italic, colour or border. (We need to be careful with bold;
with some fonts, it reduces the difference between letters such as l and
i, which is bad from a spoofing perspective. Further research required.)
There is some space either side of the highlighted text.
For file:// URLs, you'd have no highlighting, as there's no domain.
4) Display EV business name and country
For HTTPS connections with EV certificates, prepend the hostname with
the O (Organisation) and C (Country) fields from the certificate. So:
[* Paypal, Inc.] - www. PAYPAL.COM /foo/bar/baz?q=x
We replace the hostname in geographical space, while still making it
visible further to the right. This means there's a really big difference
between the real site and an attempted spoof, which would have a domain
name in that space rather than a textual name.
We now have two things highlighted; we'd need to do UI experiments to
see if that was confusing, and whether we should highlight them the same
or different, or whether we should drop the highlighting of the domain
name, or something else. The name and flag need to appear non-editable.
The * represents a flag. We need to include information about the
country (there can be businesses of the same name in different
jurisdictions), and the question is, do we use letters (US, UK, CM) or a
flag? A flag is safe because we are actually talking about countries,
not languages, and it might be more recognisable and differentiable. IE
and Opera are using letters.
The flag is next to where the favicon should be, which raises a risk of
confusing of spoofing, but leads on to:
5) Remove the favicon from the URL bar entirely
We would keep it on tabs, of course. I realise this is controversial;
here's my rationale. Favicons in the URL bar are dangerous, because they
represent the website having some control over what's in the chrome.
This is why we turned off website access to the status bar. We already
have spoof websites having a little lock as their favicon, to try and
persuade users they are over SSL. Let's put the websites back into the
content area box.
This could lead to making the tab bar always visible - i.e. setting
browser.tabs.autoHide to false - so that the favicon was always visible.
I think this is good because it improves the discoverability of tabs and
stops the content area jumping around when you go from one to two tabs
or vice versa. I don't know if the default setting of this preference is
a controversial issue. Perhaps this issue needs to be separated out.
I believe that the only other function of the page-proxy-icon (where the
favicon appears) is to be draggable to create e.g. bookmarks toolbar
entries. We'd need to replace that function somehow. To be decided.
6) Focus/hover turns bar back to a text box
On focus/hover, move back towards being a text box. People have
important behaviours to do with URL bar hand-editing that we don't want
to break. Therefore, clicking anywhere in the URL bar, or pressing
Ctrl-L or equivalent, focusses the URL bar and makes the following changes.
If the domain name is styled in such a way that it looks "uneditable",
then the style changes to remove that impression. We should try and keep
enough style to make sure the domain is still picked out, if possible.
Any hidden information, such as the scheme, returns. The EV business
name and country identifier remain (as they aren't editable, so there's
no need to do anything to them). The URL bar acts as much like a single
text box as possible. This will lead to things shifting about; we'd need
to do tests to see if this was too jarring. I hope that the fact that it
changes on hover means that it isn't.
7) Change selection behaviour
People edit individual URL components. So, we should make it easier to
select individual components. Like in a word-processor, a single-click
focusses, a double-click selects a component ("word") - hostname, path
segment, URL parameter key+value or fragment identifier, and a
triple-click selects the entire URL (equivalent to "select line").
For reference, the current behaviour is:
With layout.word_select.stop_at_punctuation=false (default on Linux):
Single-click places caret
Double-click selects everything
Triple-click also selects everything
In other words, the selection never takes account of the different parts
of the URL.
With layout.word_select.stop_at_punctuation=true (default on Windows):
Single-click places caret
Double-click selects out to punctuation
Triple-click selects everything
URL bar selection behaviour has been discussed before in this bug:
which requests that layout.word_select.stop_at_punctuation be set to
true on all platforms.
8) Analyse font choice carefully
If we are emboldening some parts of the URL (e.g. the domain), we need
to be very careful about choosing fonts where the bold version provides
enough differentiation between visually close letters like i and l.
Perhaps we might consider a fixed-width font in the URL bar? This would
also make selection easier; at the moment, putting the caret in the
right place in million.com is nearly impossible for those with less than
perfect motor skills, and tricky even for those with.
Not all of these suggestions are interrelated; some could be removed
without affecting others. This is not supposed to be a tightly-bound
I Strongly agreed here. Some places (as <http://people.mozilla.com>)
don't have a useful top level domain page.
> B) URL bar changes to a text box on hover as well as on focus. (We
> couldn't do this before, as otherwise the hostname button would be
> unclickable.) [...]
Selecting a piece of text without the need to another click is good.
I was thinking we could have a in-between plain view and pretty view here.
There is here a concern about decoding URLs at this stage.
If I read:
and want to change to:
That's fairly easy.
But if I see:
and wanna change to:
That's harder. For Japanese and other ruby ones, that's even harder.
The user couldn't see anymore the exact place of the mistake (or another
thing he wanted to change).
Our URL bar threats this:
<http://pt.wikipedia.org/wiki/Ação (física)> correctly, so the user
could see the decoded URL while editing.
Copying with the spaces would break it almost everywhere, so FX could
That would be a huge benefit for non speakers of a lot of languages around.
> We could even make it so that the URL bar changes mode when the mouse
> was over any part of the chrome, not just the URL bar itself. That means
> that if you moved the mouse from the content towards the URL bar, it
> would have changed by the time you arrived, and you could aim at the
> right spot. The exact algorithm would require some careful tuning.
What about the mouse arriving there by change? Because of switching windows?
This could lead to having a plain view when the user didn't want and
that could be confusing.
> C) It's not so important that things don't shift around when the URL bar
> changes modes - because the shift now happens on hover (even just
> getting close), rather than on focus, so you can move the mouse, see the
> shift, and then click where you want the caret to be and it'll stay there.
When you point to something and it moves, that's annoying. But that's
better than the old proposal.
> This means that:
> D) We can show the scheme in the text version, without worrying about
> the jumping around. This removes some concerns people had about hiding
> the scheme totally. (It's still hidden in the non-text version.)
I believe everyone is happy here, but that could be further studied (see
> Removing "click the hostname" also means that:
> E) We highlight Effective TLD + 1, not the entire hostname. There's no
> need to highlight the entire hostname because "it might be where people
> want to go when they click" - that rationale is removed. Sticking with
> Effective TLD + 1 removes the spoofing possibilities of highlighting all
> of microsoft.com.foo.bar.evil.com.
It's a must. No other idea should change this proposal, IMHO.
> F) I have changed to Ben and Rimas's suggestion of _prepending_ the EV
> information to the domain name. IE has it on the far right, but I think
> prepending it works well, because it's then in the position the domain
> name used to be, and yet the domain name is still visible (and
> highlighted). But I'd particularly like further discussion on this,
> because it raises its own issues.
The same clue as above about "don't move too much the things away".
One more thing about it. Though not sure if the devs should take it
into account or not. In previous thread you mentioned a Japanese link.
Windows users may have problems with links like that, because
Windows often includes only support for typography of relevant
regions/languages by default, and doesn't add support for other
regions. For example, I don't think I could actually see CJK
hieroglyphs on my Windows machine.
Not sure if it's a concern though, as if your computer doesn't support
those symbols, you should have no need to visit pages that have them
even in URL... But well...
It was me who posted the link to the japanese wikipedia, and I have a
plain XP Pro version of windows (it is even possible to enable
japanese keyboard input, a lot of people learning e.g. Japanese do
this). Even notepad in windows XP works in UTF-8 by default. The only
problem might be japanese fonts (because I'm not sure I didn't install
those manually... but they should be avaliable on the install CD). Is
it possible for FF to detect wether a particular glyph can be
displayed, and if not, revert to the url-encoded version of the whole
(just out of curiosity, can you see the characters in
That would be a pretty good solution, if possible...
> (just out of curiosity, can you see the characters in
> http://ja.wikipedia.org/wiki/メインページ ?)
Yes, but I'm on Linux now. :)
I don't mean to sound like an IE lover, but again, I like the way IE7
handles IDN, and I think we could expand this for anything concerning
the URL. And what they do is explained in .
hehe, take a look at a screenshot here:
To increase readability of URLs, the path part of the URL should be
displayed as characters, not as an url-encoded string (the query part
should remain url-encoded, because it is not sure it doesn't contain
binary data). The status bar should match the display of the location
bar (currently, it displays all characters decoded, even whitespace).
Some issues that come to mind (or have been mentioned in previous
- Whitespace handling. Whitespace characters should probably not be
decoded (this might allow URLs to overflow the visible area without
indication that this happened). They can either left encoded (e.g. %20
for a space), or they could be displayed similarly to "show
whitespace" mode in text editors and word processors (e.g. using
something like a middle dot for spaces). The first approach is
probably much easier to implement and a reasonable compromise between
readable urls and safety.
- How to display the anchor/fragment part of the URL?
- Missing fonts: What happens when an URL contains characters that
don't have a glyph installed on the system? Can Firefox detect a
missing glyph, and fall-back to the all-encoded version, or is it OK
to display a "missing glyph" (on some systems, its ?, on others an
- Editing/selection behavior: should the content of the location bar
change to the encoded version on location bar hover/select? (this
would be very hard to do seamlessly) This ties in closely with the
- copy/paste behavior: Should the encoded or decoded URL be copied and
pasted? Is it possible to say "the contents of the clipboard are a
hyperlink, the destination is this encoded url, and the name is this
decoded url"? What if only a part of the URL is selected?
My personal opinion on these two: try to use the decoded version as
much as possible, both for editing and for cutting and pasting. FF, IE
and Opera seem to cope well with html pages that contain non-ascii
characters in hyperlinks, and the w3c validator says it's valid (I
assume that all browsers are smart enough to encode the URL anyway for
the http protocol). Switching between the encoded and decoded version
is a bit annoying (try the current 0.7.2.1 version of the LocationBar2
extension to see what I mean), and it prevents editing of the URL (as
mentioned by Asrail).
- Which character set/encoding? I'm not sure if this really is an
issue (and only applies when decoded URLs will be used for copying and
pasting anyway). What happens if you copy an URL that's UTF-8 to a
page that is written in ISO-8859-1 - should FF convert the characters
to the target character encoding, or paste them byte-by-byte (no
transformation)? Firefox defaults to UTF-8 (this can be a problem when
using keyword searches on search engines that default to a different
encoding, and probably affects URLs typed directly too).
I'm sorry, are you talking about LocationBar^2, or maybe the one in
SM? The version of LocationBar^2 I'm using switches to the encoded url
for editing (which is a bit annoying).
I'm talking the Gerv's proposal.
I already have tested every URL bar version available since version 0.5.
Not only the ones available at addons.mozilla.org.
As of version 0.8 it don't decode the URLs. As of 0.8.2 spaces are
re-encoded (I've seen this one right after sending the mail above).
But the comments here are about the Gerv's proposal, please, that
extension is just to play with the proposals.
I meant: the last one LocationBar2 doing something does not mean anything.
Sure it does.
My fault, sorry...
"As of version 0.8 it doesn't re-encode the URLs in the plain view."
The second part of that sentence was right, though =(.
Just the same way as the rest of the URL, I suppose.
> - Editing/selection behavior: should the content of the location bar
> change to the encoded version on location bar hover/select? (this
> would be very hard to do seamlessly) This ties in closely with the
> next issue:
I think it shouldn't.
> - copy/paste behavior: Should the encoded or decoded URL be copied and
> pasted? Is it possible to say "the contents of the clipboard are a
> hyperlink, the destination is this encoded url, and the name is this
> decoded url"? What if only a part of the URL is selected?
Formatted text? I'm not sure it's needed. But the idea is interesting...
> My personal opinion on these two: try to use the decoded version as
> much as possible, both for editing and for cutting and pasting. FF, IE
> and Opera seem to cope well with html pages that contain non-ascii
> characters in hyperlinks, and the w3c validator says it's valid (I
> assume that all browsers are smart enough to encode the URL anyway for
> the http protocol).
I think this is exactly browsers job. Hence, the validator doesn't
care. Well, (X)HTML specifications could be of a help here.
> Switching between the encoded and decoded version
> is a bit annoying (try the current 0.7.2.1 version of the LocationBar2
> extension to see what I mean), and it prevents editing of the URL (as
> mentioned by Asrail).
> - Which character set/encoding? I'm not sure if this really is an
> issue (and only applies when decoded URLs will be used for copying and
> pasting anyway).
I don't think it's a problem. This should be handled exactly the same
way any other non-ASCII text is currently handled.
> What happens if you copy an URL that's UTF-8 to a
> page that is written in ISO-8859-1 - should FF convert the characters
> to the target character encoding, or paste them byte-by-byte (no
> transformation)? Firefox defaults to UTF-8 (this can be a problem when
> using keyword searches on search engines that default to a different
> encoding, and probably affects URLs typed directly too).
And this part is unrelated, as it applies to any other text too. I
think what Fx currently does in such situation is encodes all
characters that don't fit into page charset as HTML entities.
Yes, IE puts it to the right. What are you trying to tell me? I'm
It would be great if someone could go away and read whatever documents
exist on IRIs (internationalised URLs) and let us know what stage those
specifications are at, and how they affect this question, if at all.
I'm hesitant to make suggestions as to how this should work without
consulting those docs.
It would also mean that you could bold the domain without shifting
everything that comes after (which would then move around on hover).
Then again, bolding is possibly not an option because of the mentioned
problems with complex scripts.
The downside for me isn't that monospace fonts look ugly but that they
take away space.
To tell the truth, I'm not familiar to the standardization process,
but it seems that the RFC 3987 (http://www.ietf.org/rfc/rfc3987.txt)
is mostly ready. The only open issue seems to be something about
comparing IRIs, and last month there was a message to the public
mailing list regarding a bidi issue. This info can be found at
http://www.w3.org/International/iri-edit/. Several specifications
already assume the existence of IRIs (although they don't directly
reference the specification, the underlying principles are the same,
encoding non-ascii characters as UTF-8 and then percent-encode them).
The parts of the RFC that most apply to the current issue are the
conversion from/to URIs, and the rendering of IRIs.
Mapping IRIs to URIs is relatively straightforward, unicode characters
are encoded using UTF-8 and then percent-encoded.
Decoding URIs is a bit more complicated, because (simply speaking)
only "strictly legal UTF-8 octet sequences" can be shown as
characters, the rest has to be kept percent-encoded. This applies to
some other characters as well. The RFC doesn't explicitly mention
spaces, but says that "characters in US-ASCII not allowed in URIs"
have to be kept percent-encoded - as far as I understand, this covers
spaces (and other whitespace and control characters). Some unicode
characters aren't permitted either. The RFC is a bit vague on that,
but basically it says that "look-alikes" should be left percent
encoded. Some are obvious, like half-width Katakana or "space look-
alike" characters. Some, like "many others" [sic] are not so obvious.
The RFC allows unicode characters almost everywhere - including
fragment and query, and it even touches the issue of IDNs and
Another important issue is rendering IRIs, because unicode text can be
bi-directional. This issue seems to be quite complex (because it
imposes additional constraints on what can be displayed and what has
to be kept percent-encoded). Also, each component of the IRI may use a
different directionality. The general rule seems to be that if an IRI
component can't be reliably displayed, the whole component has to be
So, the RFC definitely is worth having a look, if only to see the
range of issues that arise from trying to fully support
internationalized resource identifiers.
On a German Windows XP SP2, I can't.
That page links to instructions on how to install support for complex
script, right-to-left and East Asian languages in various Windows versions.
I say the tab strip should be on by default, and a new-tab button
positioned to the left of the tabstrip (like this extension
https://addons.mozilla.org/firefox/1456/ ). I believe that there are
too many icons already in the URL bar so removing the favicon would
I also think Mozilla should grow some bite and fix a lot of the
ancient UI in Firefox. The home button should be the leftmost link on
the bookmarks toolbar, and not an actual button anymore (Home is just
a glorified bookmark). It could be distinguished by being bold and
having a sperator line to the right.
I'm not! It is an excellent way to visually recognize a site.
> there may be a lot of uproar from removing the favicon from the URL
> bar, tab discoverability in Firefox is practically 0. Both IE7 and
> Opera have up-front default new-tab buttons. Firefox is very behind in
> this respect.
IE achieved this by without *wasting* a lot of vertical space by
creating a really weird menu/icon-bar/tab-layout. I don't think some
dubious 2discovery" of tabs (which n00bs will be rare to use anyhow) is
worth all that.
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
> I also think Mozilla should grow some bite and fix a lot of the
> ancient UI in Firefox. The home button should be the leftmost link on
> the bookmarks toolbar, and not an actual button anymore (Home is just
> a glorified bookmark).
Umm, interestingly, the SeaMonkey suite has both of them - and some
people always complain about the latter one and want "home" in the main
toolbar, while others love it in the bookmarks toolbar. I think that's
something only toolbar customization can resolve, as people want it in
Hum, why not have inside the bookmarks, using the home icon instead of
the favicon, and allowing to add it back to the toobar by drag&drop ?
The favicon on tabs behaves in the same way, although when you hover
the mouse cursor over it it doesn't change to the hand cursor the way
the page-proxy-icon does, so it isn't as discoverable.
Except many users don't use bookmarks at all. They certainly have no use
for the bookmarks toolbar; having it enabled at all is just wasting
vertical space. Home isn't really a glorified bookmark to these folks;
it's the panic button. It's the button you press when you've gotten
somewhere that seems scary and you want to go somewhere safe and
familiar so you can start over.
(And yes, the home button--and every other button--should be able to be
placed on any toolbar you want.)
I have some bookmarks but I have no use for the bookmarks _toolbar_ ; I prefer
the bookmarks _menu_ . OTOH I have a use for the Home button.
> (And yes, the home button--and every other button--should be able to be
> placed on any toolbar you want.)
As it is now, and (AFAIK) that capability is not going to be removed any time
soon: click right on any toolbar, then "Customize", and start dragging.
If everything is coming your way then you're in the wrong lane.
I still don't like this.
> 3) Highlight hostname
Add the port (if non standard for the protocol) to the highlighted
> 6) Focus/hover turns bar back to a text box
I just realized that changing the location bar from edit control to
anything else can present a challenge to accessibility API and software.
It would be good to involve Aaron Leventhal or other accessibility
people in this discussion.
Have you played with the latest Locationbar2?
>> 6) Focus/hover turns bar back to a text box
> I just realized that changing the location bar from edit control to
> anything else can present a challenge to accessibility API and software.
> It would be good to involve Aaron Leventhal or other accessibility
> people in this discussion.
It's still an edit control as far as the XUL DOM is concerned.
> One more thing about it. Though not sure if the devs should take it
> into account or not. In previous thread you mentioned a Japanese
> link. Windows users may have problems with links like that, because
> Windows often includes only support for typography of relevant
> regions/languages by default, and doesn't add support for other
> regions. For example, I don't think I could actually see CJK
> hieroglyphs on my Windows machine.
> Not sure if it's a concern though, as if your computer doesn't
> support those symbols, you should have no need to visit pages that
> have them even in URL... But well...
Sometimes you follow links. And sometimes the content of the pages is
(at least partly) in English, even though the domain is in .tw or
someplace like that.
Even if my computer *can* display these characters in the URL, it
shouldn't, because, I CAN'T READ THEM. "%057F" is at least
pronounceable in a pinch as "percent zero five seven eff" (or, if I
know what it means, "Unicode character zero five seven eff"), but the
actual character, if it's displayed, is just an arbitrary scribble.
In the page content it's another thing, or even the page title, but I
don't want off-the-wall characters in the location bar.
Display of non-ASCII characters in the URI should be l10n-dependent.
For en-us, it should be OFF by default. (Yes, many users can read
more than one language, so there obviously has to be a way to turn it
on, easily. I'm not sure what the UI for that should look like, but
there has to be one.)
Even for most multilingual users, there are way more unicode
characters that they *can't* read then there are ones that they can.
Turning on languages they can read would thus be more sensible than
turning off the ones they can't.
Jonadab, for some reason your message was sent with UTF-16be headers but UTF-8
or Latin1 content. The above is how that strange combination makes it look --
mostly Chinese to me. Let me quote it again below (which I can only do by
pasting after having changed the encoding):
> Rimas Kudelis <r...@i.hate.spammers.very.much.---.akl.lt> writes:
>>> > > (just out of curiosity, can you see the characters in
>>> > > http://ja.wikipedia.org/wiki/��0�0�0�0�0�0� ?)
that should have been http://ja.wikipedia.org/wiki/メインページ
>> > Yes, but I'm on Linux now. :)
> I cannot, on FreeBSD.
> It's probably because I didn't go out of my way to install fonts for
> that writing system (what is it, Kanji? something I can't read
> anyhow), but still, it looks like six identical empty rectanglular
> boxes here.
> And even if it looked like Japanese writing, that wouldn't be
> significantly better. I haven't studied Japanese writing, so it
> pretty much all looks the same to me. Indeed, in a context like the
> URL bar, with a small number of characters, I'm not confident I could
> distinguish Japanese writing from Chinese writing. (Given a full page
> of text I could, since I know Chinese is ideographic but Japanese uses
> a syllabary, so there would be a big difference in the variety of
> characters. But with only six characters to work from like above,
> even if my computer displayed them, I don't think I could tell which
> kind they were; I only guessed it was Japanese in this case because
> Wikipedia uses a language-indicating domain prefix.)
Japanese uses Chinese characters (called hanzi in Chinese, kanji in Japanese)
as well as two syllabaries (covering the same set of sounds with different
symbols, one used for foreign names (katakana) and the other for Japanese
"empty words" such as flexions, and for transliteration of difficult kanji
(hiragana). The hiragana are very different from the kanji, as they have a
much higher proportion of "rounded" line shapes. The six characters above are
all (IIUC) katakana (i.e., members of the other, more straight-lined, syllabary).
> Even writing systems that I *can* read (Latin alphabet with some
> diacritics, Greek alphabet with diacritics, Hebrew abjad with Niqqud
> vowel points, most of the Cyrillic alphabet, and a few characters from
> the Devanagari abugida), I don't particularly want to see them in the
> URL bar, but I admit that's mostly for reasons of ambiguity.
The current display (ASCII with percent-escapes) seems OK to me. Maybe an
additional menu item "Copy URL as UTF-8", which would resolve the
percent-escapes, could be added. And/Or a button to toggle "ASCII display" vs.
"Unicode display" of the Location Bar. But I'm not sure.
> -- v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
When hammering a nail, you will never hit your finger if you
hold the hammer with both hands.
I just installed it to try it out. I do like the highlighted colors, but
the changing content on hover/focus annoys the heck out of me.
I realized that I actually look at the scheme rather than the lock icon
in determining if I am on an SSL-enabled page (on some sites I check for
both). But because it is now hidden, I find I start reading the URL,
stop, look to the right to see if there is a lock, then jump back to the
beginning to start reading the hostname. Very irritating.
>>> 6) Focus/hover turns bar back to a text box
>> I just realized that changing the location bar from edit control to
>> anything else can present a challenge to accessibility API and software.
>> It would be good to involve Aaron Leventhal or other accessibility
>> people in this discussion.
> It's still an edit control as far as the XUL DOM is concerned.
I am not so sure that is what screenreaders etc. use.