Jamie Collins wrote:
http://www.viberate.co.uk/ws/styling-a-form/styling-a-form.html
<http://www.viberate.co.uk/ws/styling-a-form/styling-a-form.html>
I must say that I disagree with some points stated in these article,
shared also with stronger tone in previous posts (that is "Tables for
forms = NO, DL for forms = No").
First, what is form really?
I understand it as an interaction layer that allows user to send his
input to server - this layer is transparent to actual structure layer
and vice versa.
Ideally internal form structure should be same as if there wasn't a form
layer at all (values of inputs and labels will stay as text nodes) - and
this is the way I'm thinking when I'm composing a form.
Using form doesn't exclude use of list or table - it's the other way -
form content may be ordered list, may be definition list, may be a table
or the other and we should use most appropriate element for the content
(thinking as if there wasn't form layer).
Mind that form by specs can contain only block elements - it really
means that spec authors perceived form as a one or more block elements -
form element is just indication for interaction layer - real structure
of form is those block elements inside - I know that this point of view
might controversial for some - the biggest source of confusion is that
browsers do not treat <form> element as a transparent layer but as a
part of structure - you can add padding, width border etc - it feels
like part of a structure. However after all I think it's much more
logical to think of form as of other transparent layer and it's
definitely good to avoid any styling of it (we're already forced to use
block elements inside and styling them should do the job anyway).
Treating it as transparent makes job easier - moving form closures
around doesn't affect appearance of page - recently I've had a call from
client which wanted to move form closures - it can be pain if you have
some presentational css stuff tied to it - mind that it's totally
unlikely that client would request moving closures of *real* structure
element - that should make a good hint ;-)
Other thing - It is said in specs that its children can be <ul>, <ol>,
<table> etc. If writers of specs will think of form as another thing
aside to lists and tables they will state that form can only have e.g.
fieldset elements as its children (like <ul> can have only <li>
elements, <tbody> <tr> etc.) but they didn't.
The only structural (and controversial) element (not really part of form
interaction layer) that can be used only with forms is <fieldset>
..which is to me a weak point of HTML 4.0. What is <fieldset> really?
It's a section and I think it could be very useful also when not using a
form at all - after all in XHTML 2.0 they came up with <section> element ;)
Thanks.
Medyk
--
Mariusz Nowak
Skype: mariuszn3
AIM: mariuszn3
http://www.medikoo.com
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
