browser.urlbar.richResults = false doesn't work anymore :-(
Lars-Erik Østerud
Get the new two-line fancy drop down list even with that on :-(
I though you were going to have the "browser.urlbar.richResults"
option?
Don't like the new view at all (to few lines, to messy/confusing)?
--
Lars-Erik - http://www.osterud.name - ICQ 7297605
My Firefox tweaks: http://osterud.name/firefox.html
Dave Townsend
about the reasons there.
Dave
Lars-Erik Østerud
> Support for the option was removed in bug 407836, you can read more
> about the reasons there.
I read it, but don't sse the logic :-(
Why couldn't the option be left for advanced users?
FF gets more and more like IE7, easy small functional things and
posibility to choose is replaces by huge icons, eye-candy, fancy lists
etc.
That would have been OK if one could choose not to use then,
but when that is removed as well :-(
Don't like it :-(
Foteos Macrides
Lars-Erik Řsterud wrote:
> I read it, but don't see the logic :-(
The "logic" for ignoring criticisms such as yours is expressed in Bug
#403159 Comment #11
Fote
--
Lars-Erik Østerud
> The "logic" for ignoring criticisms such as yours is expressed in Bug
> #403159 Comment #11
Like "use an add-on"?
Why couldn't plain and easy stuff be left as options, instead of
forcing users to write and install add-ons to make things simpler?
FF is a good browser, and FF3 too, but now after the new HUGE icons
(IE7 style) and removal of a fast, small a working drop-down, well...
I think I'm not alone in my views... Why not ask the users first?
Foteos Macrides
> I think I'm not alone in my views...
You most definitely are not alone. See:
Fote
--
Justin Dolske
> Why couldn't plain and easy stuff be left as options, instead of
> forcing users to write and install add-ons to make things simpler?
Because one of Firefox's principles is to NOT add a zillion options in
attempt to please everybody.
I was initially concerned about the new url autocomplete-menu format,
too. It took a little time to adjust to, but I think it's a clear win now.
Justin
Axel Hecht
Just as an arbitrary data point, I'm not. Right now, it's still in the
way of me getting to the locations I want. I type in, forcing me to
ignore the suggestions, and then at some point, I take a deep breath,
and start investigating what's displayed.
Axel
Mike Beltzner
> Just as an arbitrary data point, I'm not. Right now, it's still in the
> way of me getting to the locations I want. I type in, forcing me to
> ignore the suggestions, and then at some point, I take a deep breath,
> and start investigating what's displayed.
Is that the matching algorithm or the display?
I find your arbitrary data point interesting (and saddening) but not
particularly useful in helping me understand what aspect of the design
is getting in your way. I crave more detailed introspection!
cheers,
mike
Martijn
> Lars-Erik Østerud wrote:
>
> > Why couldn't plain and easy stuff be left as options, instead of
> > forcing users to write and install add-ons to make things simpler?
>
> Because one of Firefox's principles is to NOT add a zillion options in
> attempt to please everybody.
There was a pref for it, not an option.
Regards,
Martijn
> I was initially concerned about the new url autocomplete-menu format,
> too. It took a little time to adjust to, but I think it's a clear win now.
>
> Justin
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Seth Spitzer
> Like "use an add-on"?
Yes, that is much better than having a pref, as it prevents code bloat.
I've created an add-on to switch back to the Firefox 2 style, see
https://bugzilla.mozilla.org/attachment.cgi?id=293973
I'll be moving that to addons.mozilla.org
-Seth
Seth Spitzer
> Like "use an add-on"?
Yes, that is much better than having a pref, as it prevents code bloat.
Seth Spitzer
https://addons.mozilla.org/en-US/firefox/addon/6227
Currently in the amo sandbox.
-Seth
Foteos Macrides
> https://addons.mozilla.org/en-US/firefox/addon/6227
> Currently in the amo sandbox.
Thank you, Seth, for making this add-on available yourself as part of the
fix for Bug #407836.
It works with tonight's Minefield, but not with yesterday's Fx3.0b2 release,
even though it's indicated as working with Firefox: 3.0b2pre – 3.0b3pre
Am I mis-understanding what that version span means?
Fote
--
Seth Spitzer
> It works with tonight's Minefield, but not with yesterday's Fx3.0b2 release,
> even though it's indicated as working with Firefox: 3.0b2pre – 3.0b3pre
Good catch.
With 3.0b2, you can still use the browser.urlbar.richResults pref.
I'll fix the add on to only work with 3.0b3pre.
-Seth
Lars-Erik Østerud
Instead of marking the matches with BOLD + underline (looks a bit ugly
I think), how about marking it with a different background color -
just like with "find" ?
Axel Hecht
I think there are two aspects. Probably most prominently, I'm surfing
via URLs, and those get de-emphasized. So I need to look harder to
actually find what I know. The second piece that I find disturbing is
that there seems to be a concurrence between me actually consiously
scanning the suggestions and some timeout that gives me more hits. That
is, as soon as I start reading, the list changes.
I'm having a "too much data" problem, too, I guess. That might come from
not seeding it enough, or the search not being good enough yet. Just
played with it, http://flickr.com/photos/axelhecht/2124897766/, for
"bug", 2 out of 10 links have useful data in the display. It took me a
bit to figure out that the litmus links are in there because those
queries have a "withbugs=all" query param in them.
Oh, and are we going to release note "use a different profile for porn"? ;-)
Axel
Mike Beltzner
> Mike Beltzner wrote:
>> On 19-Dec-07, at 6:19 PM, Axel Hecht wrote:
>>
>>> Just as an arbitrary data point, I'm not. Right now, it's still in
>>> the
>>> way of me getting to the locations I want. I type in, forcing me to
>>> ignore the suggestions, and then at some point, I take a deep
>>> breath,
>>> and start investigating what's displayed.
>>
>> Is that the matching algorithm or the display?
>>
>> I find your arbitrary data point interesting (and saddening) but not
>> particularly useful in helping me understand what aspect of the
>> design
>> is getting in your way. I crave more detailed introspection!
>>
>
> I think there are two aspects. Probably most prominently, I'm surfing
> via URLs, and those get de-emphasized. So I need to look harder to
> actually find what I know. The second piece that I find disturbing is
> that there seems to be a concurrence between me actually consiously
> scanning the suggestions and some timeout that gives me more hits.
> That
> is, as soon as I start reading, the list changes.
OK, I've heard this before, and am working on some ideas to see if we
can make it easier to see the URLs. The design goal here is actually
to make it easier to pick URLs out from this list (since one can see
more of them than before, and they are painted green, as they are in
search results) so it's certainly not good that we're interfering with
that.
> I'm having a "too much data" problem, too, I guess. That might come
> from
> not seeding it enough, or the search not being good enough yet. Just
> played with it, http://flickr.com/photos/axelhecht/2124897766/, for
> "bug", 2 out of 10 links have useful data in the display. It took me a
> bit to figure out that the litmus links are in there because those
> queries have a "withbugs=all" query param in them.
As far as I can tell, that would happen the same way with the less
rich results, the only difference being that you might not be able to
see the matching part of the URL because part of the horizontal space
would be given to a snippet of the page title.
Not matching against query params is an interesting optimization,
though; I think we considered it, but realized that sometimes it would
be useful.
> Oh, and are we going to release note "use a different profile for
> porn"? ;-)
We never have before, I don't see why we'd start now. :)
cheers,
mike
Michael Lefevre
> On 19-Dec-07, at 6:19 PM, Axel Hecht wrote:
>
>> Just as an arbitrary data point, I'm not. Right now, it's still in the
>> way of me getting to the locations I want. I type in, forcing me to
>> ignore the suggestions, and then at some point, I take a deep breath,
>> and start investigating what's displayed.
>
> Is that the matching algorithm or the display?
As another arbitrary data point, I have the beta installed on my computer
at home, and a friend's first reaction on seeing the new drop down was
that the huge text was some sort of accessibility feature for people that
couldn't read normal size text. I agree that the larger-than-normal text
looks a bit weird and clunky.
As for the matching algorithm - it seems pretty good, but is not so great
when you've only typed 1 or 2 letters, so I wonder if flashing up a whole
load of stuff is useful enough to counter the rather distracting effect of
it.
Going in the other direction from simplicity, I feel there is some merit
in Daniel Glazman's thoughts about customisation -
http://www.glazman.org/weblog/dotclear/index.php?post/2007/12/20/Firefox-3b2-address-bar
Quite often I do actually know whether I want a site that I've visited a
lot or a site that I've visited recently or something that I've previously
bookmarked. If, when faced with a lot of results, I could somehow tweak
the matching as I go (by doing something more than typing more letters to
be a found together), that might be good. But I guess that is something
for an extension...
--
Michael
Adam Kowalczyk
> Going in the other direction from simplicity, I feel there is some merit
> in Daniel Glazman's thoughts about customisation -
> http://www.glazman.org/weblog/dotclear/index.php?post/2007/12/20/Firefox-3b2-address-bar
> Quite often I do actually know whether I want a site that I've visited a
> lot or a site that I've visited recently or something that I've previously
> bookmarked. If, when faced with a lot of results, I could somehow tweak
> the matching as I go (by doing something more than typing more letters to
> be a found together), that might be good. But I guess that is something
> for an extension...
Edward Lee is working on what he calls "adaptive learning"[1] which
accomplishes exactly what you are asking for. As far as I know, it is
scheduled to be included in Firefox 3.
- Adam
Mike Beltzner
> Michael Lefevre wrote:
> > Going in the other direction from simplicity, I feel there is some merit
>> in Daniel Glazman's thoughts about customisation -
>> http://www.glazman.org/weblog/dotclear/index.php?post/2007/12/20/Firefox-3b2-address-bar
>> Quite often I do actually know whether I want a site that I've visited a
>> lot or a site that I've visited recently or something that I've previously
>> bookmarked. If, when faced with a lot of results, I could somehow tweak
>> the matching as I go (by doing something more than typing more letters to
>> be a found together), that might be good. But I guess that is something
>> for an extension...
I've heard a lot of people ask for deep customization here, but I think
that's best for extension fodder at the moment. We've been working hard
to keep the performance impact down to a minimum, and it feels like
adding these alternate paths might affect that. Seth might know more.
I will be posting to my blog today or tomorrow with some userChrome.css
hacks that people can use to change the colours, though, so that we can
get some alternate ideas generated.
I do, otoh, like Daniel's idea for Shift-Delete removing a single item
from the history; anyone know if there's a bug on that?
>
> Edward Lee is working on what he calls "adaptive learning"[1] which
> accomplishes exactly what you are asking for. As far as I know, it is
> scheduled to be included in Firefox 3.
>
> - Adam
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=395739
Indeed, changes to the matching algorithms are in the works, and I think
there's a lot more we can do to make sure that the intelligent results
are truly intelligent.
cheers,
mike
Lars-Erik Østerud
> can make it easier to see the URLs. The design goal here is actually
> to make it easier to pick URLs out from this list (since one can see
Enabling the old style with an option to not display the "title"
would do that (a plain drop-down with the icon and the URL - no more).
Make it an option somewhere.
I had allready in my "userChrome.css" for 2.0 made the "title" field
narrower (you can even remove it), and I have found a way to remove
the "title" and adjust the position of the URL in the "rich list" as
well using "userChrome.css" (and negative margins and stuff).
So if you don't include these options, they will still be there,
but harder to get (more tech knowledge) for the non-tech users.
Lars-Erik Østerud
> As another arbitrary data point, I have the beta installed on my computer
> at home, and a friend's first reaction on seeing the new drop down was
How will this new two-line complicated drop-down work for those using
tools for blind (reading lists) or poor-sight (high contrast, huge
font). I would think the old style was much better for those?
Mike Beltzner
> Make it an option somewhere.
Adding an option is not free; it adds code bloat and creates additional
testing paths, and in cases where the option is user facing, it adds
information that the user must parse when looking for a certain
preference or option that they actually care about.
So far I haven't heard a convincing argument about why this needs to be
an option as opposed to an add-on.
> I had allready in my "userChrome.css" for 2.0 made the "title" field
> narrower (you can even remove it), and I have found a way to remove
> the "title" and adjust the position of the URL in the "rich list" as
> well using "userChrome.css" (and negative margins and stuff).
>
> So if you don't include these options, they will still be there,
> but harder to get (more tech knowledge) for the non-tech users.
Non-tech users don't care about URLs as much as they care about page titles.
cheers,
mike
Adam Kowalczyk
> Non-tech users don't care about URLs as much as they care about page
> titles.
I don't think that's strictly true, FWIW. I would agree that they don't
usually understand the entire structure of URLs. However, they are
certainly familiar with domains, nowadays when many printed adverts
include website addresses and the phrase "visit goats-insurance dot com"
attacks us a dozen times a day. I see plenty of people calling websites
by their domains. I suppose this happens especially in cases of websites
which don't have clear, memorable, or concise names, which makes it
easier to just use their domains instead.
Based on these observations, I think that non-tech users type domains in
their Location Bars all the time.
- Adam
Axel Hecht
> Lars-Erik Řsterud wrote:
>> Make it an option somewhere.
>
> Adding an option is not free; it adds code bloat and creates additional
> testing paths, and in cases where the option is user facing, it adds
> information that the user must parse when looking for a certain
> preference or option that they actually care about.
>
> So far I haven't heard a convincing argument about why this needs to be
> an option as opposed to an add-on.
I'm not convinced that putting the blame on an extension author is
helping here. If QA tests an option or if QA tests another overly
popular extension is probably a loose-loose situation.
Anyway, from what I see, there's data that indicates that the awesomebar
needs work, and there are bugs open to work on it. I would think that
there are likely some scenarios to be looked at and designed for in this
thread, and I just rest assured that that's happening. The wording in
the last half-sentence is wrong, but I wouldn't even have some German
for beltzner here in my head right now.
I think that Firefox is about coming up with the most usable solution
beneficial to a large audience, laying ground for extensions to cover
niches. I don't think the awesomebar is there yet. It's currently
showing everything that could be relevant and of interest, and not
showing what's of interest while giving an opportunity to go beyond.
Again, I'm sure that some mix of brains, cookies and punch will get us
ahead here, and if anything else fails, the UX team can still shave :-)
Axel
Lars-Erik Østerud
> testing paths, and in cases where the option is user facing, it adds
Given how easy it is to add the "old-style" url-auto-complete I guess
the code is not huge. And the old-style auto-complete is used other
places. Also it was there, was tested, worked. You even added an
option to use the old one in "about:config". Then why remove it again?
> Non-tech users don't care about URLs as much as they care about page titles.
I my world, we only use URLs. Title are useless (very often) over here
Lars-Erik Østerud
> Based on these observations, I think that non-tech users type domains in
> their Location Bars all the time.
Second that. Have NEVER seens any of my friends (very non-tech) use
anything other than URL. Most don't even know that is possible :-)
Michiel van Leeuwen
> Non-tech users don't care about URLs as much as they care about page
> titles.
So non-tech users have to ignore every other line (the one with the url)
while scanning the list. Users that prefer url's have to do the same. To
me, that sounds non-optimal in both cases. Having the title and the url
in two columns would make it easier for both.
Michiel
Mike Beltzner
> So non-tech users have to ignore every other line (the one with the url)
> while scanning the list. Users that prefer url's have to do the same. To
> me, that sounds non-optimal in both cases. Having the title and the url
> in two columns would make it easier for both.
Except for the part where you can't read either since they're both clipped.
cheers,
mike
Foteos Macrides
>> titles.
>
> I my world, we only use URLs. Title are useless (very often) over here
> --
> Lars-Erik - http://www.osterud.name - ICQ 7297605
> My Firefox tweaks: http://osterud.name/firefox.html
Lars-Erik,
I suspect that much of this debate might become moot if it weren't for those
titles in Fx3.0b2 and Minefield screaming at you and making it difficult to
focus on the URLs.
Since your site is already offering add-ons, and you earlier indicated that
you had been able to change the formatting in the "rich list" using
userChrome.css, it might be useful to gather some empirical data. How about
offering an add-on which makes the titles the same font-size as the URLs
(still with color:black versus color:green) and valigns the shortcut icon
with respect to both lines so that it doesn't necessitate a greater
line-height for the titles. Perhaps you could also provide a screen-shot
with that formatting as an attachment in Bug 406215.
We might then conduct a survey with questions such as:
1. Which format do you prefer?
2. Are you a so-called "non-tech" or "not non-tech" person?
3. If a "non-tech" person, have you nonetheless learned enough about URL
structure to pay attention to URLs for protection against phishing and
identity theft?
4. Have you noticed that in Google hit lists, the titles have a larger
font-size than the URLs, but they are never opposed, and instead always have
color:black text with the same font-size as the color:green URLs interposed?
5. Do you think it would be unfortunate if the formatting of the urlbar
dropdown in Fx3.0b2 and the current Minefield, and the so-called "need to
get used to it" interfered with a broader appreciation of the Fx3+
autocomplete and all the work which the Fx developers put into it?
Fote
--
Lars-Erik Østerud
> I suspect that much of this debate might become moot if it weren't for those
> titles in Fx3.0b2 and Minefield screaming at you and making it difficult to
> focus on the URLs.
Also I have tweaked a little to make it fit more into my "look":
/* FF3 URL-dropdown */
richlistitem spacer,richlistitem label{display:none!important}
.ac-title{margin:-4px 8px 2px -4px!important}
.ac-url{margin:-6px 0px 0px 20px!important}
Would be nice combining the best of the old and the new look !!!
BTW: The search highlight with bold+ul does not look good :-(
> offering an add-on which makes the titles the same font-size as the URLs
> (still with color:black versus color:green) and valigns the shortcut icon
> with respect to both lines so that it doesn't necessitate a greater
I have been thinking about setting down the font-size in
"userChrome.css", but fear that will not work OK with different
Windows font settings (as you have to set a fixed size).
I'm thinking of moving both back on one line with some CSS entries,
getting the old look back, but WITH the search-highlight (and without
the lines between each entry). I'll experiment some more :-)
> We might then conduct a survey with questions such as:
I'm all in favour of surveys.
I think to many programs (like MS Vista and the new Office suits) are
to much designed for the casual user, and not for the "mass"-user
(those that work with IT all day - the new UIs are annoying for us).
Lars-Erik Østerud
> Except for the part where you can't read either since they're both clipped.
But screens get wider and wider, and with the ability to search from
the URLbar maybe the search-bar is not for any use. Then you have
width to use...
Lars-Erik Østerud
richlistitem spacer,richlistitem label{display:none!important}
richlistitem{border:none!important}
.ac-title{margin:-4px 0px 0px
300px!important;background:solid!important}
.ac-title
description{font-size:11px!important;color:ThreeDShadow!important}
.ac-title description[selected="true"]{color:white!important}
.ac-url{margin:-19px 0px 0px 20px!important}
.ac-url description{color:black!important}
.ac-url description[selected="true"]{color:white!important}
BUT I have trouble with the width of the "title" and "url".
No matter what attibute I set the width is not restricted.
And then the text overlap each other, not looking good :-(
Also I have to set a fixed startpoint for the "title" (300px).
A variable one (a percantage) would be better to suit more screens
Mike Beltzner
> I tried this, and it looks quite OK (try it and see :-):
>
> richlistitem spacer,richlistitem label{display:none!important}
> richlistitem{border:none!important}
> .ac-title{margin:-4px 0px 0px
> 300px!important;background:solid!important}
> .ac-title
> description{font-size:11px!important;color:ThreeDShadow!important}
> .ac-title description[selected="true"]{color:white!important}
> .ac-url{margin:-19px 0px 0px 20px!important}
> .ac-url description{color:black!important}
> .ac-url description[selected="true"]{color:white!important}
>
> BUT I have trouble with the width of the "title" and "url".
> No matter what attibute I set the width is not restricted.
> And then the text overlap each other, not looking good :-(
>
> Also I have to set a fixed startpoint for the "title" (300px).
> A variable one (a percantage) would be better to suit more screens
Thanks for playing around with the settings, Lars. That's helpful. For
people who might not know how to play with userChrome.css, can you also
put out screenshots?
cheers,
mike
Foteos Macrides
> Would be nice combining the best of the old and the new look !!!
> BTW: The search highlight with bold+ul does not look good :-(
> I'm thinking of moving both back on one line with some CSS entries,
> getting the old look back, but WITH the search-highlight (and without
> the lines between each entry). I'll experiment some more :-)
Seth's oldbar add-on meets my basic need for an easy way to switch between
the new default, vertically-stacked format and a compact, horizontal format
which lets me focus unencumbered on the URLs. Since it does retain the
autocomplete, I guess it would be nice to also have the search-highlight.
But that's not a big issue for me, personally, and I'll remain content if
Seth simply keeps updating the version restriction and does any necessary
tweaking of it for successive releases.
I completely agree with you, though, that the bold+ul is inadequate, and it
would be much better to make that the same as for "Highlight all" in the
Find searches. But some outstanding bugs indicate that efficiency and RTL
issues still need to be overcome.
Fote
--
Lars-Erik Østerud
> richlistitem{border:none!important}
> .ac-title{margin:-4px 0px 0px 300px!important;background:solid!important}
> .ac-title description{font-size:11px!important;color:ThreeDShadow!important}
> .ac-title description[selected="true"]{color:white!important}
> .ac-url{margin:-19px 0px 0px 20px!important}
> .ac-url description{color:black!important}
> .ac-url description[selected="true"]{color:white!important}
Here is the screenshot for the code above:
http://osterud.name/RichBar1.png
If anyone can help with how to restrict the width of the text
so it does not overlap each other or the "star" icon, please tell me
> richlistitem spacer,richlistitem label{display:none!important}
> .ac-title{margin:-4px 8px 2px -4px!important}
> .ac-url{margin:-6px 0px 0px 20px!important}
And here is the compacted version of the two-line display
by the code above: http://osterud.name/RichBar2.png
Both are adjusted so that margins and stuff fits with the tweaked
menu/urlbar in the userChrome.css at http://osterud.name/firefox.html
Dave Townsend
> Mike Beltzner wrote:
>
>> Except for the part where you can't read either since they're both clipped.
>
> But screens get wider and wider, and with the ability to search from
> the URLbar maybe the search-bar is not for any use. Then you have
> width to use...
Numbers vary depending on exactly where you get your stats from of
course, but 1024x768 is still the most popular screen size on the web.
Apparently nearly 1 in 7 users are still on 800x600. Heck if you're
talking physical monitor size, mine hasn't changed in around 7 years :(
Dave
Lars-Erik Østerud
> Numbers vary depending on exactly where you get your stats from of
> course, but 1024x768 is still the most popular screen size on the web.
> Apparently nearly 1 in 7 users are still on 800x600. Heck if you're
> talking physical monitor size, mine hasn't changed in around 7 years :(
Of course I know :-) That why I have made the "minimized" userChrome
But still. I think that even at 1024x768 the old style dropdown is OK
IF you can loose the searchbar (you can search from the urlbar so it's
not really any need for it anymore, right), then you have even more
Foteos Macrides
> And here is the compacted version of the two-line display
> by the code above: http://osterud.name/RichBar2.png
That's an improvement over the current spaciness. The shortcut icon drops
down to overlap with the URL and visually ties it with the title so that you
don't need the horizontal lines, which also interfere with scanning the
list. If the title could be made to have the same font-size as the URL then
that would work out yet better.
Fote
--
Foteos Macrides
> IF you can loose the searchbar (you can search from the urlbar so it's
> not really any need for it anymore, right), then you have even more
Hmm... I thought that the autocomplete urlbar search is of copy-and-pasted
URLs plus other available browsing history, and one's bookmarks, whereas the
searchbar is for a search-engine's database of the entire web (or as much of
it as the engine has walked). These are fundamentally different and both
desired. It's true that many users enter "domains" in the searchbar (NOT
titles, but the host field of a URL) for a "quick" link to a frequented
site, and the urlbar search can do that more quickly. Otherwise the urlbar
and searchbar are not interchangeable, but correct me if I'm wrong.
For Fx3 there is a slidebar-handle between the urlbar and searchbar, so you
can quickly change their relative widths, if needed, depending on which one
you are using. In Fx2 I moved the searchbar up, so that the urlbar can fill
the entire width of the window. There was some bogus discussion earlier
about that in relation to bar heights and inferred platform conventions, but
I use the small icons without text, and the bar heights are just fine and
dandy (plus being unconventional doesn't bother me :<). You can still do
that with Fx3 if you should find its slidebar-handle feature inadequate.
Fote
--
Lars-Erik Østerud
> down to overlap with the URL and visually ties it with the title so that you
> don't need the horizontal lines, which also interfere with scanning the
> list. If the title could be made to have the same font-size as the URL then
Looks weird without the horizontal lines with two line model :-(
Here's an image of this code:
richlistitem spacer,richlistitem label{display:none!important}
richlistitem{border:none!important}
.ac-title{margin:-7px 8px 2px -4px!important}
.ac-title description{font-size:11px!important}
.ac-url{margin:-8px 0px 0px 20px!important}
With and without the horizontal lines:
URL: http://osterud.name/RichBar3.png
Foteos Macrides
> Looks weird without the horizontal lines with two line model :-(
>
> Here's an image of this code:
> With and without the horizontal lines:
>
> URL: http://osterud.name/RichBar3.png
Oh wow!!! I love it with the same font-sizes and no horizontal lines. I
know what I'm looking for in such lists, and I can scan for it much more
quickly that way, then scroll down to it when I have that hit.
Can you make that a standard add-on and put it in the sandbox so I can use
it as the complement for Seth's oldbar add-on (or do I have to figure out
how to create add-ons myself :<)?
BTW, though you have indicated that you would prefer an Option solution for
this issue, with the Fx3 Add-ons Menu, which has a Disable/Enable button for
each entry, plus a Find Updates button and a Restart Browser button at the
bottom, it is much faster and easier to change the behavior than if one has
to plow through a set of Options Menus.
Of course, if the Add-ons entries increase to encompass as many choices as
the Options Menus do . . .
Fote
--
Lars-Erik Østerud
> Can you make that a standard add-on and put it in the sandbox so I can use
> it as the complement for Seth's oldbar add-on (or do I have to figure out
I'm no good with add-ons, only with userChrome.css hacks :-/
But if you cut the code from the message, save it as "userChrome.css"
and put it in the "CHROME" folder inside the profile folder, then...
> BTW, though you have indicated that you would prefer an Option solution for
> this issue, with the Fx3 Add-ons Menu, which has a Disable/Enable button for
> each entry, plus a Find Updates button and a Restart Browser button at the
> bottom, it is much faster and easier to change the behavior than if one has
> to plow through a set of Options Menus.
yes, but as I said, I have no experience in making add-ons (yet) :-(
Lars-Erik Østerud
> URLs plus other available browsing history, and one's bookmarks, whereas the
Try typing a search critera in the URL-bar and hit enter.
Here that launches the search page with that search-critera.
But I don't know if that is enabled as default
(I have added som "user.js" settings that might do something).
Anyway, it IS possible to set it up to serch from the URL-bar.
And here it works like this..
1) when you start typing you get the auto-complete list with
the matches in the URL and TITLE, and can click on one of
them, or....
2) Just press enter to search for the phrase using the search-engine
(now, if the phrase is just one word the default is to add
"http://" so it must have a space, or you must alter some setting)
But why have two fields if one is enough?
> For Fx3 there is a slidebar-handle between the urlbar and searchbar, so you
> can quickly change their relative widths, if needed, depending on which one
I know, had a bit if trouble making that look good in my "userChrome"
tweak :-) But I thing the result got OK so far. It's a neat addition
Frank
> How will this new two-line complicated drop-down work for those using
> tools for blind (reading lists) or poor-sight (high contrast, huge
> font). I would think the old style was much better for those?
> --
> Lars-Erik - http://www.osterud.name - ICQ 7297605
> My Firefox tweaks:http://osterud.name/firefox.html
Hi Lars-Erik, this two-line dropdown will work fine for the visually
disabled. Although not visually impaired myself, I'm the guy that made
the Metal Lion HiViz Sidebar for the visually disabled and I see no
problem here.
The point, it seems to me, that many here are missing is this. If you
have a single line, limited to the width of the urlbar, then both
entries on that line need to be truncated (shortened) to fit. This
makes those 2 entries useless to anyone who uses an even remotely
narrow urlbar width. The url address shown is particularly useless
when truncated. I want to stress this point again - the dropdown is
useless in that format, people cannot read the full bookmark name and
certainly cannot read most of an url address. It is a total waste of
space like that, visually impaired or otherwise.
However, the richlist 2 line system not only shows more of those
entries on an urlbar of the same width proportion as above, but also
readily lends itself to being able to untruncate both line entries
outside the width of the urlbar, where they may be viewed in full, if
required, with the addition of a horizontal scrollbar. Not just one
pair of entries, but all of them. You then have a dropdown that
actually achieves some functionality.
Frank
> I my world, we only use URLs. Title are useless (very often) over here
It takes about 30 seconds for a themer to write the code for the 2
line entry text, in any combination of px size or colour.
By default, my own stuff gives priority to the entry Title, in terms
of colour, font-weight and px size. One single line in userChrome.css
could then turn that priority to the Url address if necessary,
whatever the user preferred. I suppose someone could even bring out an
extension with a single line of css to do it.
We ain't exactly talking no complicated coding here. :)
Foteos Macrides
> Try typing a search critera in the URL-bar and hit enter.
That yielded a Google search, even if I used only one word, and the word
also generated autocomplete hits.
> But why have two fields if one is enough?
The searchbar lets you choose other search engines. But if I search the web
maybe I'll find info on how to do that via the urlbar as well. Then one
indeed could use Customize to remove the searchbar. Hmm. But the searchbar
also has a Suggestions dropdown.
Anyway, at this point I'm going to start playing with userChrome.css and
hope that I don't blow up the browser (like a "non-tech" person :<).
Fote
--
Foteos Macrides
> Anyway, at this point I'm going to start playing with userChrome.css and
> hope that I don't blow up the browser (like a "non-tech" person :<).
I created a userChrome.css in the chrome directory of Minefield's profile,
with the namespace url from the example file, followed by:
richlistitem spacer,richlistitem label{display:none!important}
richlistitem{border:none!important}
.ac-title{margin:-7px 8px 2px -4px!important}
.ac-title description{font-size:11px!important}
.ac-url{margin:-8px 0px 0px 20px!important}
and now the default (vertically-stacked) urlbar dropdown formatting is
exactly as I'd like that. Also, the browser did not blow up.
However, when I invoke the Add-ons Menu to try switching to the horizontal
display via Seth's oldbar add-on, all of the add-on entries are gone. How
do I get them back?
Fote
--
David McRitchie
On Dec 20, 5:42 pm, Lars-Erik Řsterud <.@.> wrote:
> How will this new two-line complicated drop-down work for those using
> tools for blind (reading lists) or poor-sight (high contrast, huge
> font). I would think the old style was much better for those?
> --
> Lars-Erik - http://www.osterud.name - ICQ 7297605
> My Firefox tweaks:http://osterud.name/firefox.html
Hi Lars-Erik, this two-line dropdown will work fine for the visually
disabled. Although not visually impaired myself, I'm the guy that made
the Metal Lion HiViz Sidebar for the visually disabled and I see no
problem here.
The url address shown is particularly useless when truncated.
Hi Frank, (doesn't look like I am replying to plain text)
There is usually enough information on the one line version to
help you remember what you were looking at at some other
time, along with the favicon, and if FF 3, the star which would
show if it is bookmarked. Of course if it were builtin to Firefox
we could as for a context menu with full properties. Wonder if it
is possible to bring up the properties menu like in bookmarks.
--
HTH,
David McRitchie,
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/firefox.htm
Foteos Macrides
> However, when I invoke the Add-ons Menu to try switching to the horizontal
> display via Seth's oldbar add-on, all of the add-on entries are gone. How
> do I get them back?
Here's another data point. I removed the userChrome.css file from the
Minefield profile's chrome directory, restarted Minefield, and all of the
former Add-ons Menu entries were present and operational again. So I
enabled Seth's oldbar add-on, put userChrome.css back into the chrome
directory, and re-started Minefield. The urlbar dopdown now has the
horizontal formatting which the oldbar add-on produces, but the Add-ons Menu
again doesn't show that entry nor any of the others.
Fote
--
Frank
> Hi Frank, (doesn't look like I am replying to plain text)
> There is usually enough information on the one line version to
> help you remember what you were looking at at some other
> time, along with the favicon, and if FF 3, the star which would
> show if it is bookmarked. Of course if it were builtin to Firefox
> we could as for a context menu with full properties. Wonder if it
> is possible to bring up the properties menu like in bookmarks.
Hi David,
I know exactly what you mean, but 'usually' just does not cut it on
good UI, nor does having to piece bits together to remember things,
haha. You're right, of course, often there is no problem, but let's do
an example. A guy bookmarks 3 pages for the same site, most of those
titles or urls look just the same...apart from just the very last bit,
which the guy now cannot see. Then he has 2 choices, widen the urlbar
or hover over each to get to full description tooltip. That can't be
right.
Give the guy a 2 liner there is a good chance he could see, at least,
those titles in full. Even if he cannot, if you have untruncated those
entries, as I have, he only then has one slight horizontal scrollbar
move to do, to definitely see all 3 in full, all at the same time and
make the selection. Plus, if you theme it right, it doesn't look
confusing at all. Honestly, it looks OK.
The Devs got the first bit right by doing the 2 liner, then boxed
themselves in a corner. Which was 'how do we untruncate this lot and
show it in full, without the stars/tags zigzagging all over the place
at the ends of uneven length entries?' They wanted the stars in a
straight vertical column. At that point, they sorta gave up,
haha...went back to truncating the entries (which then holds the Star
in position) and scrubbed the horizontal scrollbar. The result is
better than the one line job, but nowhere near as good as it should
be.
The trick is - untruncate the entries, put back the horiz scroll and
change the ordinal order (haven't fully cracked that one yet, but
mockups look great) to put the Star/Tag under the favicon on the left.
Apart from the other advantages that I've already outlined, doing this
stops the eyes swivelling from left to right from favicon to Star to
see if that entry is a bookmark or history item. Put it under the
favicon and you can see that instantly. Plus, of course, you retain
straight vertical column of the Star/tags.
Even if the Devs just left the Title line as is, untruncated the url
address and put the horiz scroll back, it would still be much more
useful than it is, at the moment. Remember, I've got no axe to grind
here...my stuff will look and work fine, whatever they decide to
do. :)
Foteos Macrides
> richlistitem spacer,richlistitem label{display:none!important}
> richlistitem{border:none!important}
The problem appears to be that the Add-ons Menu is a rich list, so adding
that messes it up.
Fote
--
David McRitchie
"Foteos Macrides" <fot...@hotmail.com> wrote in message news:0cSdnSmmeeWhAvHa...@mozilla.org...
Glad you noticed that, can't have add-ons with no text, so all I need then is...
/* FF3 URL-dropdown, Lars-Erik Řsterud, 2007-12-21, revert awsomebar to Ff2,
http://google.com/groups?threadm=b6qdnYdC8JgZiPHa...@mozilla.org */
.ac-title{margin:-4px 8px 2px -4px!important}
.ac-url{margin:-6px 0px 0px 20px!important}
and am perfectly happy with the single line items, and my url bar is very wide and the
font size is very small so that is why I don't see the problem of hiding anything. Being
able to see things close together is what is important to me, and everything lines up.
I wasn't seeing boldface in the expanded version anyway.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2 ID:2007121120
Lars-Erik Østerud
OK, look into that. Probably need another prefix then.
Tried just adjusting the height, but that didn't help.
Lars-Erik Østerud
replace the lines above with:
.autocomplete-richlistitem spacer,.autocomplete-richlistitem
label{display:none!important}
Then the add-ons box will not be messed up.
Also I found that instead of removing the border (horizontal lines)
it look quite good by toning them down from black to light-grey:
richlistitem{border-color:ThreeDHighlight!important}
I haven't changed the prefix here as I think this looks good for the
add-ons as well, but if you use "border:none" you should use:
.autocomplete-richlistitem{border:none!important}
or else you will remove the horizontal lines in add-ons as well
Lars-Erik Østerud
> The searchbar lets you choose other search engines. But if I search the web
> maybe I'll find info on how to do that via the urlbar as well. Then one
OK, I never change that. I have made a search-page that searched with
4 engines at once. So then I never change the setting.
Try it here: http://search.osterud.name
Lars-Erik Østerud
> richlistitem spacer,richlistitem label{display:none!important}
> richlistitem{border:none!important}
> .ac-title{margin:-7px 8px 2px -4px!important}
> .ac-title description{font-size:11px!important}
> .ac-url{margin:-8px 0px 0px 20px!important}
> However, when I invoke the Add-ons Menu to try switching to the horizontal
> display via Seth's oldbar add-on, all of the add-on entries are gone. How
> do I get them back?
Change all "richlistitem" to ".autocomplete-richlistitem". My fault.
Foteos Macrides
>> richlistitem spacer,richlistitem label{display:none!important}
>> richlistitem{border:none!important}
>> .ac-title{margin:-7px 8px 2px -4px!important}
>> .ac-title description{font-size:11px!important}
>> .ac-url{margin:-8px 0px 0px 20px!important}
>
>> However, when I invoke the Add-ons Menu to try switching to the
>> horizontal
>> display via Seth's oldbar add-on, all of the add-on entries are gone.
>> How
>> do I get them back?
>
> Change all "richlistitem" to ".autocomplete-richlistitem". My fault.
Perfect! I also made the .ac-title description color:grey!important, which
for my eyes further improves both "scan-ability" and readability (less is
more, IMHO), makes the present bold+ul for the hit string more readily
detectable (though an emulation of the "Highlight all" of Find searches
still would be better), and the oldbar add-on even more-so a "quickie
switch" to the vertically-stacked display without unwanted distractions if
there's clipping in the horizontal display and I need to see what's been
clipped. An earlier comment in this thread that there should be an
overflow:auto for a horizontal scrollbar as well as the vertical one struck
me as overkill initially, but I guess does make sense in this context.
It might be fun trying to roll that userChrome.css editing and oldbar into
an equivalent format-switching add-on but which has highlighting in both the
horizontal and vertically-stacked formats, but it may be pre-mature to
attempt that before the highlighting mechanism is finalized. I don't know
if this is intentional, but at present the hit string is highlighted in the
URL only if it is not also a hit in the title. Otherwise, it's highlighted
only in the title.
Fote
--
Foteos Macrides
> Perfect! . . .
Although the userChrome.css edits we've been discussing all do work
perfectly for Minefield, with Fx3.0b2 including:
.autocomplete-richlistitem label{display:none!important}
creates a situation such that as one enters letters in the urlbar, instead
of highlighting them in the dropdown they are deleted from the titles or
URLs which contain them.
Obviously this is no longer a problem in the trunk code, but I thought I'd
mention it in case it was not known and there is a regression during further
development of the autocomplete feature.
Fote
--
Lars-Erik Østerud
> Although the userChrome.css edits we've been discussing all do work
> perfectly for Minefield, with Fx3.0b2 including:
>
> .autocomplete-richlistitem label{display:none!important}
>
> creates a situation such that as one enters letters in the urlbar, instead
> of highlighting them in the dropdown they are deleted from the titles or
> URLs which contain them.
Could you describe that more, as I havn't seen that.
One could prefix "label" better, but to get lower line height
I found I had to remove them as I didn't succeed changing the height
(no height and width settings seems to work for richlist items, why?)
Lars-Erik Østerud
If the phrase you are typing in the URL field exist BOTH in the page
title AND the URL then it is only higlighted in the title...
I think it should be higlighted ALL places it exist.
Lars-Erik Østerud
I have several entries in history for "play.com"
If I type "play" slowly in the URL field I get a dropdown list.
BUT if I type fast "play" I get a list with no entries.
If I remove the last "y" afterwards, then type it again it shows.
Seems like something is not matching my typing speed :-)
Seems like the lists needs to complete for each letter before
you type the next, or else the list just disappears :-(
Foteos Macrides
>> Although the userChrome.css edits we've been discussing all do work
>> perfectly for Minefield, with Fx3.0b2 including:
>>
>> .autocomplete-richlistitem label{display:none!important}
>>
>> creates a situation such that as one enters letters in the urlbar,
>> instead
>> of highlighting them in the dropdown they are deleted from the titles or
>> URLs which contain them.
>
> Could you describe that more, as I havn't seen that.
To track down the culprit I put:
.autocomplete-richlistitem spacer{display:none!important}
/*
.autocomplete-richlistitem label{display:none!important}
*/
.autocomplete-richlistitem{border:none!important}
.ac-title{margin:-7px 8px 2px -4px!important}
.ac-title description{font-size:11px!important}
.ac-title description{color:grey!important}
.ac-url{margin:-8px 0px 0px 20px!important}
in the userChrome.css for Gran Paradiso (currently Fx3.0b2). Uncomment the
culprit to see the bug (that CSS rule IS needed for the intended format to
occur fully, but yields the deletion bug).
Fote
--
Lars-Erik Østerud
> in the userChrome.css for Gran Paradiso (currently Fx3.0b2). Uncomment the
Don't have the b2 here, only the latest b3pre :-(
Foteos Macrides
>> in the userChrome.css for Gran Paradiso (currently Fx3.0b2). Uncomment
>> the
>
> Don't have the b2 here, only the latest b3pre :-(
Right, the bug is gone in the trunk code (b3pre), though when reading the
gazillion bugs filed for the autocomplete feature and its dropdown
formatting, I didn't see one which seemed related to this.
The deletions, when present, are the same as would occur for the bold+ul
highlighting. It's obvious that the title is being scanned before its
associated URL, and the scan stops as soon as there is a hit in either of
the pair. So you don't get highlighting (or deletion) in the URL if there
is a hit in its title, and if there is more than one occurrence in the
title, only the first gets highlighted (or deleted).
Fote
--
Foteos Macrides
lines which are pale so that the bold+ul highlighting is readily detectable:
.ac-title description{font-size:11px!important;color:#4488cc!important}
That works well, and in conjunction with the default pale-green URLs should
be OK w.r.t. colorblindness issues -- but please correct me if I'm wrong. I
also tried making the separator lines very-pale-green:
.autocomplete-richlistitem{border-color:#ddeecc!important}
and that works well, too, making them less of a distraction when scanning
the list. But as in Google hit lists I'd like to try removing the separator
lines:
.autocomplete-richlistitem{border:none!important}
and instead underlining the pale-blue titles. I tried:
.ac-title description{text-decoration:underline!important}
but it didn't work, nor does:
.autocomplete-richlistitem{text-decoration:underline!important}
Is there CSS for userChrome.css which does yield underlining of the titles?
Fote
--
Foteos Macrides
.autocomplete-richlistitem label{display:none!important}
in the userChrome.css rules we've been discussing, if the title or URL is
clipped we no longer get an ellipsis at the end of the string to make clear
that it's not the complete title or URL. Is there a tweak we can use to
retain the ellipsis?
Fote
--
Lars-Erik Østerud
> .autocomplete-richlistitem label{display:none!important}
>
> that it's not the complete title or URL. Is there a tweak we can use to
> retain the ellipsis?
I would like a way to set the max height etc instead...
I'll do some experimenting when I have time...
Foteos Macrides
> I would like a way to set the max height etc instead...
> I'll do some experimenting when I have time...
OK, I'll keep my fingers crossed. In the meantime, here's a screenshot:
http://www.macridesweb.com/oltest/urlbarCompactVertical.png
for these userChrome.css rules:
/*
* Compact vertical urlbar dropdown
*/
.autocomplete-richlistitem spacer,.autocomplete-richlistitem
label{display:none!important}
.autocomplete-richlistitem{border-color:#ddeecc!important}
.autocomplete-richlistitem[selected="true"]{background-color:#66aaee!important}
.ac-title{margin:-7px 4px 2px -4px!important}
.ac-title description{font-size:11px!important;color:#4488cc!important}
.ac-title description[selected="true"]{color:white!important}
.ac-url{margin:-8px 0px 0px 20px!important}
with a window width of 800px (thus showing the best that one of the approx.
20% of users still stuck with a SuperVGA monitor would see, unless s/he
moved the searchbar up, or removed it). One of the URLs with a long Google
Search query string is clipped, with no ellipsis to indicate that.
I like that vertical display, but when focusing on URLs I still prefer to
use Seth's oldbar add-on for setting autocompletepopup to PopupAutoComplete
instead of PopupAutoCompleteRichResult. I added this userChrome.css rule:
/*
* Compact horizontal urlbar dropdown via oldbar add-on
*/
#PopupAutoComplete>.autocomplete-tree{color:green!important;}
to make the URLs pale-green as in the vertical display, but I haven't
figured out how to make the titles pale-blue instead of grey.
Based on the comments in Bug 399664
(https://bugzilla.mozilla.org/show_bug.cgi?id=399664)
there's no prospect for using highlighting with PopupAutoComplete, and it
could be a long time (if ever) that the highlighting might be other than
bold+ul and only for the first hit in each line pair with
PopupAutoCompleteRichResult.
Fote
--
Foteos Macrides
> to make the URLs pale-green as in the vertical display, but I haven't
> figured out how to make the titles pale-blue instead of grey.
Got it. Here's the screenshot:
http://www.macridesweb.com/oltest/urlbarCompactHorizontal.png
and here are the userChrome.css rules:
/*
* Compact horizontal urlbar dropdown via oldbar add-on
*/
#PopupAutoComplete>.autocomplete-tree{color:green!important;}
.autocomplete-treebody::-moz-tree-cell-text(treecolAutoCompleteComment)
{color:#4488cc!important}
.autocomplete-treebody::-moz-tree-cell-text(selected)
{color:white!important}
treechildren.autocomplete-treebody::-moz-tree-row(selected)
{background-color:#66aaee!important}
Fortunately, approx. 80% of us are not stuck with SuperVGA monitors and
would be using a wider window, but note in that screenshot that any clipped
URLs or titles do have an ellipsis.
Fote
--
Lars-Erik Østerud
/* FF3 2 line URL-dropdown */
.autocomplete-richlistitem spacer,.autocomplete-richlistitem
label{display:none}
.autocomplete-richlistitem{border-color:ThreeDHighlight!important;padding-top:4px!important}
.ac-title{margin:-15px 6px 0px -4px!important}
.ac-title description{font-size:11px!important}
.ac-url{margin:-12px 6px 0px 20px!important}
A screenshot on the look is here: http://osterud.name/RichBar4.png
PS! One thing I noted. When forwarding is used (I use the
"osterud.name" domain, and they forward that to "gethome/~larse") the
browser does not remeber the title. Apparantly that is stored before
the forward..... or.... Anyhow... It doesn't work as you see...
Foteos Macrides
> OK, here is the latest version of the "richResults" tweak:
Thanks for the revised margin rules. They now yield perfect vertical
alignment of each shortcut icon with respect to its title and URL pair.
> .autocomplete-richlistitem spacer,.autocomplete-richlistitem
> label{display:none}
That's still blowing off indications of clipped lines via ellipses (but I
also can live with that in exchange for the much more desirable
formatting :<). The reserving of space for ellipses in the
PopupAutoCompleteRichResponse urlbar dropdown (instead of
substitutions of ellipses for characters at ends of lines only when
needed) appears to have been due to efficiency and rtl issues when
adding highlighting in the hits Substitution instead of reserving space
is used in urlbar searches with PopupAutoComplete and in searches
of history via the Library module, which do not highlight. Seth has a
patch for PopupAutoCompleteRichResponse so that the first hits in
both the title and URL get highlighted if both members of the pair
contain the query string, and hopefully that will get into the trunk soon.
Fote
--
Lars-Erik Østerud
> > .autocomplete-richlistitem spacer,.autocomplete-richlistitem
> > label{display:none}
>
> That's still blowing off indications of clipped lines via ellipses (but I
> also can live with that in exchange for the much more desirable
I know. But they are hard to align since they for some reason son't
follow the margin of the container (why not), and why do they steal
space when not visible (couldn't the with be adjusted and the "..."
shown only when needed). I guess it's a matter of personal opinion.
> both the title and URL get highlighted if both members of the pair
> contain the query string, and hopefully that will get into the trunk soon.
Nice :-)
Foteos Macrides
>> > .autocomplete-richlistitem spacer,.autocomplete-richlistitem
>> > label{display:none}
>>
>> That's still blowing off indications of clipped lines via ellipses (but I
>> also can live with that in exchange for the much more desirable
>
> I know. But they are hard to align since they for some reason son't
> follow the margin of the container (why not), and why do they steal
> space when not visible (couldn't the with be adjusted and the "..."
> shown only when needed). I guess it's a matter of personal opinion.
For the autocomplete searches via the history or bookmarks sidebar,
and for history or bookmarks via the Library module, if there is clipping
then the complete title or url is displayed as a tooltip when one hovers
over the string (link).
This is a basic PopupAutoComplete feature, and thus is also true for the
urlbar searches if you switch those to PopupAutoComplete via Seth's
oldbar add-on: https://addons.mozilla.org/en-US/firefox/addon/6227
The feature should be implemented for PopupAutoCompleteRichResponse
as well, but I haven't seen a bug filed for that. Perhaps it's buried in
terminology that caused me to miss it. If nobody posts an existing bug
number, I'll file a bug report.
Fote
--
Foteos Macrides
> BTW: The search highlight with bold+ul does not look good :-(
I got a chance to play with that today. In the autocomplete.xml
binding, the highlighting for the title and URL each are set up via
html:span elements
<html:span class="ac-emphasize-text"/>
so in userChrome.css you need to include that namespace:
@namespace html url(http://www.w3.org/1999/xhtml);
and include html|span.ac-emphasize-text (or html|*.ac-emphasize-text
as autocomplete.css does) in your rules for the highlighting.
I've included Seth's patch for highlighting the first hit in both the title
and URL if both members of a pair have one (not yet in Minefield,
but should be soon), and found that I got the best results if I used
bold+bgcolor with different background-colors for the title versus
URL lines, plus switched to bold+ul with same background-color
as the rest of the row when a row is selected. Here's a screenshot:
http://www.macridesweb.com/oltest/gifworksURLbar.png
For comparison, here's a screenshot of the same search via the
History Sidebar:
http://www.macridesweb.com/oltest/gifworksHistorySidebar.png
so that even a "non-tech" person could see how the URLs often can
be much more important than the titles in search hit lists. :<)
Fote
--
Foteos Macrides
> Foteos Macrides wrote:
>
>> > .autocomplete-richlistitem spacer,.autocomplete-richlistitem
>> > label{display:none}
>>
>> That's still blowing off indications of clipped lines via ellipses (but
>> I also can live with that in exchange for the much more desirable
>
> I know. But they are hard to align since they for some reason son't
> follow the margin of the container (why not), and why do they steal
> space when not visible (couldn't the with be adjusted and the "..."
> shown only when needed). I guess it's a matter of personal opinion.
To deal with that in the current Minefield nightly I am using:
.autocomplete-richlistitem spacer{display:none!important}
.autocomplete-richlistitem label[anonid="title-overflow-ellipsis"]
{font-size:11px!important;margin-top:-13px!important}
.autocomplete-richlistitem label[anonid="url-overflow-ellipsis"]
{margin-top:-9px!important}
I'm still not clear on why the labels are not fully encompassed by the
rules for their corresponding description, but when using 11px for the
font-sizes as we are doing, the (empirical :<) rule is to change the top
margin values of the labels by 3px less than for the top margin values
of their corresponding (.ac-title and .ac-url) description.
When the patch for:
https://bugzilla.mozilla.org/show_bug.cgi?id=408621
is finalized, the spacers will be gone, so you can get rid of the css rule
not to display spacers, and you'll need to change your margin values
for the labels and descriptors, but there will be "swapping in when
needed" rather than "always stealing space" for the ellipsis.
So that's progress, but I don't yet see any indication of progress on:
https://bugzilla.mozilla.org/show_bug.cgi?id=408621
for invoking tooltips with complete strings on hovers over titles or
URLs which have been clipped. Fortunately, one does still get
such tooltips when the autocompletepopup value is set to
PopupAutoComplete instead of PopupAutoCompleteRichResult.
Fote
--
Foteos Macrides
> So that's progress, but I don't yet see any indication of progress on:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=408621
>
> for invoking tooltips with complete strings on hovers over titles or
> URLs which have been clipped. Fortunately, one does still get
> such tooltips when the autocompletepopup value is set to
> PopupAutoComplete instead of PopupAutoCompleteRichResult.
Oops, I copied the wrong URL. That bug is:
https://bugzilla.mozilla.org/show_bug.cgi?id=406280
Fote
--