After getting errors from the W3C validator, I found out that the DTDs of XHTML 4.01/XHTML 1.0 don''t allow empty select elements, i.e., something like <select> </select> is not valid according to these DTDs. The likely reason is that markup such as this doesn''t make much sense in static HTML documents. For web applications, particularly when enhanced with client-side scripting, are useful and common. The dilemma here is this. First horn: Working around the restrictions of the DTDs is just a matter of programming: insert a dummy option into selects, where necessary, remove them again with some JavaScript. Unfortunately, this adds code that seems to be entirely unnecessary and is another cause of errors. Second horn: Some nosy people may submit to the validator just one of those pages containing an empty select and then start complaining about invalid HTML. Michael -- Michael Schuerig Not only does lightning not strike mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org twice, it usually doesn''t strike once. http://www.schuerig.de/michael/ --Salman Rushdie, Fury
On 7/5/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> > After getting errors from the W3C validator, I found out that the DTDs > of XHTML 4.01/XHTML 1.0 don''t allow empty select elements, i.e., > something like > > <select> > </select> > > is not valid according to these DTDs. The likely reason is that markup > such as this doesn''t make much sense in static HTML documents. For web > applications, particularly when enhanced with client-side scripting, > are useful and common. > > The dilemma here is this. First horn: Working around the restrictions of > the DTDs is just a matter of programming: insert a dummy option into > selects, where necessary, remove them again with some JavaScript. > Unfortunately, this adds code that seems to be entirely unnecessary and > is another cause of errors. Second horn: Some nosy people may submit to > the validator just one of those pages containing an empty select and > then start complaining about invalid HTML.You could always consider your HTML an extension to the standard DTD :-) I wonder why you''d display an empty select element at all. Are you filling it up using client side scripting or something? If that''s so, it shouldn''t be too hard to make the JS function that does the filling create the select element if it doesn''t already exist. - Rowan -- Morality is usually taught by the immoral.
On Tuesday 05 July 2005 21:12, BigSmoke wrote:> On 7/5/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote: > > After getting errors from the W3C validator, I found out that the > > DTDs of XHTML 4.01/XHTML 1.0 don''t allow empty select elements, > > i.e., something like > > > > <select> > > </select> > > > > is not valid according to these DTDs.> I wonder why you''d display an empty select element at all. Are you > filling it up using client side scripting or something? If that''s so, > it shouldn''t be too > hard to make the JS function that does the filling create the select > element if it > doesn''t already exist.It''s not that easy, alas. I have a helper for choosing the associated objects of a habtm association. This helper creates two select boxes, "current" and "candidates", and buttons to move elements around. Whether one of these is empty depends on the state of the association. Special casing to skip empty selects on the server and create them on the client would obfuscate the code considerably. Michael -- Michael Schuerig Not only does lightning not strike mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org twice, it usually doesn''t strike once. http://www.schuerig.de/michael/ --Salman Rushdie, Fury
On 7/5/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> On Tuesday 05 July 2005 21:12, BigSmoke wrote: > > On 7/5/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote: > > > After getting errors from the W3C validator, I found out that the > > > DTDs of XHTML 4.01/XHTML 1.0 don''t allow empty select elements, > > > i.e., something like > > > > > > <select> > > > </select> > > > > > > is not valid according to these DTDs. > > > I wonder why you''d display an empty select element at all. Are you > > filling it up using client side scripting or something? If that''s so, > > it shouldn''t be too > > hard to make the JS function that does the filling create the select > > element if it > > doesn''t already exist. > > It''s not that easy, alas. I have a helper for choosing the associated > objects of a habtm association. This helper creates two select boxes, > "current" and "candidates", and buttons to move elements around. > Whether one of these is empty depends on the state of the association. > Special casing to skip empty selects on the server and create them on > the client would obfuscate the code considerably.Personally, I''d simply ignore the validator''s warning then. These standards are there to provide interoperability. I don''t think your empty select elements will ever seize to work in _any_ browser, so I suppose there won''t be a problem really. - Rowan -- Morality is usually taught by the immoral.
Have you considered using something like "choose one" as the default value for your select? That way the select is not empty :)
On Wednesday 06 July 2005 09:54, Giovanni Intini wrote:> Have you considered using something like "choose one" as the default > value for your select? That way the select is not empty :)Well, two days ago my patch to add a prompt to the select_xyz helper methods has made it into Rails. But that''s a different problem. The paradigm case for my problem is this: http://www.schuerig.de/michael/boilerplate/index.html#habtm Michael -- Michael Schuerig Those who call the shots mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Are never in the line of fire http://www.schuerig.de/michael/ --Ani DiFranco, Not So Soft
This was actually provided in revision 1646 of the trunk, based on ticket 1181. I don''t know if it handles the validation issue, but it provides the ''please select'' prompt. http://dev.rubyonrails.com/ticket/1181 The latest beta gems (rev. 1707) already incorporates this patch and so will .13 when it comes out this week. -- Matt On Jul 6, 2005, at 3:54 AM, Giovanni Intini wrote:> Have you considered using something like "choose one" as the default > value for your select? That way the select is not empty :) > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >Matt Pelletier pelletierm-A1PILTyJ15gXhy9q4Lf3Ug@public.gmane.org
I would either: a) Not worry about it, because it seems you''re not caring about accessibility and the real meaning of standards by your screenshots b) Completely rewrite your application so that you build it for non-javascript enabled devices first, then add unobtrusive scripting to change things the way you like it. No offense, but validation errors don''t mean a thing when you''re completely ignoring the way the web was intended. While your app "looks cool" it does ignore simple things like: Form fields were meant for forms. It''s not that big of a deal, really - but when you''re going this far, validation is something you should care less about. Kind of akin to shoving 10 different kinds of models into one database table and arguing whether you should be using a varchar(100) field or varchar(90) field.