[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

[Gérard Talbot]

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

--- Comment #21 from Gérard Talbot <browserbugs at gtalbot.org> ---
(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

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