Richard Anderson a écrit :
- write forms with : <p><label>text</label><input type="..."></p>, NOT with <table> I think there is a problem here in that the <label> tag has been used as for formatting (with CSS styles) rather than its intended use as an accessibility aid. So people will find it hard to add in <label> tags to other parts of the forms without distorting the page layout.
When used as an accessibility aid the <label> tag can really speed up how people use forms - especially for radio buttons and checkboxes - you get a big target to click on to check the input.
Rather than apply a style to the <label> tag, I think it would be better to wrap it in <span> with the style applied to the span.
So the above example would be: <p><span class="label"><label for="somename">text</label></span> <input type="..." id="somename" /></p>
This would enable someone, perhaps me, to add in the accessibility features which the <label> tag enables.
OK for the accessibility, owen already entered a lot of for="...", and accesskey would be interesting too. But I don't see why we also need the <span>. The <label> can also be used as CSS. and we could/should avoid having a <span>. Were am I wrong here ?
I think it would be nice to add a unique id to each table. This would give a lot more options for people to format how each table looks via some contextual css. I guess in most cases it wouldn't be used but I think it is an easy option to add in at the templating stage.
OK agreed.
* begin every "invariant" bloc with <!-- KOHA id="X" --> where X is a number : that is a big task and only useful is someone is ready to develop a "template compiler" (like the translator compiler). The idea would be to : be able to report blocs in a local template to have synch easier. An example : This sounds like a great idea.
We spoke of this on irc with owen. Another idea, that sounds better, would be to have a <div id="templatename_what_it_is_for> </div> That could serve the same purposes of "template compiling" AND enable css driven only theme. At the end, all templates should contain : * a include menu.inc * a include menu_module.inc (acquisition, catalogue, circulation, authorities...) * a include template_bottom.inc (do we need a template_module_bottom.inc ?) * a content, that can highly be css driven, through <div> and id. * all necessary things to create a "template compiler" if someone want to write it. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)