RE: [Phpgroupware-developers] Proposal for XHTML/CSS/JavaScript u sage

[Kai Hofmann]

Hi Dave,

> 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.

I have often done this - so I have a lot of experience in this area.
I see two steps here:
1) make te single tags compatible
2) correct the nesting etc. (this is the hard part)

so I could do this job, but because of the many of files it would
only make sense when someone with cvs access will do it ;-)

> > 2) Verifing all HTML pages via the W3C validator
> 
> 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.

adding html from within php code should be avoided - better is to correctly
use the template engine. 
Another possibility would be to write a script that logs into a
phpgroupware,
save the html pages and automatically send them to the validator.
For example "curl" would be a very helpfull tool here - wget will also work
as long as no SSL via Proxy is required.

> >   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.

you can include multiple css files into one html page without problem.

> It would be possible to have a css.php 
> script, but who
> is going to implement that? 

I think this should be avoided.

> >   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.

sorry to say but a print css would be very usefull -
for example you can disable the navigation menu etc. within it so that
you only have the calendar content in a print etc.
This is important in the business area.
You can test this on www.isl.org

> > 4) Verify all CSS via the W3C css validator
> 
> Again this is eaiser than it sounds when you have dynamic content.

There should no dynamic content for css.
Please try to specify the need for dynamic content in CSS.
To switch between themes you would only change the css filename variable
(template)
in a html template.
 
> 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;
> }

Everything that is dynamic and don't need to be is a performance waste.
Also javascript files could be external in the API.
last but not least if there is an acceptable requirement for dynamic
JavaScript - please put it into an external file and use the template engine
on it
this will made the whole code more understandable and maintainable.

> >   the W3C DOM (Internet Explorer, Mozilla, Opera, ....).
> 
> Standards are great, but all three browsers listed here have varying
> levels of support for this "standard".

DOM Level 1 is implemented in all three browsers problems arise mostly for
DOM level 3 - but mostly you only need level 1 partly level 2.
Also this will change in the future I think.

> >   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.

You should never update CVS from a release archive!
Code changes should only be done on workcopies checked out
from the CVS.
When someone has installed a release (compressed) version and
wants to make changes to it he/she could still checkout some
singles files and put them into the installation.
Patches can also be done simply - create a new release version (compression)
and then create the patch between thsi release and the previous one.

> > 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.  

I have no problems with that - as I have proven by my sites ;-)

> 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.

ok here is a TOP tip:

use Mozilla and install "checky" from checky.mozdev.org
you have more than 20 checkers directly within the browser by only making
one keypress ;-)

> 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.

Try the webpages I mention - they will always work - also with lynx ;-)

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

Someone with cvs access as mentioned earlier ;-)

Greetings

    Kai

-- 
*****    Open Source und Linux im professionellen Einsatz    *****
**  komplexe Mailserver, Groupware, Office: sprechen Sie uns an **
Dipl.-Inform. Kai Hofmann                    Team Softwarelösungen
pro|business AG, EXPO Plaza 1 (Deutscher Pavillon), 30539 Hannover
E-Mail: address@hidden,   Tel.: 0511/60066-332, Fax: -355
WWW: http://www.probusiness.de/