Only forum.kde.org related discussions fall in the scope of the Forum Feedback area. Please take a minute to find the appropriate section for your query before posting here.
Reply to topic

KDE Community forums should comply with 100% Easy-2-Read Std

GTalbot
Registered Member
Posts
69
Karma
1
OS
Hello,

The KDE Community forums website should support and comply with the 100% Easy-2-Read Standard

If the website would not [re-]define the font size for unstyled body text and for headings elements, then the user preferences for unstyled body text (and then the heading elements proportionality) as set in the browser preferences would prevail.

This is known to be the most accessible way to set, to style font-size: you avoid setting it, you avoid styling it and then the preferences of the user (otherwise the browser defaults) shine. The user is perfectly in control this way.

No one knows what's my preferred font size for reading normal body text. No one knows in advance what's the preferred font size for reading normal body text for this visitor, that visitor, for any visitor. The nice thing is: the web authors do not need to know that and they can honor individually each visitor's preferences.

Right now, the KDE Community forums website sets the font-size of <body> and <p> to 13px. But what if it's too small for you or too big for your netbook? ...

A bit more reading...

"
Doing it right

So what does an author have to do to get it right? Absolutely nothing! Just avoid specifying a font in CSS for <BODY> or <P> (...)
"
The Wrong Size Fonts Or why not to over-ride the reader's font size


"
If you do not specify any font size at all (as on the pages you are reading), text will appear in the default size that was selected by the user.
"
Truth & Consequences of Web Design: Font size


"
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; (...)
"
Top Ten Web Design Mistakes of 2005: 1. Legibility Problems


regards, Gérard


User avatar neverendingo
Administrator
Posts
2136
Karma
17
OS
Usually i would agree with you and do something against it. But as there is a new theme for KDE sites rising on the horizon it is probably overhead to do something right now. So stay tuned and watch the things to come ;)


New to KDE Software? - get help from Userbase or ask questions on the Forums
Communicate.
Image
GTalbot
Registered Member
Posts
69
Karma
1
OS
neverendingo wrote:Usually i would agree with you and do something against it. But as there is a new theme for KDE sites rising on the horizon it is probably overhead to do something right now. So stay tuned and watch the things to come ;)


Ingo,

I disagree. It's never too late for doing the right thing. Furthermore if a new layout is being developed.

I also checked the website underlying code and there are several other problems of various types.

Javascript errors: just turn on javascript debugger and script errors reporting and there will be errors being reported.

HTML and DHTML
1-
<input name="keywords" id="keywords" type="text" maxlength="128" ...> (...)
<input class="inputbox search tiny" type="text" name="keywords" id="search_keywords" size="20" ...

id must be document unique. Here it is not.

2-
<div class="footer">
<div class="container" id="footer">
This is a very bad way to specify elements. What is "footer"? A class name or an id value? One can be used to logically group elements for a purpose while the other is document unique: here, they are both used! Attributes values should be unique and distinguishible from each other for various reasons; code maintenance, debugging, reviewing for starters, avoid side effects, javascript errors, etc...

3-
<a id="top" name="top" accesskey="t"></a>
<a id="bottom" name="bottom" accesskey="z"></a>
empty anchors: this is a known issue which can create problems. Note again here the duplication of name and id.

Many other types of underlying coding and architecture design problems (with some being pretty serious for a large site):
Nested tables, unsemantic class name (eg class="rightside"), target="_blank", inline style (clear separation of structure and presentation), inline script (clear separation of structure and behavior), overconstrained tables, divitis, classitis, overconstrained table cells, non-scalable (rigid) webpage layout, various accessibility issues, etc..

A new theme is not going to help; it is going to make things worse, more difficult to manage, to maintain, to debug, to review, etc.

regards, Gérard


User avatar neverendingo
Administrator
Posts
2136
Karma
17
OS
You probably got me wrong. The new theme will indeed address things we did wrong in the past. And i know quite good what is wrong with this current theme, i wrote it. Nothing i want to repeat with the new one.
Afterall, we all learn with time ;)
And you might think with the new theme we are about to manage one more theme. This is not the case. The current one will just be replaced. Here you are right. It makes no sense to maintain several themes.


New to KDE Software? - get help from Userbase or ask questions on the Forums
Communicate.
Image
GTalbot
Registered Member
Posts
69
Karma
1
OS
Ingo,

Please consider the following as recommendations, suggestions, tips.

class is for logical grouping of elements sharing the same function, the same role, the same goal. Class attribute value should not be presentational; class attribute value should describe the function, the role, the goal without any presentational aspect. Class should not be about markup. Since class involves logical grouping of various elements, then it must be used more than once otherwise id attribute should be used. Good examples of class is:

class="registration"
class="references"
class="warning"
class="important"
class="navigation"
class="documentation"
class="report"
class="author" eg <address class="author">
class="user-settings"
etc,

---------

Bad examples of class is
class="box-top"
class="left"
class="span-19"
class="centered"
class="rightside"
class="red"
class="bold"
class="class1"
class="div2"


---------

id should be about identifying an unique element in a document.

Good examples of id is:

<div id="footer"> <!-- Once HTML5 footer element is better supported by browsers, including Konqueror, then it can replace such div footer -->
<div id="horizontal-navlist">
<form id="register>
<form id="feedback">
<textarea id="txtComments">
<form method="post" id="topic-search" ...>

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

I saw this
window.onunload = function()
but I think (am not sure) it should be window.onbeforeunload = function()

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

Example of overconstrained table I saw in the website code:

<table border="0" width="100%;">
<tr>
<td width="1%"><img src="images/tags.png" alt="" /></td>
<td width="1%" style="line-height:30px"><b>Tags:</b>&nbsp;</td>
<td width="59%" style="line-height:30px">
<!-- lot of stuff -->
</td>
<td width = "40%" style = "text-align:right">
<!-- lot of stuff -->
</td>
<td style="text-align: left">

</td>
</tr>
</table>

1% + 1% + 59% + 40% = 101%
and that's just for 4 cells and then there is a 5th empty left-aligned cell.


---------

In my opinion, name attribute should only be used for form control elements (input, textarea, button, fieldset). Name attribute should no longer be used for anchors and for form elements.

"
name = cdata [CI]
This attribute names the element so that it may be referred to from style sheets or scripts. Note. This attribute has been included for backwards compatibility. Applications should use the id attribute to identify elements.
"
http://www.w3.org/TR/html4/interact/for ... -name-FORM

"
12.2.3 Anchors with the id attribute

The id attribute may be used to create an anchor at the start tag of any element (including the A element).

This example illustrates the use of the id attribute to position an anchor in an H2 element. The anchor is linked to via the A element.

You may read more about this in <A href="#section2">Section Two</A>.
...later in the document
<H2 id="section2">Section Two</H2>
...later in the document
<P>Please refer to <A href="#section2">Section Two</A> above
for more details.

The following example names a destination anchor with the id attribute:

I just returned from vacation! Here's a
<A id="anchor-two">photo of my family at the lake.</A>.

The id and name attributes share the same name space. This means that they cannot both define an anchor with the same name in the same document.
"
http://www.w3.org/TR/html4/struct/links.html#h-12.2.3

By removing name attribute for a elements, you make your code closer, less prone to bugs and readier for an eventual HTML5 code upgrade.
http://dev.w3.org/html5/html4-differenc ... attributes

regards, Gérard


User avatar neverendingo
Administrator
Posts
2136
Karma
17
OS
You seem to know quite much about webdevelopment. Would you like to join us in our efforts to improve the web experience of KDE? If so, most of the discussions take place on IRC, freenode, channel #kde-www.
Any new contributor is welcome. :)


New to KDE Software? - get help from Userbase or ask questions on the Forums
Communicate.
Image
GTalbot
Registered Member
Posts
69
Karma
1
OS
neverendingo wrote:You seem to know quite much about webdevelopment. Would you like to join us in our efforts to improve the web experience of KDE?


Right now, I am too busy. But I wish the accessibility of all kde.org webpages would be improved (Open Quality Standards for website, Jakob Nielsen's useit.com).

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

editor.js in forum.kde.org

I checked the editor.js file. There are issues with such code.
The caret often disappear (while using Konqueror 4.7 with KHTML rendering engine) when editing in forum.kde.org and the problem may be originating from that editor.js code ... or it also be a real bug with Konqueror 4.7.0 under KHTML rendering engine.

Also, some focus() calls (document.body.focus()) are wrong in my opinion.

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

Browser sniffing vs object feature/method detection in editor.js

User agent string detection is generally unreliable, difficult to manage, long to maintain and often wrong, incorrect. So, why use it? Every single recourse to a method should resort to object feature/method detection and not to browser sniffing. There is now a wide and majority consensus among browser manufacturers and cross-browser code gurus out there to promote object feature/method detection.


"we recommend to test for features rather than the browsers brand."
coming from kde.org's Konqueror FAQ !

Javascript Best Practices by Matt Kruse
Feature-Detect Rather Than Browser-Detect



Browser identification approach (aka "browser sniffing"): not best, not reliable approach
Using Object/Feature support detection approach: best and overall most
reliable



comp.lang.javascript FAQ
Version 32.2, Updated 2010-10-08, by Garrett Smith
13.1 How do I detect Opera/Safari/IE?



Browser Detection (and What to Do Instead)
coming from comp.lang.javascript additional notes

A Strategy That Works: Object/Feature Detecting
coming from comp.lang.javascript additional notes

Browser detection - No; Object detection - Yes
by Peter-Paul Koch



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

Any user visiting forum.kde.org or any .kde.org webpages with IE6 or IE7 should politely/diplomatically be invited to switch or to upgrade (browsehappy.com). In the web standards equation, web users should update their browser version regularly (say, once a year, at minimum) while web authors fix validation errors and js errors and while browser manufacturers fix their bugs. Standards is beneficial to compliant parties ... and that includes web users, web visitors as well.

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

neverendingo wrote:If so, most of the discussions take place on IRC, freenode, channel #kde-www.


I have not used any IRC software under KDE so far. Generally speaking, I am not a "chat" person (I am a slow typer). Which IRC software do you use and/or recommend for me? I am using KDE 4.7.0, Kubuntu 11.04, Qt 4.7.2, Linux 2.6.38-11-generic-pae (32bits) here.

Overall, I can help (when time permits) with regards to HTML4, HTML5, CSS 2.1, CSS3 and DOM interfaces. Javascript debugging, testing, DHTML in general. My expertise is CSS 2.1, accessibility and usability, creating reduced testcases, QA and bug triaging.

regards, Gérard


valoriez
KDE CWG
Posts
623
Karma
3
OS
I love Konversation, but there is also Quassel which some folks prefer.

Valorie


Image

 
Reply to topic

Bookmarks



Who is online

Registered users: Baidu [Spider], Bing [Bot], boudewijn, cairncrossr, chechoxque, Google [Bot], ipwizard, Stephen Leibowitz, Yahoo [Bot]