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.
KDE Community forums should comply with 100% Easy-2-Read Std
Page 1 of 1 (8 posts)
Tags:
None
Registered Member 
|
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...
regards, Gérard |
Administrator
|
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
|
|
Registered Member
|
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 |
|
Administrator
|
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. |
|
Registered Member
|
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> </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 |
|
Administrator
|
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. 
|
|
Registered Member
|
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. ---------------
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 |
|
KDE CWG
|
I love Konversation, but there is also Quassel which some folks prefer.
Valorie |
Page 1 of 1 (8 posts)
Bookmarks
Who is online
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan
