[dev] RFC: Horde_Form Rewrite's XHTML Output

[Matt Warden]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck Hagenbuch wrote:
> Quoting Matt Warden <mwarden at gmail.com>:
> 
> 
>>The reason I am not using, say:
>>form fieldset { ... }
>>is because that would be assuming that all forms on the given page
>>(or really any page that links to this stylesheet) are Horde_Forms. I
>>think this is a bad choice.
> 
> 
> I am curious why you think it's a bad choice, and I disagree on the 
> assumption. You are merely assuming that all forms using the stylesheet 
> are structurally similar and that they should look the same. I think 
> that's a good idea, for UI consistency.

And if the user agrees that a given form is of the same type as the
horde-form, she could simply class her form as "horde-form". If,
however, the user feels that a form does not belong in the group of
horde forms, then she would not class the form as such. Hence the
point of classes, no?

> For some of these cases might it be more appropriate to have the 
> wrapper div get the creditcard class? Then style everything inside it 
> based on that.

This is what I was originally thinking. But the way the horde_form
package is structured, variables are rendered by VarRenderer, and the
rest of the package does not know about the variable type (except for
two cases, one of which is 'enum' and the other of which escapes me).
I figured this was intentional and so I didn't change it.

> reason I'd like to see as few classes as possible is that each class="" 
> is a bit of presentation information, not semantic information - or 
> worse, semantic information passed along as presentation information.

Wait, class isn't presentation information at all. It is a way to
group similar elements, just like id is a way to identify a specific
element. It is true that one way to select a group of elements in CSS
is by class, but that does not make it a presentation attribute.

> Interestingly it's sometimes also behavior layer, instead of 
> presentation or data. Things like class="form-required" specify 
> presentation but also should ideally specify behavior - the form 
> javascript, if the user agent allows, should prevent the user from 
> submitting the form with required elements empty. And an attempt to do 
> so should result, behaviorally, in a presentation change to highlight 
> the missing fields.

And there is nothing wrong with this. We would be attaching a behavior
to a group of elements, based on the semantics of "form-required".

> This is getting a bit philisophical, but here are some links:
> http://digital-web.com/articles/forms_usability_and_the_w3c_dom/

Similarly:
http://www.alistapart.com/articles/customdtd/
http://www.alistapart.com/articles/scripttriggers/

> http://www.sitepoint.com/article/standards-compliant-world

I really don't buy that. The .target property is equivalent to the
target attribute. Just as adding an attribute node of "target" or
"invalidAttribute" would cause the page to be invalid, so should
setting the .target property. The proper way to attach functionality
to an element is to... attach functionality to an element. Examples of
this would be using the onclick handler, the sole purpose of which is
behavior. The author is using the 'rel' attribute as if it were a
class. Again, the purpose of a class is to group related elements.
That's exactly what he's doing with the value of the rel attribute. I
don't see the argument for it being okay to attach behavior based on
rel and not on class.

> I think that actually an unordered list imposes a semantic meaning 
> that's incorrect, because a form can be ordered. And also unorded, so I 
> don't think an ordered list is right either.

My thoughts exactly. Forms generally do not have order except for
certain elements (password typically follows username, etc.).

> This is sort of the ideal I have in mind:
> http://www.quirksmode.org/css/forms.html

Interesting. But if we do that, we *definitely* can't semantically
link notes and error messages to field groups.

> Of course a lot of the more complicated elements would want some sort 
> of a container anyway, so if you're saying that we should be consistent 
> and put everything in the same kind of container (that being the divs), 
> I can probably be happy with that.

Cool. The other option is to use another fieldset element. *shrug*

Thanks,

- --
Matt Warden
Miami University
Oxford, OH, USA
http://mattwarden.com


This email proudly and graciously contributes to entropy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC96pKAQ0d4HGyPE8RAk1zAJ4h+/friDrW28Lb7E6tNxDjl4103ACfbvvE
uR050tC0HkCgvbEcqhQvPNQ=
=byZW
-----END PGP SIGNATURE-----