Last modified: 2013-02-14 07:46:39 UTC
Why is it contained in a table element? This causes huge restrictions on how one can style it. I am currently trying to style the login form to look like https://mingle.corp.wikimedia.org/attachments/3408386b028630169e1105579e7b53da/186/Wikipedia_Signup_-_iOS.png for mobile and it is impossible to do so without changes to the core. Let's replace it with a form with clearly marked input elements and input labels. There is absolutely no need for the table elements.
https://gerrit.wikimedia.org/r/38674 for more context.
Technically speaking given that the login form has keys and values (key = label, value = form input) a table is actually a rational markup. That said, we actually do have some plans to change the form. Mixed in with various signup projects, form style guide, mobile stuff, etc...
I don't understand your reasoning for why a table is a rational markup. It is not rational to me at all. Labels refer to inputs in the for attribute The form groups them together. There is no new for rows / columns.
A table is perfectly rational markup. One column is for labels, the other column is for inputs, and each row is a field with its label. However, if https://gerrit.wikimedia.org/r/27022 ever gets merged, you can always just call setDisplayFormat( 'div' ) on the HTMLForm to change it.
A table is a rational markup, but not a flexible one. It makes sense on desktop but is not very suitable for mobile devices. A <ul> or <dl> (or even bare <label> and <input>) can be styled to look like a table, but it's very difficult to make a table look like a list (especially on older browsers, or IE that Windows Phone uses).
This is trivial enough to fix; see the mobile version of the create account form.
My main groan with this is that it seems we are using a table markup just for the styling benefits it gives. Mobile had to rewrite the login form from scratch due to this constraint. I would advocate going for a bare label and input login form for the existing Special:UserLogin - there is no need for it to be in a table.
*** This bug has been marked as a duplicate of bug 34751 ***
