Re: [Phpgroupware-developers] Proposal for XHTML/CSS/JavaScript usage

[Dave Hall]

Kai Hofmann <address@hidden> wrote:

> Because of my experience with Websites/-applications I would like 
> to make
> some
> suggestions regarding the usage of XHTML, CSS and JavaScript:
> 
> 1) Using XHTML 1.0 Transitional 
>   The step from HTML 4.0 to XHTML 1.0 transitional is very small 
> and the
> first step
>   towards XHTML 1.1/2.0.
>   Differences are:
>   - all tags and attributes are written in lower case
>   - all tags must have a start and an end tag
>     tags that have no end tage like hr, br, input, meta have to be 
> writtenas follows:
>     <hr />, <br />, <input type="submit" />, <meta name="keywords"
> content="" />
>   - all attributes values must be written in quotation marks
>     attributes like "selected" from option tags have to be written as
> follows:
>     <option selected="selected">...</option>
>   - all tags muste be correctly used and correctly nested - only 
> as allowed
> by
>     the XHTML 1.0/HTML 4.0 standard especially by the DTD that 
> defines it.

I wanted to make 16 HTML 4.01 Transitional comliant, but then looked at
how much work was involved in just acheiving that, and gave up.  XHTML
is nice but is even more work.

> 
> 2) Verifing all HTML pages via the W3C validator
>   All XHTML pages should be correct and verified via the W3C 
> validator.   Hint: 
>   Live would become easier if it would be possible to verify the 
> templates   directly before processing - this is not possible now, 
> because of the
>   structure of the templates and its usage.
> 

I is possible to create a non cookie based session where the ip is not
verfied and get the online validator to use that, but that will take a
lot of time.  Validating template can be very difficult, as some apps
add html to the tpls.

> 3) Using CSS
>   CSS should be used for formatting (font, colors, alignment, etc.)
>   instead of using XHTML tag   Using css should still be done with 
> some care, but
>   http://www.ddj.com/webreview/style/
>   is very helpful here (sorry you have to login there :(
>   In this way "Themes" will be done by using CSS!

CSS is great, I added CSS support to setup - a little incomplete, but
looks a lot better imho.

>   CSS should only be used in an external ".css" file - never 
> inside of
> XHTML code.

This is difficult, as we have color themes, and also some apps require
additional css.  It would be possible to have a css.php script, but who
is going to implement that?  In HEAD we have external css files with
support for app css too.

>   This will also allow to have different CSS for different media 
> types:   screen, print, projection, ....
>   create an own file for each media type.

I see that there is really only a small need for print - in print view,
and the rest would just be screen.

> 
> 4) Verify all CSS via the W3C css validator

Again this is eaiser than it sounds when you have dynamic content.

> 
> 5) Usage of JavaScript
>   JavaScript classes/functions should always be defined in 
> external ".js"
> file.

Again this is a nice idea, but I also favour having the api contain some
nice javascript functions which are generated dynamically, like so:

gimme_js($arg1, $arg2)
{
  return $my_js_as_a_string;
}

>   Most important using JavaScript is to use it in a defensive way. 
> Thatmeans
>   the whole application should work without javascript! Only add 
> extra   JavaScript functionality that will make life simpler when 
> javascript is
> available
>   - nothing more - nothing less!

In principle I agree with this.

> 
>   Prefered is object oriented javascript - using "classes".
>   Accessing XHTML documents should only be done by using the W3C DOM
> specification -
>   doing it in this way will make JavaScript compatibe to all 
> browsers that
> implement
>   the W3C DOM (Internet Explorer, Mozilla, Opera, ....).

Standards are great, but all three browsers listed here have varying
levels of support for this "standard".

>   Javacript code should be documented by using JSdoc (see 
> sourceforge)   For the release this documentation could be stripped 
> by using an external
> tool.
> 

As with the removing php comments from release code, CVS updates become
a nightmare.

> 6) Verifying javascript by using Mozillas javascript console
>   another good step would be to write javascript unit tests 
>   (frameworks can be found at 
> http://www.xprogramming.com/software.htm)

I will look at this.

> 7) Make all XHTML pages and CSS styles compatible for people with
> disabilities
> 
> 8) Verify this by using the bobby checker
>   http://bobby.watchfire.com/bobby/html/en/index.jsp

IMHO bobby == brilliant objective, big bastard for you.  I have tried
getting a 1 star bobby rating on sites I have written, but couldn't even
get that.  There is another standard, I forget the name of it (have it
in my uni notes - in .au), which is better.  When studying "Human
Computer Interaction", we were told business love bobby, but many
academics consider it is be a crappy standard.

> 
> 
> As an proof of concept for websites that follow these rule I would 
> mentionmy own works:
>      http://www.hofmann-int.de/
>      http://www.datelib.de/
>      http://www.isl.org/        (my former employer)
> 


I will try to get time to look at these.

I am all for standards compliance, but deciding on which standard you
will support, and comparing to the standards other have chosen to
support is the most difficult part imho.  This is due to the fact that
standards compliance does not mean it will always work.

Also who is going to spend the time implementing this in the
unmaintained apps?

Cheers

Dave

dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>