Sorry to bother you once again with this subject... I really tried to code with prog templates. But that's a pain... Because there are some features that have to be coded in the template. Like javascript or some important css/html things that can't be removed imho. Just one example : in acquisition directory, there is a doNotPrint css (in default templates) that makes a table column to be NOT printed (through a media=print stylesheet) we should not remove this stylesheet or we loose a feature ! I agree that actual default templates have to be improved. - doc-head-open and doc-head-close in prog templates are a good idea. - dividing menus in mainmenu / submenu is also a good idea. - we could have a unique id for each div (bloc). It's name could be the template name+ a number. With this a local stylesheet could remove a feature unwanted through the stylesheet. My idea is that the templates should be only one, and includes directory / stylesheet being local. That could give enough freedom to template designers. Let me know what you think, and maybe have a meeting on irc to definetly decide something. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)
OK, I gave prog templates a last chance... and worked on acquisitions to be sure every template is valid XHTML (there was some missing + lot of XHTML error) And finally I agree to work with PROG... I just have some comments to have consistent templates : * validate the XHTML. to do this, the best is to : set insecure=yes in system preferences && have the webdev toolbar installed on firefox && ctrl-shift-H to validate the current page in the w3c validator. * Some html proposals : - use h1 for page main title - use h2 for bloc level title - write forms with : <p><label>text</label><input type="..."></p>, NOT with <table> - use <table> as few as possible (and only where tables are useful) - don't use <caption> at the beginning of tables, at least not for table title. As most blocs are not table, the caption does not exist everywhere. Use h2 instead Questions : * the toggle variable is what the template designers must use when wanting a toggle color in <table> : <!-- TMPL_IF name="toggle" --><td with_toggle1_parameter><!-- TMPL_IF --><td with_toggle0_parameter><!-- /TMPL_IF --> I suggest having a style "toggled" in the css to check that the HTML is correct. * 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 : ============== my local template <p>something specific to me....</p> <!-- KOHA id="1" --> something coming from prog templates, unmodified <!-- /KOHA --> <!-- KOHA id="2" MODIFIED --> Something modified locally, even if it exist in prog templates <!-- /KOHA --> <p> something still specific...</p> the compiler would automatically replace the KOHA id=1 in the template, but let the KOHA id="2" as is, warning the user to check manually for a change. Does it sound interesting ? It would only is template designers plan not to modify invariant blocs, even for some spelling reasons (like "book bag" in NPL template where default says "basket" !) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)
Hi, Just a couple of comments... Paul POULAIN wrote:
* Some html proposals : - use h1 for page main title - use h2 for bloc level title - 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. There is an explanation of how the <label> tag should be used at http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL and http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-grouping
- use <table> as few as possible (and only where tables are useful) - don't use <caption> at the beginning of tables, at least not for table title. As most blocs are not table, the caption does not exist everywhere. Use h2 instead
Questions : * the toggle variable is what the template designers must use when wanting a toggle color in <table> : <!-- TMPL_IF name="toggle" --><td with_toggle1_parameter><!-- TMPL_IF --><td with_toggle0_parameter><!-- /TMPL_IF --> I suggest having a style "toggled" in the css to check that the HTML is correct.
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. eg The class="toggled" in the 2 tables below could easily be made to look quite different via css without having to edit the template. <table id="table1"> <tr> <td class="toggled">text</td> <td class="toggled">text</td> </tr> </table> <table id="table2"> <tr> <td class="toggled">text</td> <td class="toggled">text</td> </tr> </table>
* 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 : ============== my local template <p>something specific to me....</p> <!-- KOHA id="1" --> something coming from prog templates, unmodified <!-- /KOHA --> <!-- KOHA id="2" MODIFIED --> Something modified locally, even if it exist in prog templates <!-- /KOHA --> <p> something still specific...</p>
the compiler would automatically replace the KOHA id=1 in the template, but let the KOHA id="2" as is, warning the user to check manually for a change.
Does it sound interesting ? It would only is template designers plan not to modify invariant blocs, even for some spelling reasons (like "book bag" in NPL template where default says "basket" !)
This sounds like a great idea. Cheers, Richard -- Richard Anderson Project Manager Katipo Communications PO Box 12487 Wellington Web: http://www.katipo.co.nz/ Ph: (04) 934 4251 (DDI) (04) 934 1285 Fax: (04) 934 1286 Mobile: 021 043 3649
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)
Paul POULAIN wrote:
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 can't quite recall where (and it mightn't have even been in Koha) but I think there were some radio buttons which were on the same line. So what I was thinking was that if we put labels on the names for the radio buttons they would get spread apart because of the css on the label tag. eg Is it Sunny? : Yes : No if we put a <label for> on the Yes and No it would become Is it Sunny? : Yes : No Cheers, Richard -- Richard Anderson Project Manager Katipo Communications PO Box 12487 Wellington Web: http://www.katipo.co.nz/ Ph: (04) 934 4251 (DDI) (04) 934 1285 Fax: (04) 934 1286 Mobile: 021 043 3649
participants (2)
-
Paul POULAIN -
Richard Anderson