On Sat, Sep 24, 2011 at 04:30:33PM +0930, David Kettler wrote:
> G'day John,
>
> > The idea here is good, but we need to work on the appearance to make it
> > look like it belongs.. so it has that certain elegant something that makes
> > it look like a finished product. Two things are that it looks like the
> > placement is arbitrary, and it doesn't work gracefully when input grows
> > beyond the allocated width for the minibuffer input box. I would like to
> > see a version where:
> >
> > * minibuffer-input is flex 1
> > * url-panel is flex 0
> > * url-panel has same background color as minibuffer-input
> > * url-panel uses sligthly smaller font size, and/or slightly grayed text.
> >
> > Let's try that and see if it has a more fitting look.
>
> Below is a version of the patch that I think does most of what you've
> asked for. I've used an oblique font for the panel; I quite like the
> appearance and it avoids the problems you pointed out with a smaller
> font or grayed text. It's not quite right; there's a grey separator
> that should be white.
>
The grey separator is a margin around the label. The following css makes
it go away:
.url-panel-value {
margin: 0px !important;
}
> The text appearing flush right avoids the two problems you mentioned
> (arbitrary placement and input too wide). However, it has two usage
> problems that bother me.
>
> * In the usual case (wide browser, short hint input) the text is
> displayed far removed from the input. I think the adjacency given
> in both the former patch and in the original panel is important.
>
> * As different links are selected, the start of the link text jumps
> left and right (obviously, as it's right justified). I find that
> very distracting and more difficult to scan.
>
I agree that right justifying is a bad idea. What I would like to look
into though is positioning by use of the flex attribute. I have
experimented a bit with finding a good flex value, and I'm seeing
something I can't fully explain: need for very large flex values on the
url panel.
> My preference is for the panel to appear at a fixed offset, as in my
> former patch, although in that case I don't know how to address your
> point about the placement being arbitrary. Perhaps that is less jarring
> when the appearance makes it merge into the minibuffer-input. To
> address your second point, I'd like the minibuffer-input to expand when
> required, pushing the panel to the right. I'm not sure how to achieve
> that yet; I'm doing cargo cult programming with the CSS.
We'll have to experiment with that.
> Another consideration is that I think we should aim for visual (and
> programmatic) consistency between the url panel display and overlink
> mode. If we use a special style (like oblique here) for the panel, then
> the overlink display should do that too.
I don't see this as a problem we need to address, as hinting and overlink
are completely separate and unrelated features. The former only needs
special styling because we're putting a lot of information into a small
space and need to direct the user's eye.
--
John Foerch
_______________________________________________
Conkeror mailing list
[email protected]
https://www.mozdev.org/mailman/listinfo/conkeror
