W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] introduction, plus some form input ideas

From: timeless <timeless@gmail.com>
Date: Thu, 23 Oct 2008 07:22:22 +0200
Message-ID: <26b395e60810222222y5a987b80h3811fcc7e479244b@mail.gmail.com>
You're doing dom work, the code jonas wrote reminds me of perl which
typically doesn't generate a dom and then serialize it to send out
over the wire. Among other things serializing often requires the
entire document which means you can't build and incrementally send the
document over the wire. For documents i build, this would typically
kill my server or simply cause the connection to be reset because
processing takes too long.

On 10/22/08, Kristof Zelechovski <giecrilj at stegny.2a.pl> wrote:
> I do not find the other code significantly simpler than the present one.
> I would rather say:
>
> 	Sub printOption(value, selected, text)
> 	Dim Opt
> 	Set Opt = Option. Create(value, text)
> 	Opt. selected = (value = selected)
> 	Response.Write Opt.outerHTML
> 	End Sub
>
> 	For each rec in recset
> 	printOption rec.value, selectedValue, rec. text
> 	Next
>
> Problem solved.
> Chris
>
> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jonas Sicking
> Sent: Wednesday, October 22, 2008 6:19 PM
> To: Ian Hickson
> Cc: whatwg at lists.whatwg.org; Ric Hardacre
> Subject: Re: [whatwg] introduction, plus some form input ideas
>
> Ian Hickson wrote:
>>> 2. select tag:
>>>    selectedindex="[num]"
>>>
>>> implicitly set the selected index, instead of having to parse all the
> option
>>> tags and insert a "selected" string, much easier to bind to server side
> data,
>>> an invalid value (such as -1 or greater than the number of option tags)
> would
>>> mean none are selected. this would obviously not apply to
> multiple-selects
>>
>> You can do this from script at the moment (setting the .selectedIndex
>> attribute). I haven't added it to the markup side yet. It doesn't seem to
>> add much other than convenience (you can already do this with selected="",
>
>> as you noted). Adding features has a high cost, even for simple features
>> like this, and I'm not sure we can really justify the cost here.
>
> I actually think that something like this could be of high value to authors.
>
> I've found myself many many times writing serverside code like this:
>
> selected_value = get_default_selected();
> list_of_records = get_records_from_db();
> print("<select name='hi'>");
> foreach (record in list_of_records) {
>    print("<option ");
>    if (record.value == selected_value) {
>      print("selected ");
>    }
>    print("value='" + record.value + "'>" + record.text +
>          "</option>");
> }
>
>
> while this works it is quite a pain. It would be much better if you
> could stick selected value in one place and then just dump all values.
> Such as:
>
> list_of_records = get_records_from_db();
> print("<select name='hi' value='" + get_default_selected() + "'>");
> foreach (record in list_of_records) {
>    print("<option value='" + record.value + "'>" + record.text +
>          "</option>");
> }
>
> So I think it works quite well as a convenience feature.
>
> We would have to define things like does the value content attribute
> change value when a new option is selected, or does it just act as a
> default value. In firefox different controls behave differently in this
> regard, I haven't yet checked what the html5 spec does.
>
> / Jonas
>
>

-- 
Sent from Gmail for mobile | mobile.google.com
Received on Wednesday, 22 October 2008 22:22:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:06 UTC