Tue Sep 13, 2011 12:59 am
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...
Tue Sep 13, 2011 9:32 am
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
Tue Sep 13, 2011 4:44 pm
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.
HTML and DHTML
<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.
<div class="container" id="footer">
<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.
Tue Sep 13, 2011 4:48 pm
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.
Tue Sep 13, 2011 8:49 pm
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="author" eg <address class="author">
Bad examples of class is
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 -->
<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%;">
<td width="1%"><img src="images/tags.png" alt="" /></td>
<td width="1%" style="line-height:30px"><b>Tags:</b> </td>
<td width="59%" style="line-height:30px">
<!-- lot of stuff -->
<td width = "40%" style = "text-align:right">
<!-- lot of stuff -->
<td style="text-align: left">
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.
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
Wed Sep 14, 2011 12:13 pm
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.
Wed Sep 14, 2011 9:23 pm
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 !
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
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)
A Strategy That Works: Object/Feature Detecting
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.
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.
Thu Sep 15, 2011 7:14 am
I love Konversation, but there is also Quassel which some folks prefer.