Comparing revisions for RegisterAction

Additions:
$intro = $this->Format(' --- If you are a **new user** you can register an account using this form (if you already have an account, please go to the [[UserSettings | login page]]). --- --- To register, the following fields are required:
~~~~&Using a **data** table to **structure data** (inside or outside of a form) is not using it as a representational aid, but using it exactly for what data table markup is intended for. Marking up form content (a form with more than a single field at least) this way is also helpful for people using screen readers, precisely because it //is// a //data// table (and not a //layout// table): they can choose to browse the content in table mode (representing the data structure, to get an overview of the content) as well as in form mode (to enter or modify the data). I know there are such things as field sets, etc. - but they can't do what the data table is doing here: presenting the **data structure**. Arranging a data structure in rows and columns (and more complicated variants of that) is precisely what data tables are for - and precisely for that reason the markup I've used is **not** a that of a layout table (which uses //nothing but// ##table##, ##tr## and ##td## elements) but that of a data table (with a ##summary##, a ##caption##, and table header cells (##th##) associated with their corresponding data cells (##td##) - none of which are even allowed in a layout table). If you would merely **present** these data, you //would// use a data table. Making those same data editable by means of a form does not suddenly rob it of its data structure: so the data table markup is equally applicably to data that is merely presented and to data that is editable: it is the same data structure after all, with an extra facility (editablility) added to it! --- I know there are "schools" trying to get rid of //all// tables - but that is (respectfully) the wrong approach. Data tables provide a rich markup to present data structures which is not preempted by using a form but can work in conjunction with it. The result provides both visually explicit structure (for those who can see it) as well as a markup structure for those who use assistive technology and like to explore the data structure before (possibly) entering or modifying data. It gives people using assistive technology a choice (corresponding to "scanning" the rows and columns of a form by those who can see) that would simply be missing if data table markup weren't used. While this isn't required by accessibility standards, it definitely isn't wrong either; in fact it's appreciated by most, and it doesn't get in the way for those who want to use only "form mode". --- When you say that a submit button is not data, you are right, of course. :) A refinement of my code (I did say it was not in a final form...) would be to take the submit button outside of the form, leaving the data table to only structure the //data// in the form (and not the form itself). --- If you browse this site, you'll see I always advocate not using tables for layout (that's why the still somewhat experimental new [[WikkaBetaFeatures | category action]] is no longer using a table!) but vice versa I also advocate using **data** table markup - instead of **layout** table markup - when presenting an actual data structure (see JwCalendar, for instance). --- The markup presented here conforms not only to the XHTML (1.0, and even 1.1) standard, but to WCAG as well. You may not like it - but it's not wrong. --JavaWoman---
~~~~~~& OK, agreeing to disagree a done deal! ;) I apologise for not picking up on your earlier mentioning of align="right" going into CSS. But you will find that align probably **will** be deprecated in [[http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-tables.html#s_tablesmodule | XHTML 2]], so it is still deemed a presentational throwback that they weren't brave enough to expunge in 1.1! If you have any links to articles defending the use of tables in forms, I'd be interested, leave them on my page here. Thank you for the interesting discussion, even if you are wrong :p (that is the stick-out tongue smiley just in case!), take care, --IanAndolina
Deletions:
$intro = $this->Format(' --- If you are a **new user** you can register an account using this form (if you already have an account, please go to the [[UserSettings login page]]). --- --- To register, the following fields are required:
~~~~&Using a **data** table to **structure data** (inside or outside of a form) is not using it as a representational aid, but using it exactly for what data table markup is intended for. Marking up form content (a form with more than a single field at least) this way is also helpful for people using screen readers, precisely because it //is// a //data// table (and not a //layout// table): they can choose to browse the content in table mode (representing the data structure, to get an overview of the content) as well as in form mode (to enter or modify the data). I know there are such things as field sets, etc. - but they can't do what the data table is doing here: presenting the **data structure**. Arranging a data structure in rows and columns (and more complicated variants of that) is precisely what data tables are for - and precisely for that reason the markup I've used is **not** a that of a layout table (which uses //nothing but// ##table##, ##tr## and ##td## elements) but that of a data table (with a ##summary##, a ##caption##, and table header cells (##th##) associated with their corresponding data cells (##td##) - none of which are even allowed in a layout table). If you would merely **present** these data, you //would// use a data table. Making those same data editable by means of a form does not suddenly rob it of its data structure: so the data table markup is equally applicably to data that is merely presented and to data that is editable: it is the same data structure after all, with an extra facility (editablility) added to it! --- I know there are "schools" trying to get rid of //all// tables - but that is (respectfully) the wrong approach. Data tables provide a rich markup to present data structures which is not preempted by using a form but can work in conjunction with it. The result provides both visually explicit structure (for those who can see it) as well as a markup structure for those who use assistive technology and like to explore the data structure before (possibly) entering or modifying data. It gives people using assistive technology a choice (corresponding to "scanning" the rows and columns of a form by those who can see) that would simply be missing if data table markup weren't used. While this isn't required by accessibility standards, it definitely isn't wrong either; in fact it's appreciated by most, and it doesn't get in the way for those who want to use only "form mode". --- When you say that a submit button is not data, you are right, of course. :) A refinement of my code (I did say it was not in a final form...) would be to take the submit button outside of the form, leaving the data table to only structure the //data// in the form (and not the form itself). --- If you browse this site, you'll see I always advocate not using tables for layout (that's why the still somewhat experimental new [[WikkaBetaFeatures category action]] is no longer using a table!) but vice versa I also advocate using **data** table markup - instead of **layout** table markup - when presenting an actual data structure (see JwCalendar, for instance). --- The markup presented here conforms not only to the XHTML (1.0, and even 1.1) standard, but to WCAG as well. You may not like it - but it's not wrong. --JavaWoman---
~~~~~~& OK, agreeing to disagree a done deal! ;) I apologise for not picking up on your earlier mentioning of align="right" going into CSS. But you will find that align probably **will** be deprecated in [[http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-tables.html#s_tablesmodule XHTML 2]], so it is still deemed a presentational throwback that they weren't brave enough to expunge in 1.1! If you have any links to articles defending the use of tables in forms, I'd be interested, leave them on my page here. Thank you for the interesting discussion, even if you are wrong :p (that is the stick-out tongue smiley just in case!), take care, --IanAndolina
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki