[www.kde.org] [Bug 317553] www.kde.org webpages should not set font-size of unstyled body text and should comply with 100% Easy-2-Read Std

[Ingo Malchow]

https://bugs.kde.org/show_bug.cgi?id=317553

--- Comment #14 from Ingo Malchow <imalchow at kde.org> ---
I have no clue why you are still arguing against a closed bug. This simply
means I will not fix it. Unless you come up with a sane patch that doesn't
introduce more work or destroys the entire layout. This is no mailinglist, this
is a bugtracker.

(In reply to comment #13)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #2)
> > > > users favourites are something between 6px and 20px... 
> 
> > > No one's favorite font is 6px, or 7px, or even 8px. The most commonly used
> > > fonts require at least 8px to fully form a glyph. Most font families require
> > > a minimum size of 9px to fully form all available glyphs. On several of my
> > > installations the _minimum_ allowed font size in web pages is 20px.
>  
> > Wow, then you must have a seriously different user group. Instead, i got a
> > lot of complaints in the early phase about too big fonts. And they were not
> > even close to 20px, rather around 14px (but em based).
> 
> Early phase of what?
> 
> Most people who complain about too big fonts haven't personalized their
> personal computing environment to match their own needs or preferences.
> 

That doesn't really matter and is actually debunks your own argument, that
users shouldn't adapt a website, but the website their environment. If a user
didn't set his/her environment, so be it. Actually, that is the majority of web
users, and that is what you shouldn't forget in your design decisions.

> It looks to me like when you wrote "6px, or 7px, or even 8px" what you must
> have meant was pt rather than px. On 96 DPI desktops, there's a 3:4
> relationship between pt and px. 16px is 12pt. But when the DPI is something
> else, that ratio changes. 12pt becomes 20px @ 120 DPI, 24px @ 144 DPI, and
> 32px @ 192 DPI. Take a look for yourself using
> http://fm.no-ip.com/Auth/Font/font-dejaserif.html on multiple systems
> running at DPIs that vary from 96, in addition to 96 that is actually on a
> 96 DPI display rather than forced to 96 by Xorg configuration. When I open
> it here on displays that closely match a display's physical pixel density of
> 90 or more, the letterforms need to be at least 10ppem for there to be
> non-zero space between every letter pair. When the device DPI and DE DPI are
> disparate, as a 96 DPI DE on a 32" 1920x1080 device, 6px & 7px are
> essentially just blobs of color, 8px starts looking like letters, and 9px
> starts to become legible if viewed at half or less of the recommended
> viewing distance for such a device size, all using a western character set.
> For CJK fonts considerably more px are required for legibility.
> 
> This is a very old issue, discussed by the early CSS developers such as at
> http://style.cleverchimp.com/font_size/points/dump.html, which may be the
> first mention of the oft cited
> http://style.cleverchimp.com/font_size/points/font_wars.GIF that
> demonstrates what 8px and 9px fonts typically looked (and still look) like
> on common desktop displays. Even then people were being warned of the
> legibility problems to come from using the newly supported CSS sizing in px
> or pt. For web page text, pt and px have acquired a fixed 1:1 ratio in most
> browsers, making the problems the same regardless which is used to ignore
> user defaults, legibility and reading comfort.
>  
> > > They don't work properly now. They produce a rude product hard on users. An
> > > appropriate set of CMS themes and a firm policy of respecting users will not
> > > cause maintenance horror.
>  
> > i won't let it up to the user that much, else you end up with
> > sidebars that 
> > lo
> > ook
>  
> > a
> > bit
> > like
> > this
> 
> There's no good reason for that to happen. That ever happens as a
> consequence of px sizing instead of relative sizing of the sidebar.
> Competent relative sizing means sidebars are a width fixed in relation to
> their content instead, such as shown by this simple example page:
> http://fm.no-ip.com/Auth/Sites/Ksc/

There is also no good reason to keep fixed elements on very narrow viewports,
which you have done in your example. The menu stays in place and the main text
actually becomes what i described above.
But well, that is up to the designer. A lot of possibilities.
>  
> There, given enough viewport width, proportions of all content are perfectly
> maintained through a wide range of browser default sizes, and nobody with a
> browser default set to maximize his own reading comfort will have any
> accessibility reason to zoom or unzoom to change size of anything therein
> contained.
> 
> > 20px... that is not workable here.
> 
> What's not workable is sizing in px and pt. Both entirely disregard the wide
> range of actual user needs and environments. What works on your display with
> you looking at it is poorly representative of all who want or need to use
> kde.org.

Absolutely right, and if i like it or not, the majority of our users is taken
into account. This meant e.g. a smaller font (px or pt is of no relevance for
the whole point). Or reducing whitespace between elements to not waste blank
space.
And this leads me to my final point. These designs are not just about
accessibility, but about usability, aesthetics as well.
All of your examples or own sites are well, and good in accessibility. But in
my opinion, a frontpage with a list of links pointing to subdocuments without
an own menu, so you need to go back, is not considered good usability in my
view.
But it is not up to me to question your decision, it is simply a different
approach than mine.

KDE sites are supposed to look good for the majority of our users, and of
course should be accessible as much as possible. But all of that is based on
compromises, in any regard. You can't waste space with margins or paddings, you
can't waste space with too big fonts (we have a lot of nerds around, who prefer
a lot of text in less space, but still, i won't make it too small), etc etc. I
can go on for ages about the sort of compromises you need to do for such a
project.

So, in short, this is no mailinglist, i can't fix what you intend, as it is a
too narrow use case and too far from the mediocrity, and i don't have the
manpower as well. This bug is already closed. No need to try to discuss it.

-- 
You are receiving this mail because:
You are the assignee for the bug.