Adding accessibility keyword

First, it is a lie that your first link doesn't provide a font-size to its body or paragraphs. It does set some rem based font size.
Second, notice the difference between the links you provided and what the KDE websites drive. A single column, no functions, no nothing, plain simple html page. This is very well done, if you have nothing more than just some texts, followed hierarchically. 
But it tends to break when you try to do complex layouts in a lot of different CMS. And that is the situation with KDE, we have a lot of them, and a lot of functionality that needs to be put somewhere, e.g. sidebars, horizontal bars, buttons, boxes etc. Now imagine how hard it will get when you just try to strike out any font declaration. Bad idea, especially considering, users favourites are something between 6px and 20px... 

Then, the referenced page from www.kde.org does use an old theme, which is no longer maintained. The newer themes use an em/rem approach, which is far more flexible regarding dimensions.

Another point, we do use a specific font (on the new themes). We do so because we believe it is the most readable font, not only aesthetically pleasing. This of course removes the choice from the user, but for good hopefully.

So, all in all, valid points you raise, the maintenance horror overweighs though. This is no screenreader blogpage, this is a set of around a dozen different CMS that need to be themed and work properly. 

Oh, and i know the forum post, we have discussed there before. Rejected there, rejected here. Any other accessibility request is welcome.

Created attachment 78498 [details]
contextual 144 DPI screenshot of last URL in comment 0

(In reply to comment #2)
> First, it is a lie that your first link doesn't provide a font-size to its
> body or paragraphs. It does set some rem based font size.

Archived/earlier version of first comment 0 link:
http://web.archive.org/web/20120529002551/http://informationarchitects.net/blog/100e2r/
Editor's version of first comment 0 link:
http://fm.no-ip.com/Auth/new100e2r.html

Default line height is as provided by the actual glyph used's designer, which is generally optimal as long as type size is optimal and line length is not excessive. Regardless, line height is a separate issue from text size and thus should not be a component of or discussed in this bug.

Setting any base font size other than 100%, 1em or medium is rude[1]. There's no way any web stylist can know something other than the user's browser default size can possibly work better, no matter how much trouble it may be for a site's stylist(s) or CMS to not change the base text size to something else.

The KDE Forum and KDE Bugzilla are particularly awful, via further usability reduction in the form of tiny fonts that are low contrast gray on white instead of black on white, and smaller still text within its tiny user input textareas.

[1] http://fm.no-ip.com/Auth/rudeweb.html

(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.

(In reply to comment #2)
> But it tends to break when you try to do complex layouts in a lot of
> different CMS. And that is the situation with KDE, we have a lot of them,
> and a lot of functionality that needs to be put somewhere, e.g. sidebars,
> horizontal bars, buttons, boxes etc. Now imagine how hard it will get when
> you just try to strike out any font declaration. Bad idea

The worse idea is rude design. 

This excuse is typical of a lazy person with no interest inaccessibility.

> pleasing. This of course removes the choice from the user, but for good
> hopefully.

You're hoping for the impossible. No good can be expected from web page text a fraction of the user's preference, or half the size or less of the DE's UI text. It's the user that matters most. Without users there's no reason for a pages existence. Without legible text, there's little reason for the visitor's first action on seeing it to be other than clicking the back button or the tab's close button.
 
> So, all in all, valid points you raise, the maintenance horror overweighs
> though. This is no screenreader blogpage, this is a set of around a dozen
> different CMS that need to be themed and work properly. 

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.

(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).

> 
> (In reply to comment #2)
> > But it tends to break when you try to do complex layouts in a lot of
> > different CMS. And that is the situation with KDE, we have a lot of them,
> > and a lot of functionality that needs to be put somewhere, e.g. sidebars,
> > horizontal bars, buttons, boxes etc. Now imagine how hard it will get when
> > you just try to strike out any font declaration. Bad idea
> 
> The worse idea is rude design. 
> 
> This excuse is typical of a lazy person with no interest inaccessibility.

False assumption. And not the most ideal way to get something fixed.

> 
> > pleasing. This of course removes the choice from the user, but for good
> > hopefully.
> 
> You're hoping for the impossible. No good can be expected from web page text
> a fraction of the user's preference, or half the size or less of the DE's UI
> text. It's the user that matters most. Without users there's no reason for a
> pages existence. Without legible text, there's little reason for the
> visitor's first action on seeing it to be other than clicking the back
> button or the tab's close button.
>  
> > So, all in all, valid points you raise, the maintenance horror overweighs
> > though. This is no screenreader blogpage, this is a set of around a dozen
> > different CMS that need to be themed and work properly. 
> 
> 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.

Hmmmyeah... I better leave that uncommented...
Feel free to report other usability issues as they arise. However, there is a lot of progress on an updated version, and the font might change with it as well. But i won't let it up to the user that much, else you end up with sidebars that 
lo
ook

a
bit
like
this
.
20px... that is not workable here. As you can see, this specific bug is already marked as wontfix.

(In reply to comment #2)
> First, it is a lie that your first link doesn't provide a font-size to its
> body or paragraphs.

This may be an honest mistake on my part. Such mistake does not per se invalidate this bug report.

> It does set some rem based font size.

Unstyled body text at 
http://informationarchitects.net/blog/100e2r
appears to be specified as
font-size: 1.3125em;
at line 418 of
http://cloudfront6.informationarchitects.net/wp-content/themes/iA4/style.css 
body {
  position: relative;
  border-top: 0.14286em solid black;
  padding: 2.90476em 0 3.04762em 0;
  font-family: "iABCRegular", Georgia, serif;
  font-weight: normal;
  font-style: normal;
  font-variant: normal;
  font-size: 1.3125em;
  line-height: 1.52381em;
  color: #111111;
  background-color: #fdfdfd;
  /* Stops Mobile Safari from auto-adjusting font-sizes */
  -webkit-text-size-adjust: 100%;
  /* improves the text rendering in more recents browsers */
  text-rendering: optimizeLegibility; }

On my system, at
http://informationarchitects.net/blog/100e2r
p's font-size is computed as 21px... which is a bit too big for me.
1.3125 mult by 16px == 21px


> Second, notice the difference between the links you provided and what the
> KDE websites drive. A single column, no functions, no nothing, plain simple
> html page. 

It's not so simple html page. As an expert in the field of CSS, I would not say it is a "plain simple"
html page.

> This is very well done, if you have nothing more than just some
> texts, followed hierarchically. 
> But it tends to break when you try to do complex layouts in a lot of
> different CMS. And that is the situation with KDE, we have a lot of them,
> and a lot of functionality that needs to be put somewhere, e.g. sidebars,
> horizontal bars, buttons, boxes etc. 

Ingo, I undertstand what you're saying. But this may be caused by different issues like: overcoding, side effects of declarations, misunderstanding how some CSS properties work or do, etc...
And I am telling you that I see several errors and mistakes with regards to HTML coding, CSS coding in those kde.org webpages.

> Now imagine how hard it will get when
> you just try to strike out any font declaration. Bad idea, especially
> considering, users favourites are something between 6px and 20px... 
> 
> Then, the referenced page from www.kde.org does use an old theme, which is
> no longer maintained. The newer themes use an em/rem approach, which is far
> more flexible regarding dimensions.

Where is that old theme? Where are those newer themes?

> Another point, we do use a specific font (on the new themes). We do so
> because we believe it is the most readable font, not only aesthetically
> pleasing. This of course removes the choice from the user, but for good
> hopefully.

bug 53484 (user setting possibility to use only one specified font for each generic font: sans-serif, serif, fixed, ...) somehow contradicts such specific-font-for-each-theme policy. But anyway, this is a different matter.

> 
> So, all in all, valid points you raise, the maintenance horror overweighs
> though. 

Maintenance horror: people tend to over-code, over-declare, over-style, add more containers instead of reducing code and using/relying on browser defaults. This is a very frequently seen tendency on the web. There is such a thing as over-excessively coding and over-excessively declaring when one of the main goal and advantages of CSS was, in its design, to reduce code, reduce declarations, relying on inheritance.


> This is no screenreader blogpage, this is a set of around a dozen
> different CMS that need to be themed and work properly. 
> 
> Oh, and i know the forum post, we have discussed there before. Rejected
> there

That is not how I recall our KDE forum thread discussion. Basically, there was a new theme being developped and I was too busy to get involved at that time. But I nevertheless reported a lot of inappropriate, inaccurate HTML code.

> , rejected here. Any other accessibility request is welcome.

Isn't rejecting this bug a bit premature? What's the reason for wontfix-ing this bug report?

Gérard

(In reply to comment #3)
> Created attachment 78498 [details]
> contextual 144 DPI screenshot of last URL in comment 0
> 
> (In reply to comment #2)
> > First, it is a lie that your first link doesn't provide a font-size to its
> > body or paragraphs. It does set some rem based font size.
> 
> Archived/earlier version of first comment 0 link:
> http://web.archive.org/web/20120529002551/http://informationarchitects.net/
> blog/100e2r/
> Editor's version of first comment 0 link:
> http://fm.no-ip.com/Auth/new100e2r.html
> 
> Default line height is as provided by the actual glyph used's designer,

There may be small discrepancies though in the way browsers handle this. 
Alan Gresley (in a thread in www-style mailing list) created some revealing 
tests on this.

> which is generally optimal as long as type size is optimal and line length
> is not excessive. Regardless, line height is a separate issue from text size
> and thus should not be a component of or discussed in this bug.


Correct: line height is a separate issue from text size. 
Although I wish it would be 1.4 or even 1.5.  
100% Easy-2-Read Standard states:
"3. Reader friendly line height
(...)
The default HTML line height is too small. If you increase the line height, the text becomes more readable. 140% leading is a good benchmark.
"

Also,

WCAG 2.0, 1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)  state:
"
Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
"
So, to be AAA compliant, paragraph line-height should be set to 1.5
http://www.w3.org/TR/WCAG/#visual-audio-contrast-visual-presentation

> 
> Setting any base font size other than 100%, 1em or medium is rude[1].
> There's no way any web stylist can know something other than the user's
> browser default size can possibly work better, no matter how much trouble it
> may be for a site's stylist(s) or CMS to not change the base text size to
> something else.
> 
> The KDE Forum and KDE Bugzilla are particularly awful, via further usability
> reduction in the form of tiny fonts that are low contrast gray on white
> instead of black on white, and smaller still text within its tiny user input
> textareas.

I completely agree with you, Felix.

> 
> [1] http://fm.no-ip.com/Auth/rudeweb.html

Upcoming attachement is 
KDE-bug317442-100percent-easy-to-read.png , 28 Kibytes, 1024px wide by 408px tall
which is what I see if I set minimal font-size to 15px in Firefox 19.0.2 and when I try to read your own comment, Ingo, on my 1024px by 768px scr. res.

Created attachment 78513 [details]
Comment #2 of this bug report when minimal font-size is set to 15px

KDE-bug317442-100percent-easy-to-read.png , 28 Kibytes, 1024px wide by 408px tall 
what I see if I set minimal font-size to 15px in Firefox 19.0.2 and when I try to read comment #2

(In reply to comment #2) 
> users favourites are something between 6px and 20px... 

This range seems exaggerated or abnormal. Young people will prefer 10px-12px because they do not have poor eyesight and they like to fill all of their window viewport with several applications.
People with lower eyesight will prefer 15px up to 20px. So, in my opinion, testing themes should at least cover the 12px to 18px range.

----------------

Justified text

#main {
   text-align: justify;
   padding: 10px 35px 0;
   font-size: 10pt;
   line-height: 120%;
   text-shadow: #fff 0 0 3px;
   color: #444;
}

 http://www.kde.org/media/includes/chihuahua/css.php around line 341

1-
1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)
" Text is not justified (aligned to both the left and the right margins)."
So, to be AAA compliant, text should not be justified 
http://www.w3.org/TR/WCAG/#visual-audio-contrast-visual-presentation

2-
"
8 Typography: Legibility
Justified text
(...)
Modern browsers support justified text, but it is achieved by crude adjustments to word spacing. Fine adjustments are not possible on low-resolution computer displays and are impractical to implement in today’s web browsers. Also, web browsers are unlikely to offer automatic hyphenation any time soon, another “must” for properly justified text. For the foreseeable future, the legibility of your web documents will suffer if you set your text justified.
(...)
Left-justified text
Left-justified text is the most legible option for web pages because the left margin is even and predictable and the right margin is irregular. Unlike justified text, left justification requires no adjustment to word spacing; the inequities in spacing fall at the end of the lines. The resulting ragged-right margin adds variety and interest to the page without reducing legibility.
"
http://webstyleguide.com/wsg3/8-typography/3-legibility.html

---------------

The nr 1 problem I see in chihuahua/css.php and in styles/plasmaMenu.css is the amount of selector elements and declarations resetting each other. Some elements are being reset more than 5 times. This contributes unneedlessly to difficulty to debug a webpage.

Best is to understand browser defaults and to use them, rely on them, voluntairly, intentionally, deliberately.

Best is to rely on inheritance instead of fighting inheritance. Best is to use inheritance instead of resetting properties all the time.

Ingo,

When I set minimal font-size to 15px in Firefox 19.0.2 when logged in at KDE forums, all the words, sentences at the far right side are truncated... just like in attachment 78513 [details] . And the body text (normal <p> font-size) is set to 13px. So, a minor increase of font-size from 13px to 15px creates an inaccessible webpage. This *_is_* a serious accessibility-to-content problem.

---------------

> An appropriate set of CMS themes and a firm policy of respecting users 
> will not cause maintenance horror.

I agree with Felix. Ingo, as far as I can see, the problem is with the HTML and CSS code of the related pages. 

chihuahua/css.php and in styles/plasmaMenu.css are *_not_* examples of optimized code, compact code, streamlined code, code relying on browser defaults (or appendix D), code using/relying on inheritance.

chihuahua/css.php and in styles/plasmaMenu.css have errors (probably triggered by misunderstandings), redundancy, over-excessive CSS resets, unneeded CSS declaration resets, over-excessively qualified selectors, etc.. 

Ingo, I am begging you to reconsider the status of this bug report. I can help. I have proven in many places that I can optimize and improve a stylesheet.

Gérard

Again, chihuahua is outdated and unmaintained. And at best it shouldn't even be used anymore. Personally, i would rather see it die right now. Because, i don't like it as well ;)
For this it needs a replacement, both on the underlying CMS and theme. 
The theme itself is undergoing a lot of work, not just the font settings. But it needs to fit in a lot of situations, which has nothing to do with over-styling but rather the need to have one design fit into all those (or most) situations.
This are basically the reasons for not wanting to waste a second on chihuahua anymore. As for the forum, this bugtracker, that is ongoing and a different story. And it is partly based on an upstream project named "bootstrap". They do the major work of resetting html and providing defaults.

Oh, and as a last word, help on that ongoing front is very much welcome. That is no question. But not in scope of this bugreport. But that does not only include optimizing a stylesheet, it also includes honoring a underlying design idea (not mine) and - like said before - making it fit into all the various situations we have.

(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.

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, 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.

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.

(In reply to comment #14)
> I have no clue why you are still arguing against a closed bug. 

Obviously. It's only closed because someone raced to close it mere hours after it was created, with no material opportunity for the community to consider it.

>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.

Exactly. Like most of the web, the KDE site is badly designed, which constitutes no less than one bug whether anyone plans to do anything about it or not. In essence, you've announced a policy to conform to the overwhelmingly widespread bad design of the web rather than being a leader interested in maximizing the KDE's and the web's value to the widest number of people. 
 
> > 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

On the contrary. Those who haven't most likely don't need to. Those unhappy with it do need to....

> 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

Where is this "fact" documented? Those that haven't can be considered a major portion if not the vast majority of those who don't need to, a complement to those who designed the default environments they use.

>and that is what you shouldn't forget in your design
> decisions.

I particularly remember the golden rule, which equates to respect for the people who are a site's visitors. You fail to understand virtually everyone can be happy when designers respect by sizing only contextually while keeping the base size exactly as the visitor has configured. This respect means minorities can enjoy comfortably just as much as the majority.
 
> > 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.

That's expected of those who choose a huge text size to viewport width ratio. Anyone who cares to accommodate that edge case can do so with script, which is outside the scope of so simple an example whose purpose is only to show how relative sizing works in a readily discoverable fashion.

> KDE sites are supposed to look good for the majority of our users, and of

Looks are useless without works.

> course should be accessible as much as possible. But all of that is based on
> compromises, in any regard.

Fewer compromises are necessary when styling is minimized and sizing is relative.

> 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),

What you call wasting space generally equates to trying to cram too much into the viewport.

> 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.

You have a fundamental misunderstanding of what the web can be and do. CSS is mostly limiting its power. Less CSS is mostly less limiting, allowing it to be friendlier and more useful, not to mention accessible. A dominating text size equal to the browser default can rarely be too big except to those unable or unwilling to adapt their tools to their own needs. All that's necessary is for site designers to understand and follow a relative sizing scheme based on 100% respect. That means never sizing text or containers using px or pt, and never setting a base text size that doesn't equal 100% of the user's browser default. All users win. Usability wins. Accessibility wins. And eventually, the stylists win too, after they understand how much easier their job is when keeping CSS reduced to a functional minimum.

And still no KDE representative has commented on either attachment.

http://www.kde.org/ has now been added to http://fm.no-ip.com/Inet/shame.html

Ingo,

I still very much disagree with your decision to close, to resolve this bug as WONTFIX. This bug report has intrinsic merits, intrinsic accessibilty values, worth. Ingo, I can not read these bugzilla bug reports pages and KDE Forums pages if I set minimal font-size to 15px!

You close this bug report for reasons that have nothing to do with those intrinsic merits and advantages. Your theme, maintenance horror, etc.. may provide a perspective and reasons as to why kde.org webpages can not honor *now* the 100% Easy-2-Read Std. But, by itself, this bug report is worth implementing, worth achieving.

That is why your decision to close this bug seems to me to be mostly tactical or purely contextual and is not about the goal and merits of this bug report.

---------------

Link update:
Truth & Consequences of Web Design: Font size
http://web.archive.org/web/20090529000800/http://pages.prodigy.net/chris_beall/TC/Font%20size.html
(percent encoding)

---------------

Is plasmaMenu.css one of the old themes you were talking about? Or is it a new theme?

I have started to look at plasmaMenu.css and I see a lot of questionable code and decisions.

at line 70 of
http://www.kde.org/media/styles/plasmaMenu.css
we can see the following:

.header .plasmamenu_box  div div div div ul li a,
.header .plasmamenu_box  div div div div ul li div div ul li a { 
	color: #444;
	text-shadow: #ffffff 1px 1px 1px;
	font-size: 13px;
	vertical-align: top;
	display: block;
}

Now, that means that the target HTML document of such rule has to have a depth of 13 levels of containment hierarchy! ... but it could be more than 13 as the selector uses the descendant selector 13 times!! So, if you have complex layouts to do, try to reduce the number of containers.

"
Avoid the descendant selector

The descendant selector is the most expensive selector in CSS. It is dreadfully expensive (...)
"
Writing Efficient CSS (a bit outdated but still relevant)
https://developer.mozilla.org/en-US/docs/Writing_Efficient_CSS?redirect=no#Avoid_the_descendant_selector.21


text-shadow: #ffffff 1px 1px 1px;
everywhere I saw text-shadow, box-shadow (and other typical purely cosmetic properties, sometimes not even in PR states and using vendor prefixes), I wondered and asked myself if such declarations were helping accessibility, text legibility. Here, I would say it does not (a white shadow of 1px will never be noticed by humans and all the time, 100% of the time) and, on other hand, it does put a performance burden on the style module of browsers. Unneedlessly.

font-size: 13px;
I have not seen the pages where this rule is being applied. I would not be surprised if such font-size: 13px; declaration was entirely unneeded because, you see, font-size is inherited by default.

vertical-align: top;
display: block;
vertical-align property is one of the most misunderstood, most misused and most abused property in stylesheets of webpages on the web. Here, no exception. vertical-align does *not* apply to block boxes.
"
 'vertical-align'
    Value:  	baseline | sub | super | top | text-top | middle | bottom | text-bottom | <percentage> | <length> | inherit
    Initial:  	baseline
    Applies to:  	inline-level and 'table-cell' elements 
"
http://www.w3.org/TR/CSS21/visudet.html#propdef-vertical-align

(In reply to comment #13)
> It looks to me like when you wrote "6px, or 7px, or even 8px" what you must
> have meant was pt rather than px.

I mentioned this in 
bug 233905 : Font setting should show unit and unit should be pixels, not points
and today, latest version of Konqueror (version 4.10.1) and latest version of Rekonq (version 2.2.1) still show font-size in pt unit and not px unit. It should be in px unit and I have explained why.

--------------------
(In reply to comment #14)
[snipped]
> 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.

What if we could provide you with a template that has an menu and honors the 100% Easy-2-Read Std ?

> 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

A small margin or padding in books and reviews contributes to legibility. It's been like that for humans for over 2000 years for paged media.

> 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. 

Those nerds can certainly find the way to set their browser to display text in their preferred font-size. Again, we propose not to set how big <h1> heading, <h2> heading, etc.. are We propose to set medium font-size to 100% of what the user has chosen/set in his/her browser settings.

Browser defaults (user agent stylesheet) helps as h1 is usually set to 2em, h2 is usually set to 1.5em, etc.. Most browsers now try to use Appendix D
http://www.w3.org/TR/CSS21/sample.html
IE8, IE9, IE10, Firefox and all webkit browsers (Chrome, Safari) in their user agent stylesheet have h1 set to 2em, h2 set to 1.5em, etc...

> I can go on for ages about the sort of compromises you need to do
> for such a project.

No compromises required for nerds. All they have to do is set their user prefs settings in their browser and a stylesheet that complies with the 100% Easy-2-Read Std will honor their font-size preferences.

The reason for closing is quite simple: It does not fit into the design decision to comply to the mentioned "standard" entirely (which is not standard, but a suggestion). This does not mean i don't agree on certain points of it. I do. On others not that much and on others not at all.

As already said probably in every reply, the new version will introduce font changes again as well. Those use rem as base. But (also again) this is decided and done upstream. The current theme on the forum overwrites some font changes which i removed already in our development version. So the entire font scaling is not up to us anymore. But we set a custom font. One of the points btw against the topic of this bugreport. Our designer once decided about a certain font to use for (also already explained) various reasons.

So yeah, it might sound tactical, and probably is, but i won't follow a certain blogpost in its rules. I follow the design that was given to me and try to do the best out of it. In our various scenarios. But this means the bugreport as it was given is a WONTFIX. If you simply stated "i can't read xxx, please raise font size", that would be different (and yet unnecessary, as i said, it changed a lot again in our dev version). It still takes a bit of work, but that is also out of scope of this bugreport.
Unfortunately the mainsite www.kde.org still uses the outdated old theme (yes, that is where plasmamenu comes from) and i hope it doesn't take that long anymore to fully get rid of it.
So please don't waste your time on something that will be gone. Not worth your and my time.

Again, don't take it as an offense that this is simply closed, i am aware of a lot of issues, not only the fonts. The given "standard" just doesn't fit. If you want to help out on a more global approach, feel free to find me outside of this bugtracker.

And about the other one, Felix, not worth to be commented really, apart from that:
"CSS is mostly limiting its power. Less CSS is mostly less limiting, allowing it to be friendlier and more useful, not to mention accessible". Now that is the biggest bullshit i have heard in a long time. No need to argue anymore then.

(In reply to comment #14)
> Unless you come up with a sane patch that doesn't
> introduce more work or destroys the entire layout. 

The thing is we probably could be able to propose one that would honor most if not all legibility and accessibility standards... but you already close this bug as wontfix!

> > Most people who complain about too big fonts haven't personalized their
> > personal computing environment to match their own needs or preferences.

Most people complain a lot more often about frozen font size and small font sizes, otherwise (because they don't know to whom to complain or it's a waste of time) they are irritated, annoyed by small fonts.
"
Top 10 Web Design Mistakes of 2005
For this year's list of worst design mistakes, I decided to try something new: I asked readers of my newsletter to nominate the usability problems they found the most irritating. 
(...)
1. Legibility Problems 
Bad fonts won the vote by a landslide, getting almost twice as many votes as the #2 mistake. About two-thirds of the voters complained about small font sizes or frozen font sizes; about one-third complained about low contrast between text and background. 
"
Top 10 Web Design Mistakes of 2005 
http://www.nngroup.com/articles/top-ten-web-design-mistakes-of-2005/

Vincent Flanders (in his Web Pages That Suck website) has a similar point of view on this:
{
Don't use small text. Designers are also fond of using small text (especially on Flash sites). Hey, we're all getting older and as I often say, "If people can't see it, they will flee it."
}
Biggest Mistakes in Web Design 1995-2015
10. Forgetting the purpose of text.
http://www.webpagesthatsuck.com/biggest-mistakes-in-web-design-1995-2015.html#10

Suggestion on how to help users set their preferred font size for unstyled body text:
(old and outdated but a good example):
http://www.w3schools.com/largetext.htm


> 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.

For desktop PC, the browsers' default font-size for unstyled body text is 16px! That is true, even in IE6 and IE7. It was and is true for all Firefox versions, all Opera versions. Konqueror too: it is 12pt (equivalent to 16px).
On kde.org websites and kde.org webpages (KDE forums, KDE bugzilla), I am "offered" less than 16px: unstyled body text is set to 10pt (13.33333px).


> There is also no good reason to keep fixed elements on very narrow
> viewports, which you have done in your example. 

If I understand you correctly: the very specific problem you mention can be arranged with media queries.

> These designs are not just about
> accessibility, but about usability, aesthetics as well.
(...)
> KDE sites are supposed to look good for the majority of our users, and of
> course should be accessible as much as possible.

This bug report was not about aesthetics or good looks. Good looks and aesthetics should be second to accessibility and legibility. 
The browser defaults for unstyled body text in all browsers (desktop PC) is 16px, not 13px. I can not increase font-size from 13px to 15px (by setting minimal font-size to 15px) without losing accessibility to content (real words).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31/03/13 12:45, Gérard Talbot  wrote:
> I still very much disagree with your decision to close, to resolve 
> this bug as WONTFIX.

It really doesn't matter whether you agree or not.  Points have been
made and considered.  The rule for open source software is quite
simple - those who do the work make the decisions.

Anne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFYPnIACgkQj93fyh4cnBf3YwCeKjPZRIBvT3/HwcFUYPCVuTqz
q2oAn1a4gIbgNP+6XNzMyNPsFfl5k2MS
=OPVc
-----END PGP SIGNATURE-----

(In reply to comment #18)
> The reason for closing is quite simple: It does not fit into the design
> decision to comply to the mentioned "standard" entirely (which is not
> standard, but a suggestion). 

The 100% Easy-2-Read Standard may not be a W3C Proposed Recommendation but WCAG 2.0 is and it recommends and has guidelines, checkpoints, techniques about line-height and color contrast and text alignment.

"
Width is no more than 80 characters or glyphs (40 if CJK).

Text is not justified (aligned to both the left and the right margins).

Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.

Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.
"
http://www.w3.org/TR/WCAG/#visual-audio-contrast-visual-presentation


> This does not mean i don't agree on certain
> points of it. I do. On others not that much and on others not at all.

Which points you agree with? Which points you do not that much? or not at all? This is vague and general. Anyway...

> As already said probably in every reply, the new version will introduce font
> changes again as well. Those use rem as base. 

I'm familiar with CSS3 values and units because I had to convert Mozilla's test to CSSWG format:
https://bugzilla.mozilla.org/show_bug.cgi?id=834923

'div {width: 1rem;}' will refer to document root font-size (specified by author stylesheet or not; if not specified by author stylesheet, then the user agent stylesheet will shine and it's going to be 16px!) and not refer to the current (inherited!) font-size of div.


> But (also again) this is
> decided and done upstream. The current theme on the forum overwrites some
> font changes which i removed already in our development version. So the
> entire font scaling is not up to us anymore. But we set a custom font. 

This is something I realized a few years ago: do not specify a particular font-family (except maybe generic font) unless you have a good reason to. Not specifying it will make the browser use the default font-family as set in the browser: chances are you (web author) are going to be using the user's preferred (or browser default) font type.

> One
> of the points btw against the topic of this bugreport. Our designer once
> decided about a certain font to use for (also already explained) various
> reasons.
> 
> So yeah, it might sound tactical, and probably is, but i won't follow a
> certain blogpost in its rules.

What about several other blogposts? WCAG 2.0? W3C Quality Assurance tips for webmasters? WAI? etc. Some blogposts are backed by serious usability studies, you know...


> I follow the design that was given to me and
> try to do the best out of it. In our various scenarios. But this means the
> bugreport as it was given is a WONTFIX. If you simply stated "i can't read
> xxx, please raise font size", that would be different (and yet unnecessary,
> as i said, it changed a lot again in our dev version). It still takes a bit
> of work, but that is also out of scope of this bugreport.
> Unfortunately the mainsite www.kde.org still uses the outdated old theme
> (yes, that is where plasmamenu comes from) and i hope it doesn't take that
> long anymore to fully get rid of it.
> So please don't waste your time on something that will be gone. Not worth
> your and my time.

Please let me know when that new theme, new design, new template ... new whatever here ... is completed, active and implemented in kde.org websites.

> Again, don't take it as an offense that this is simply closed, i am aware of
> a lot of issues, not only the fonts. The given "standard" just doesn't fit.

The new rem unit in the new theme or template or new whatever here will not do more than what the em unit was already capable of doing. rem unit is more rigid (less relative, less proportional and not inherited) than em unit.


> If you want to help out on a more global approach, feel free to find me
> outside of this bugtracker.
> 
> And about the other one, Felix, not worth to be commented really, apart from
> that:
> "CSS is mostly limiting its power. Less CSS is mostly less limiting,
> allowing it to be friendlier and more useful, not to mention accessible".
> Now that is the biggest bullshit i have heard in a long time. No need to
> argue anymore then.

What Felix wrote makes sense in my mind. The more a web author writes CSS rules, CSS declarations, complex selectors, the more such web author constraints an HTML document. The web is very much a macaroni-like of CSS declarations, CSS rules, CSS resets that don't make sense. Web authors in general try to dictate their preferences, try to impose a rigid and constraining perspective, design, layout:

{
Myth #8: People should view a Web site the way the designer intended

    False. People cannot view a Web site the way the designer intended, unless the designer intended for the site to be viewed differently. With all the different browsers, window sizes, fonts, font sizes, resolutions, color depths, and other user preferences on the Web, it is simply impossible to have a document look the same to all users.

    People should view Web sites the way they wish to view them. Some people may wish to view pages using the author's style sheet, but others may require their own presentation to be able to access the content. An author's choices are to design a site that a minority of Web users will be able to see as "intended," or to design a site that all will be able to access, with some seeing the author's suggested presentation.
}
Accessibility Myths
http://www.htmlhelp.com/design/accessibility/myths.html

Created attachment 78525 [details]
contextual 144 DPI screenshot of KDE home page in Konq 4.10 and Firefox 19.0.2

On WinXP @ 144 DPI, http://www.kde.org/ fonts in Safari 5 closely match Gecko rv19's, while on IE6, as in Konq, they're much larger, what appears to be 20px, compared to the configured 24px in the Geckos and Safari and "12pt" in IE.