Re: [Firebird-docs] Example of new documentation

[Mark R. <ma...@la...>]

On 10-05-2020 20:21, Paul Vinkenoog wrote:
> Mart Rotteveel wrote:
>>> - Font size is rather biggish. Maybe 10% smaller or so would be better and
>>> more in line with the average informative website?
>>
>> The font size is based on the default font size in your browser
>> settings. Would changing that setting be good enough for you?
> 
> Not really, because my default font size is simply the browser default
> (i.e. 'Ctrl-0'), and suits me fine on 90% of the sites I visit. If I set a
> smaller default, it will be too small for comfort on many other sites.
> 
> I uploaded an example here:
> 
>     http://firebird.vinkenoog.nl/Fontgroottes_uitsnede.png
> 
> where you can see, left to right: your rendering, the Firebird website and
> the BBC. The lowercase letter height is around 12% bigger on your site
> than on the other two; that of capitals 20% bigger than the Fb site and
> 10% bigger than the BBC.
> 
> The Firebird site is still fine with me, althought near the lower limit.
> 
> The Beeb is perfect (I think), and I imagine this size might be OK for
> many people.

The stylesheet I use defers to the browser font size by specifying the 
sizes in em units, while the Firebird website specifies font-size in px. 
The BBC also uses relative font size, but indeed looks a bit smaller.
I'll see if specifying the size to 90% instead of its default of 100% 
looks better.

I'll post a new version, or multiple versions later this week.

>> I'll see if I can add a wider padding, but reducing the font-size would
>> already 'fix' this.
> 
> Not if the padding was specified in ex units ;-)

Yes and no, because the content width is specified using em as well, 
reducing the font-size will likely cause the content block to reduce in 
size as well (unless your screen is of course already small).

In any case, I have been tweaking things a bit to get a similar padding 
as the old documentation (with the current font-config). I'll publish 
later this week.

[..]

>> I can't tweak much about this, except showing the three levels of the
>> TOC all the time. That kind of defeats the purpose why I added this in
>> the first place. And maybe I can tweak something about the animation of
>> the transition, but the current 300ms 'ease-in-out' animation applied
>> for expanding and collapsing is less fidgety than no delay to me, and
>> increasing the delay a lot further makes it seem sluggish, but will
>> reduce the jitter while scrolling very fast.
> 
> I realize now that what irritates me most is that first something goes down
> (as the newly focused section is expanded) and than it goes up again (as
> the previously focused section is collapsed). And this also happens if you're
> not scrolling, bust just click somewhere in the ToC. I think I'd prefer this
> instantaneoulsy.

I see what you mean. I'll publish a variant later this week that has the 
animation disabled. Alternatively, you could try this yourself by 
disabling (or changing) the transition rule on #tocbot .is-collapsible.

Mark

-- 
Mark Rotteveel