Re: [WSG] dl v table for form layout
Jamie Collins wrote: You put: Using form doesn't exclude use of list or table To me thats telling me 'oh yes you can use a table or list' The only time i said a table is fine forms is if its a dynamic spreadsheet or a calander. Of course you can use table or list within form as this is what form may consist of and (I'm not sure do you realize) you've just said it :) Ive demonstrated the use of forms without tables, and when i get time i will create an article that focuses on styling the forms and show you what can be achived. Its lack of knowledge that forces people to create tables to contain there forms for general layout purposes. Lack of knowledge also makes people to build tables or lists using divs ;-) The saying goes again, a table is for tabular data, and if the tablular data needs a form (like a spreadsheet) then in this case it would be fine to use. I cant see any use for a list to be used to contain form data. What about: Name your 5 favorite movies in order from most liked to less liked (ordered list with input field for each item follows). 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] ***
Re: [WSG] dl v table for form layout
Mike at Green-Beast.com wrote: I think may be some confusion, Mariusz, because so far this discussion has been about putting a form in a separate structure such as a table or dl to contain or organize the form, not about putting a structure (like a table) in a form. It's the latter you seem to be talking about. I, too, was a bit confused by your first post because of this. Yeah probably I went too much from first point of this discussion which indeed was about using tables just to fix presentational issues which it's obviously wrong. However later discussion went too much into point that in general tables and lists in forms are wrong and we should do everything to build form on fieldsets instead - which to me was wrong way in opposite direction.. and this is the issue to which I was responding to. 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] ***
Re: [WSG] dl v table for form layout
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] ***
Re: [WSG] input name and id
Terrence Wood wrote: [EMAIL PROTECTED]: Can I just substitute ID for NAME and still adhere to web standards or is NAME really required? 'name' **is** required on inputs. It's confusing, but the name attribute is required on **form controls** (input etc) so that your from can be processed on your server - it's not the same thing as 'name' used elsewhere (e.g. anchors). 'name' is not required by specification (at least as far as I understand specification) - it's a bit striking to me as what's the use of input element without assigned name?? The only use I can imagine is when script language used on client side will read and process its values. Mariusz Nowak *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] alternative to target=_blank in xhtml 1.1
Users of the search engine on my intranet site wold like to have the results open in a new page. Can anyone suggest a valid method to do this in xhtml 1.1? To my knowledge the valid way of opening link in a new window in XHTML 1.1 is to let user decide whether to open page in current or new window. All modern browsers have this thing in mind e.g. in Firefox you open page in current tab using left button and in new tab using middle button. After all this functionality is within scope of interface and shouldn't be resolved outside of it (how about windowless interface??) - this is the reason why it was removed from specs. -- Mariusz http://www.medikoo.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
