Location Bar Proposal 1.2
Gervase Markham
attempt. No further big changes, just made the text consistent.]
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 :-)
Big changes:
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
visually jarring.
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
of microsoft.com.foo.bar.evil.com.
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
-------------------------
Goals:
- 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
Optional Goal:
- Find a way of presenting information from EV certificates
Suggested Changes:
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).
So either:
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:
https://bugzilla.mozilla.org/show_bug.cgi?id=190615
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
take-it-or-leave-it package.
Gerv
Asrail
> A) Clicking the hostname no longer takes you to the root of the site. I
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:
http://pt.wikipedia.org/wiki/Açcão
and want to change to:
http://pt.wikipedia.org/wiki/Acção
That's fairly easy.
But if I see:
http://pt.wikipedia.org/wiki/A%C3%A7c%C3%A3o
and wanna change to:
http://pt.wikipedia.org/wiki/Ac%C3%A7%C3%A3o
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
encode them.
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
above).
> 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".
Rimas Kudelis
> There is here a concern about decoding URLs at this stage.
> If I read:
> http://pt.wikipedia.org/wiki/Açcão
> and want to change to:
> http://pt.wikipedia.org/wiki/Acção
>
> That's fairly easy.
> But if I see:
> http://pt.wikipedia.org/wiki/A%C3%A7c%C3%A3o
> and wanna change to:
> http://pt.wikipedia.org/wiki/Ac%C3%A7%C3%A3o
>
> 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
> encode them.
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...
RQ
Kim Sullivan
> 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
address?
(just out of curiosity, can you see the characters in
http://ja.wikipedia.org/wiki/メインページ ?)
Rimas Kudelis
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 [1].
RQ
Rimas Kudelis
> 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.
hehe, take a look at a screenshot here:
http://blogs.msdn.com/ie/archive/2006/10/20/ie7-and-high-assurance-at-rsa-europe.aspx
RQ
Kim Sullivan
characters in paths... I hope I don't omit anything:
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
discussions):
- 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
empty rectangle)
- 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:
- 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).
Kim
Kim Sullivan
> 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.
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).
Kim
Asrail
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.
Dao Gottwald
> Kim Sullivan, 19-02-2007 20:34:
>> On Feb 19, 7:29 pm, Asrail <asr...@gmail.com> wrote:
>>> 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.
>>
>> 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.
Sure it does.
Asrail
My fault, sorry...
read:
"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 =(.
Rimas Kudelis
> - How to display the anchor/fragment part of the URL?
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).
I agree.
> - 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.
RQ
Gervase Markham
> hehe, take a look at a screenshot here:
> http://blogs.msdn.com/ie/archive/2006/10/20/ie7-and-high-assurance-at-rsa-europe.aspx
Yes, IE puts it to the right. What are you trying to tell me? I'm
confused...
Gerv
Gervase Markham
> 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).
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.
Gerv
Dao Gottwald
> 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.
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.
Kim Sullivan
> 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.
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
security.
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
displayed percent-encoded.
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.
Kim
Steffen Wilberg
> http://ja.wikipedia.org/wiki/メインページ ?)
On a German Windows XP SP2, I can't.
See http://en.wikipedia.org/wiki/Help:Multilingual_support_%28East_Asian%29
That page links to instructions on how to install support for complex
script, right-to-left and East Asian languages in various Windows versions.
Steffen
Kroc Camen
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.
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
help declutter.
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.
Peter Lairo
> I'm very much in agreement with point 5 (hide the favicon).
I'm not! It is an excellent way to visually recognize a site.
> Whilst
> 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.
--
Regards,
Peter Lairo
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Robert Kaiser
> a new-tab button
> positioned to the left of the tabstrip (like this extension
> https://addons.mozilla.org/firefox/1456/ ).
> 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
different ways.
Robert Kaiser
Kroc Camen
hardcore people who are set in their ways. Those people can easily
customize the browser back to how they're used to. But Mozilla need to
get rid of archaic UI that doesn't make proper design sense anymore.
The Home button should be moved to the bookmarks bar for the benefit
of regular people, those who want a home button can just customize
their toolabr - they know how to.
Jean-Marc Desperrier
> The Home button should be moved to the bookmarks bar for the benefit
> of regular people, those who want a home button can just customize
> their toolabr - they know how to.
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 ?
Flenser
> favicon appears) is to be draggable to create e.g. bookmarks toolbar
> entries. We'd need to replace that function somehow. To be decided.
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.
Greg Campbell
> 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.
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.)
Greg
Tony Mechelynck
> Kroc Camen wrote:
>> 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.
>
> 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.
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.)
>
> Greg
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.
Best regards,
Tony.
--
If everything is coming your way then you're in the wrong lane.
Heikki Toivonen
> 1) Hide the scheme when URL bar not focussed/hovered.
I still don't like this.
> 3) Highlight hostname
Add the port (if non standard for the protocol) to the highlighted
hostname part.
> 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.
--
Heikki Toivonen
Gervase Markham
> Gervase Markham wrote:
>> 1) Hide the scheme when URL bar not focussed/hovered.
>
> I still don't like this.
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.
Gerv
Jonadab the Unsightly One
Jonadab the Unsightly One
> 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.
--
v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
Tony Mechelynck
> 剩浡猠䭵摥汩猠㱲煀椮桡瑥灡浭敲献癥特畣栮ⴭ慫氮汴㸠睲楴敳㨊ਾ‾ 橵獴畴映捵物潳楴礬慮⁹潵敥⁴桥桡牡捴敲猠楮ਾ‾瑴瀺⼯橡楫楰敤楡牧⽷楫椯メインページ‿⤊㸠ਾ⁙敳Ⱐ扵琠䤧洠潮⁌楮畸潷⸠㨩ਊ䤠捡湮潴Ⱐ潮⁆牥敂卄⸊琧猠灲潢慢汹散慵獥⁉楤渧琠杯畴映浹⁷慹⁴漠楮獴慬氠景湴猠景爊瑨慴⁷物瑩湧祳瑥洠⡷桡琠楳琬⁋慮橩㼠潭整桩湧⁉慮❴敡搊慮票潷⤬畴瑩汬Ⱐ楴潯歳楫攠獩砠楤敮瑩捡氠敭灴礠牥捴慮杬畬慲潸敳敲攮ਊ䅮搠敶敮映楴潯步搠汩步⁊慰慮敳攠睲楴楮本⁴桡琠睯畬摮❴攊獩杮楦楣慮瑬礠扥瑴敲⸠⁉慶敮❴瑵摩敤⁊慰慮敳攠睲楴楮本漠楴ੰ牥瑴礠浵捨汬潯歳⁴桥慭攠瑯攮†䥮摥敤Ⱐ楮潮瑥硴楫攠瑨攊啒䰠扡爬⁷楴栠愠ç
��慬氠湵浢敲映捨慲慣瑥牳Ⱐ䤧洠湯琠捯湦楤敮琠䤠捯畬搊摩獴楮杵楳栠䩡灡湥獥⁷物瑩湧牯洠䍨楮敳攠睲楴楮朮†⡇楶敮畬氠灡来੯映瑥硴⁉潵汤Ⱐ獩湣攠䤠歮潷⁃桩湥獥猠楤敯杲慰桩挠扵琠䩡灡湥獥⁵獥猊愠獹汬慢慲礬漠瑨敲攠睯畬搠扥楧楦晥牥湣攠楮⁴桥⁶慲楥瑹昊捨慲慣瑥牳⸠⁂畴⁷楴栠潮汹楸桡牡捴敲猠瑯⁷潲欠晲潭楫攠慢潶攬癥渠楦礠捯浰畴敲楳灬慹敤⁴桥洬⁉潮❴⁴桩湫⁉潵汤⁴敬氠睨楣栊歩湤⁴桥礠睥牥㬠䤠潮汹略獳敤琠睡猠䩡灡湥獥渠瑨楳慳攠扥捡畳攊坩歩灥摩愠畳敳慮杵慧攭楮摩捡瑩湧潭慩渠灲敦楸⸩ਊ䕶敮⁷物瑩湧祳瑥浳⁴桡琠䤠⩣慮⨠牥慤 䱡瑩渠慬灨慢整⁷楴栠獯浥楡捲楴楣猬⁇牥敫汰桡扥琠睩瑨楡捲楴楣猬⁈敢牥眠慢橡搠睩瑨⁎楱煵搊癯睥氠ç
��楮瑳Ⱐ浯獴映瑨攠䍹物汬楣汰桡扥琬湤敷桡牡捴敲猠晲潭ੴ桥⁄敶慮慧慲椠慢畧楤愩Ⱐ䤠摯渧琠灡牴楣畬慲汹⁷慮琠瑯敥⁴桥洠楮⁴桥剌慲Ⱐ扵琠䤠慤浩琠瑨慴❳潳瑬礠景爠牥慳潮猠潦浢楧畩瑹⸊ਭⴠਊ瘳獷㕐桷㕬渵灲㕏⽆⽐⽣欲浡㡵㝌⽆眳洵氶⼷椶收琰户⼸敮㑧㌯㕔愳塲㕰㌠桡捫敲步礮捯洊
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
Best regards,
Tony.
--
Leibowitz's Rule:
When hammering a nail, you will never hit your finger if you
hold the hammer with both hands.
Heikki Toivonen
> Heikki Toivonen wrote:
>> Gervase Markham wrote:
>>> 1) Hide the scheme when URL bar not focussed/hovered.
>>
>> I still don't like this.
>
> Have you played with the latest Locationbar2?
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.
--
Heikki Toivonen
Gervase Markham
> 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.
Yes, I can imagine. The lock is not ideally placed for a good "eye-flow"
in that sense. But hopefully we'll be looking at how that UI works as
part of the security UI review. Something to bear in mind.
Gerv
Jonadab the Unsightly One
> Jonadab, for some reason your message was sent with UTF-16be headers
> but UTF-8 or Latin1 content.
Very strange.
Ordinarily I don't post anything to usenet with more than 7 bits per
character, so it's entirely possible that Gnus is misconfigured with
regard to posting Unicode, and I might not have noticed until now.
OTOH, it is very unlikely that I ever took any deliberate action to
change the configuration of Gnus with regard to posting unicode, and I
certainly have no recollection of doing so.
Nonetheless, I do see the following header:
Content-Type: text/plain; charset=utf-16be
And yes, my post is totally illegible to me here, too.
That header is present in the copy that Gnus kept on my system when I
sent it, so it was already there then (i.e., was not added ex post
facto by e.g. a weird news server issue). So either the version of
Gnus that I have comes misconfigured out of the box (unlikely), or
something about my configuration has confused it (much more likely),
or something about the message I was replying to confused it (also
conceivable).
I don't know enough about Unicode to comment beyond that. Actually
what impresses me most about Unicode is the number of different
kinds of bugs it causes.
> 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).
Interesting. I didn't know all of that.
Japanese is not a language I have ever studied.
--
v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
