Form#present checks for a falsy value. So that wouldn't be appropriate
for select elements. consider the following:

<select>
    <option value="">empty string</option>
</select>

I know this is an edge case, but I think we should still guard against
it.

I suspect the best solution would be to check that selectedIndex > -1

That implies forking the Form#present function for different tags much
like we do with Form#(get|set)Value.

Maybe the API should reflect this, too. What about a: hasValue
method ?

Best,

Tobie

On Feb 18, 6:36 pm, perk <phieduren...@gmail.com> wrote:
> On Feb 18, 6:06 pm, perk <phieduren...@gmail.com> wrote:
>
>
>
> > On Feb 15, 9:08 pm, kangax <kan...@gmail.com> wrote:
>
> > > On Feb 14, 7:25 pm, perk <phieduren...@gmail.com> wrote:
>
> > > > At first I thought this was a cross-browser issue of Prototype when
> > > > Form.Element.present() used on a select box returned "true" on Firefox
> > > > but not on IE when a non-empty OPTION field was selected.
>
> > > > Later then, I realized that this method was in fact just meant for
> > > > text inputs (as clearly stated in the documentation: "Returns true if
> > > > a text input has contents, false otherwise.").
>
> > > > Still, I think it would be nice to have the functionality of the
> > > > Form.Element.present method extended so that the following example
> > > > would work on all browsers the way I thought it would at first
> > > > ("false" when no or the empty option is selected, "true" otherwise):
>
> > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
>
> > > > <html>
> > > >   <head>
>
> > > >     <title>Test</title>
> > > >     <script type="text/javascript" src="prototype.js"></script>
> > > >     <script type="text/javascript">
> > > >     document.observe("dom:loaded", function () {
> > > >       $("mySelect").observe("change", function () {
> > > >         alert($("mySelect").present() ? "select set" : "select not
> > > > set")
> > > >       });
> > > >     });
> > > >     </script>
>
> > > >   </head>
> > > >   <body>
>
> > > >     <select id="mySelect">
> > > >       <option></option>
> > > >       <option>test</option>
> > > >     </select>
>
> > > >   </body>
> > > > </html>
>
> > > > What do you think?
>
> > > The problem actually seems to be in `Element#getValue` returning
> > > "" (empty string) in Firefox (3.0.5), Safari (3.1) and Opera (9.61)
> > > for a value of a select element with `selectedIndex == -1` (i.e. the
> > > one with no options selected), while returning `null` in IE. If you
> > > look at the DOM L2 specs for `HTMLSelectElement` [1], you can see that
> > > `value` property is defined as that of type `DOMString`. `DOMString`
> > > in its turn is essentially a character string encoded in UTF-16 [2].
> > > This makes IE's `null` a bogus (what a surprise!).
>
> > > Unless I'm missing something, we should fix `getValue` foremost.
>
> > > Would you mind filing a ticket?
>
> > > [1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-94282980
> > > [2]http://www.w3.org/TR/DOM-Level-2-Core/core.html#DOMString
>
> > > --
> > > kangax
>
> > I couldn't reproduce IE returning null on getValue.
>
> Note: I tested it in IE 6, 7 and 8, and it seems like "getValue" is
> working fine.
> So if Form.Element.present() would use the "getValue" method instead
> of the "value" attribute,
> it would also work for select boxes fine, or am I missing something?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to