[dev] RFC: Horde_Form Rewrite's XHTML Output

[Matt Warden]

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


Chuck,

Chuck Hagenbuch wrote:
> The only specific xhtml quibble I see is that the form-notes divs 
> should be inside of the form-input div that they are for, to give them 
> some kind of a semantic/programmatic relationship (otherwise if you 
> wanted to do something with them DOM-wise, you'd have to rely on the 
> ordering of elements in the page).

This is how I had it originally, but I couldn't get it to float the
way I wanted. I will take another shot at it.

> My main but vague complaint is that it looks kind of like div soup 
> instead of table soup. There are a number of places where it seems like 

I think the divs look much cleaner than the table equivalent. Plus, it
avoids the misuse of tables. As far as semantic quality goes, if you
have ideas, I'd be happy to hear them. I went with divs because of
their specified intention:

"These elements define content to be inline (SPAN) or block-level
(DIV) but impose no other presentational idioms on the content.  Thus,
authors may use these elements in conjunction with style sheets, the
lang attribute, etc., to tailor HTML to their own needs and tastes."

How I am using them seems to be the most appropriate. Looking at the
notes, though, I think the use of div is in error. It should be a
paragraph tag. I will change that.

> you should be able to specify classes through better selector usage 
> instead of explicit class="" tags; for instance, the <fieldset 
> class="horde-form"; I see a few different kinds of fieldsets, and while 
> I'm not sure they're all necessary (is it required for hidden elements? 
> Given that fieldset is explicitly intended for visual grouping, seems 
> weird), but one of them should be the default - form fieldset { ... }.

Ok, two things.
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. Secondly, I could alternatively do
something like:
form.horde-form fieldset {...}
everywhere, which I do in some places. Where I do not do this is (a)
when it isn't granular enough (e.g., different classes of <input
type="text" /> items, like number, creditcard, etc.) and when I felt
it might make it harder for people to change the styling (i.e., they
would have to know the global structure of the page in order to change
the styling of a single element). Plus, there are many ways to
reference elements like this. So, assuming:

<form class="horde-form">
   <div class="form-input">
      <label></label>
   </div>
</form>

I could reference the label like:

form label {...}
or
div label {...}
div.form-input label {...}
.horde-form label {...}

etc.

So, I was using the classname as a standard so it would make it easier
to customize the styling, which I think was one of the specific items
that was listed on the bounty.

Given this reasoning, do you still feel like I should use more
selectors and less class names, where possible?

> Maybe some things like the notes would be better expressed as <p 
> class="note"></p>, 

Yeah, agreed.

> I'd
> like to see different tags used where possible, and less divs in 
> general.

I don't necessarily agree with the less-divs-for-the-sake-of-less-divs
mentality. It sounds a lot like when people argue that tables shouldnt
even be used for tabular data. If there is a more semantic
replacement, I'll be happy to use it.

For the record, I started out using an unordered list. Would you find
this more semantically correct? I decided against it because it
imposes a certain presentational idea, which I thought we were trying
to get away from. However, the presentational idea might be quite
appropriate for a form. Thoughts?

Thanks for taking the time to provide feedback.

- --
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)

iD8DBQFC9o7YAQ0d4HGyPE8RAnyKAJ9rJRkx5tUJRZ0/+o7rEyQ+LMhnkACfRlxy
bHZfAhhwZzvy2w6A8TVITIw=
=cZIP
-----END PGP SIGNATURE-----