Menu
▾
▴
vimprobable-users
|
From: Morgan H. <mt...@gm...> - 2014-12-18 08:08:05
|
Is there currently any way to change the config variable in the hinting script without recompiling? The defaults are a bit hard to look at, but I don't see a way of doing this via scripts or the rc file. I was considering adding support for it, but wanted to make sure there wasn't some trick for doing it via the user scripts first. Thanks, Morgan PS. Btw, my previous patch for showing link destinations still hasn't been merged. :) |
|
From: Jason R. <jas...@gm...> - 2014-12-18 08:47:46
|
Hi Morgan, On 18/12/14 at 04:07pm, Morgan Howe wrote: > Is there currently any way to change the config variable in the > hinting script without recompiling? The defaults are a bit hard to > look at, but I don't see a way of doing this via scripts or the rc > file. There is a patch on the wiki, but you'll still need to recompile… Given this is something that, presumably, won't be changed often, that seems reasonable… http://sourceforge.net/p/vimprobable/wiki/Patches/ Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Daniel C. <dan...@gm...> - 2014-12-18 21:03:17
|
Morgan Howe <mt...@gm...> wrote:
> Is there currently any way to change the config variable in the
> hinting script without recompiling? The defaults are a bit hard to
> look at, but I don't see a way of doing this via scripts or the rc
> file.
>
> I was considering adding support for it, but wanted to make sure there
> wasn't some trick for doing it via the user scripts first.
It's partially possible to change the hint style by style.css file. But this
allows only to style the hint labels (squares with the hint number in). To
take effect, you need to put '!important' behind the styles in case they are
defined by the hinting script, like shown below.
#hint_container .hinting_mode_hint {
-webkit-transform:translate(-4px,-4px);
color: #000 !important;
background-color: #fff !important;
border: 1px solid #444 !important;
opacity: 0.7 !important;
font:bold .9em monospace !important;
}
--
Daniel
|
|
From: Morgan H. <mt...@gm...> - 2014-12-22 05:15:11
|
On Fri, Dec 19, 2014 at 5:03 AM, Daniel Carl <dan...@gm...> wrote:
> Morgan Howe <mt...@gm...> wrote:
>> Is there currently any way to change the config variable in the
>> hinting script without recompiling? The defaults are a bit hard to
>> look at, but I don't see a way of doing this via scripts or the rc
>> file.
>>
>> I was considering adding support for it, but wanted to make sure there
>> wasn't some trick for doing it via the user scripts first.
>
> It's partially possible to change the hint style by style.css file. But this
> allows only to style the hint labels (squares with the hint number in). To
> take effect, you need to put '!important' behind the styles in case they are
> defined by the hinting script, like shown below.
>
> #hint_container .hinting_mode_hint {
> -webkit-transform:translate(-4px,-4px);
> color: #000 !important;
> background-color: #fff !important;
> border: 1px solid #444 !important;
> opacity: 0.7 !important;
> font:bold .9em monospace !important;
> }
Hey guys, thanks for the suggestions. Sorry for the delay, gmail is
doing something weird with my filters so I missed your responses for a
few days. :) Changing only the hint labels as per Daniel's post is
probably sufficient as that's the hardest part to read, though I still
think it should be fully configurable.
I agree with you, Jason, that this isn't something that won't be
changed often. Still, while it may be reasonable for you (I assume)
and me as developers to apply a patch to change this or add the
functionality to allow changing it, I feel like we may be excluding
potential users who do not have this knowledge or ability. Something
as simple as changing the default hint colors should be available out
of the box, and I think some people may be put off immediately when
they find out it's not. Although it's unfair, if such an obvious (and
hotly debated! :) option of changing basic color schemes isn't
possible, it wouldn't be unreasonable to expect the rest of the
experience to be equally inflexible.
Sure you could argue that a vim-like browser is not something
non-developers would ever be interested in to begin with, but I think
we might be selling the project short by making that assumption. I
think we should try to move as many of these compile time settings as
is reasonable out to configurable settings, and be vim-like not only
in behavior, but flexibility as well. It should be possible to do so
while still maintaining a good balance between minimalism and
configurability, and will allow us to provide a browser that
distributions will be able to include in their repos that is ready to
meet the needs or tastes of most users without a recompile.
I do not intend this as a rant or any kind of philosophical statement
and would be very interested to hear others thoughts on whether or not
this would be a worthwhile goal to work toward.
Best regards,
Morgan
|
|
From: Hannes S. <ha...@yl...> - 2014-12-22 16:04:40
|
On Mon, 22 Dec 2014 13:15:03 +0800, Morgan Howe <mt...@gm...> wrote: > I do not intend this as a rant or any kind of philosophical statement > and would be very interested to hear others thoughts on whether or not > this would be a worthwhile goal to work toward. Agreed. Hannes |
|
From: Daniel C. <dan...@gm...> - 2014-12-22 21:36:56
|
Daniel Carl
Morgan Howe <mt...@gm...> wrote:
> I think we should try to move as many of these compile time settings as
> is reasonable out to configurable settings, and be vim-like not only
> in behavior, but flexibility as well. It should be possible to do so
> while still maintaining a good balance between minimalism and
> configurability, and will allow us to provide a browser that
> distributions will be able to include in their repos that is ready to
> meet the needs or tastes of most users without a recompile.
In case of user who get vimprobable as compiled binary installed it makes
sense to allow to change some more things during runtime. But I don't think
that it would be easier for such an user to type in css rules in the config
file to change the look of the hints. The hints are not just a color or a
font. I like the way of doing style changes via style.css file. Long story
short: I can't imagine that a user want to add something like following to the
config file.
set hint-label-css=z-index:100000;font-family:monospace;font-size:10px;font-weight:bold;color:white;background-color:red;padding:0px 1px;position:absolute;
According to the initial issue, I'd suggest to rework the hinting to add and
remove only classes and avoid to set inline styles (except of the position of
the labels) and to add a stylesheet with the default styling of the hint
elements. This makes it easy to style the hints completely by style.css file.
--
Daniel
|
|
From: Hannes S. <ha...@yl...> - 2014-12-23 09:25:04
|
So, to follow up on the brief IRC discussion: I believe there are two questions to be asked here: 1. What should the default styling of the hints be? 2. How to allow the users to change them? We've got the second one covered in the discussion so far, and I also like Daniel's latest suggestion. As for the first one, I obviously took those default colours from Vimperator back in the day. They are optimised for discoverability, I'd say, i.e. if you're not quite sure what the linked elements even are, you're sure to spot them all when activating hinting mode, because they will jump right in your face. They are not pretty and some people apparently don't find them very readable (this is very subjective and hard to measure). I'm open to change the defaults, but I have some basic requirements: - Discoverability still needs to be there. Not necessarily as striking as it is now, of course, but something too subtle is also not good. - The contrast should be sufficient for visually impaired users (again, subjective; I believe there are automated test suites for this, though). Yes, my own system is completely grey on grey as well. I even like low contrast! That, however, doesn't necessarily make it a sensible default for the general public. Suggestions welcome! Hannes |
|
From: Morgan H. <mt...@gm...> - 2014-12-23 10:19:09
|
Hey Hannes, On Tue, Dec 23, 2014 at 5:25 PM, Hannes Schüller <ha...@yl...> wrote: > So, to follow up on the brief IRC discussion: I believe there are two > questions to be asked here: > > 1. What should the default styling of the hints be? > 2. How to allow the users to change them? > > We've got the second one covered in the discussion so far, and I also > like Daniel's latest suggestion. Are you referring to allowing these things to be controlled through the style.css, or was there more followup discussion? For those of us not in the IRC, would you mind giving us a quick recap of Daniel's suggestion? I'll get in the IRC in the future to hopefully catch these discussions. > As for the first one, I obviously took those default colours from > Vimperator back in the day. They are optimised for discoverability, I'd > say, i.e. if you're not quite sure what the linked elements even are, > you're sure to spot them all when activating hinting mode, because they > will jump right in your face. They certainly jump right in your face! :) > - Discoverability still needs to be there. Not necessarily as striking > as it is now, of course, but something too subtle is also not good. > - The contrast should be sufficient for visually impaired users (again, > subjective; I believe there are automated test suites for this, > though). We should definitely have some sensible defaults, or even consider not changing them at all so things look comfortable for people moving over from Vimperator (or even earlier versions of vimprobable, people usually don't like change). As you said, ultimately what is best is very subjective and nearly every one of us will probably have our own preference, so I think that what we choose as defaults is less important than having the ability to easily change them. Thanks for moving the discussion forward! Morgan |
|
From: Hannes S. <ha...@yl...> - 2014-12-23 17:11:03
|
On Tue, 23 Dec 2014 18:18:48 +0800, Morgan Howe <mt...@gm...> wrote: > > We've got the second one covered in the discussion so far, and I > > also like Daniel's latest suggestion. > > Are you referring to allowing these things to be controlled through > the style.css Yes, that's what I meant, sorry. Hannes |
|
From: Hannes S. <ha...@yl...> - 2014-12-23 17:09:59
|
On Mon, 22 Dec 2014 22:36:05 +0100, Daniel Carl <dan...@gm...> wrote: > I like the way of doing style changes > via style.css file. Long story short: I can't imagine that a user > want to add something like following to the config file. > > set > hint-label-css=z-index:100000;font-family:monospace;font-size:10px;font-weight:bold;color:white;background-color:red;padding:0px > 1px;position:absolute; > > According to the initial issue, I'd suggest to rework the hinting to > add and remove only classes and avoid to set inline styles (except of > the position of the labels) Agreed, making this an easily referenced class is the way to go. > and to add a stylesheet with the default > styling of the hint elements. This, however, I'm not so keen on. It has been the browser's policy so far never to create files, but only to populate them if the user creates them first. I.e. the browser can be run on any system without leaving any traces. I still like this. Opinions? Hannes |
|
From: Daniel C. <dan...@gm...> - 2014-12-23 18:34:41
|
> Von: "Hannes Schüller" <ha...@yl...>
> > and to add a stylesheet with the default
> > styling of the hint elements.
>
> This, however, I'm not so keen on. It has been the browser's policy so
> far never to create files, but only to populate them if the user
> creates them first. I.e. the browser can be run on any system without
> leaving any traces. I still like this. Opinions?
Oh, I didn't ment to write something into the style.css file. I thought
of adding the default style to the html header as style tag.
var e = document.createElement("style");
e.innerHTML = ...;
document.head.appendChild(e);
This means the style is considered to be the pages style and can easily
overwritten by the user styles read from style.css file.
Daniel
|
|
From: Hannes S. <ha...@yl...> - 2014-12-24 06:32:02
|
On Tue, 23 Dec 2014 19:34:32 +0100, "Daniel Carl" <dan...@gm...>
wrote:
> > Von: "Hannes Schüller" <ha...@yl...>
> > > and to add a stylesheet with the default
> > > styling of the hint elements.
> >
> > This, however, I'm not so keen on. It has been the browser's policy
> > so far never to create files, but only to populate them if the user
> > creates them first. I.e. the browser can be run on any system
> > without leaving any traces. I still like this. Opinions?
>
> Oh, I didn't ment to write something into the style.css file. I
> thought of adding the default style to the html header as style tag.
>
> var e = document.createElement("style");
> e.innerHTML = ...;
> document.head.appendChild(e);
>
> This means the style is considered to be the pages style and can
> easily overwritten by the user styles read from style.css file.
Ah, OK. Agreed, then.
Hannes
|
|
From: Jason R. <jas...@gm...> - 2014-12-23 18:57:44
|
On 23/12/14 at 10:25am, Hannes Schüller wrote: >So, to follow up on the brief IRC discussion: I believe there are two >questions to be asked here: > >1. What should the default styling of the hints be? >2. How to allow the users to change them? > >We've got the second one covered in the discussion so far, and I also >like Daniel's latest suggestion. > >As for the first one, I obviously took those default colours from >Vimperator back in the day. They are optimised for discoverability, I'd >say, i.e. if you're not quite sure what the linked elements even are, >you're sure to spot them all when activating hinting mode, because they >will jump right in your face. > >They are not pretty and some people apparently don't find them very >readable (this is very subjective and hard to measure). I'm open to >change the defaults, but I have some basic requirements: > >- Discoverability still needs to be there. Not necessarily as striking > as it is now, of course, but something too subtle is also not good. >- The contrast should be sufficient for visually impaired users (again, > subjective; I believe there are automated test suites for this, > though). > >Yes, my own system is completely grey on grey as well. I even like low >contrast! That, however, doesn't necessarily make it a sensible default >for the general public. > The current defaults (red on yellow) may pose accessibility issues for people with colourblindness[0], a better combination would be black on yellow (the international traffic standard). This is high contrast enough, and also similarly garish to prompt those who don't require such lurid colours to change them quickly… As to 2), there are three vars that the user should be able to modify: hint_foreground, hint_background and hint_size. How that is actually implemented I'll leave to the technically competent. 0. http://colorvisiontesting.com/color2.htm Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Hannes S. <ha...@yl...> - 2014-12-24 07:47:07
|
On Wed, 24 Dec 2014 07:57:30 +1300, Jason Ryan <jas...@gm...> wrote: > The current defaults (red on yellow) may pose accessibility issues > for people with colourblindness[0], a better combination would be > black on yellow (the international traffic standard). Thanks for this research, Jason! So are you suggesting a yellow background of the complete link, black background for the number and white for the number itself? Or do you mean getting rid off one of those three colours? Hannes |
|
From: Jason R. <jas...@gm...> - 2014-12-24 08:12:58
|
On 24/12/14 at 08:48am, Hannes Schüller wrote: >On Wed, 24 Dec 2014 07:57:30 +1300, Jason Ryan <jas...@gm...> >wrote: >> The current defaults (red on yellow) may pose accessibility issues >> for people with colourblindness[0], a better combination would be >> black on yellow (the international traffic standard). > >Thanks for this research, Jason! > >So are you suggesting a yellow background of the complete link, black >background for the number and white for the number itself? Or do you >mean getting rid off one of those three colours? > I was just envisaging a black number on a yellow background: the third colour (the complete link) seems like overkill to me, but if it is to be retained then a neutral colour would probably work best. However, it has been many years since I actively paid attention to WCAG, so I'd happily defer to people who are knowledgeable in that space. Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Hannes S. <ha...@yl...> - 2014-12-29 04:04:05
Attachments:
hint_styling3.patch
|
Hi, the attached patch exposes all visible hinting elements to styling via style.css. Four classes are used: - vimprobable_hinting_mode_hint: unfocused number - vimprobable_hinting_mode_hint_focus: focused number - vimprobable_hinted_element: unfocused complete link - vimprobable_hinted_element_focus: focused complete link You can override the defaults the same way Daniel described in his earlier mail. On a sidenote, I believe there is even a bug in the current hinting script. It already attempts to set specific classes to focused and unfocused hints, but gets confused in the process, I fear: class names which aren't even set are attempted to be replaced. Daniel, maybe I've been misreading something there? In any case, I believe this patch fixes that as well. Please test and provide feedback! Hannes |
|
From: Daniel C. <dan...@gm...> - 2014-12-30 21:04:02
|
Hannes Schüller <ha...@yl...> wrote:
> Hi,
>
> the attached patch exposes all visible hinting elements to styling via
> style.css. Four classes are used:
>
> - vimprobable_hinting_mode_hint: unfocused number
> - vimprobable_hinting_mode_hint_focus: focused number
> - vimprobable_hinted_element: unfocused complete link
> - vimprobable_hinted_element_focus: focused complete link
From point of styling it would be easier to split the classes into a two
parts. One for hint-label or hint-element and a second class that indicated
the focus on them.
- vimprobable_label: hint label in general
- vimprobable_element: hinted element
- vimprobable_active: hinted element or label is currently active
The classes vimprobable_label and vimprobable_element can be used to apply a
general style to the hint labels and hinted elements like font-size, or
border. And the vimprobable_active class could be used to update the style in
case the hinted element or label is focused.
/* style the hint label */
.vimprobable_label {
-webkit-transform:translate(-4px,-4px);
background-color: #fff;
border: 1px solid #444;
color: #000;
font:bold .9em monospace;
margin: 0;
opacity: 0.5;
padding: 0px 1px;
position: absolute;
z-index: 100000;
}
/* style update for active hint label */
.vimprobable_label.vimprobable_active {
opacity: 1;
}
I think we should apply such a default style by adding the style node into the
head of the current page and make sure that we do not do that twice.
Daniel
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X