On Tue, 21 Feb 2012, Jonas Sicking wrote:
> On Tue, Feb 14, 2012 at 10:05 PM, Ian Hickson wrote:
> > In short, I agree that if the implementation cost was high here that we
> > could compromise on this design and go with something less clean or with
> > less graceful fallback, because it is true t
On Tue, Feb 14, 2012 at 10:05 PM, Ian Hickson wrote:
> In short, I agree that if the implementation cost was high here that we
> could compromise on this design and go with something less clean or with
> less graceful fallback, because it is true that many authors will not use
> this fallback feat
On Fri, 29 Jul 2011, Jonas Sicking wrote:
> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson wrote:
> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
> >> On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson wrote:
> >> > On Mon, 2 May 2011, Jonas Sicking wrote:
> >> >> On Mon, May 2, 2011 at 3:36 PM, Ian Hickso
On Tue, Aug 2, 2011 at 1:30 AM, Henri Sivonen wrote:
> On Fri, 2011-07-29 at 15:20 -0700, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor
>> wrote:
>> > On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking wrote:
>> >> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson wrote:
>> >>>
On Fri, 2011-07-29 at 15:20 -0700, Jonas Sicking wrote:
> On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor
> wrote:
> > On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking wrote:
> >> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson wrote:
> >>> Looking specifically at 's ability to fall back to , I
> >>>
On Sun, Jul 31, 2011 at 11:45 AM, Jeremy Keith wrote:
> The way that datalist is currently designed (and implemented) is exemplary.
> The fact that (by design) it allows authors to nest a select element within
> it that shares the same option elements means that authors can safely begin
> to us
The way that datalist is currently designed (and implemented) is exemplary. The
fact that (by design) it allows authors to nest a select element within it that
shares the same option elements means that authors can safely begin to use this
new feature.
I've written more about it here: http://ad
On Fri, Jul 29, 2011 at 5:17 PM, Anne van Kesteren wrote:
> On Fri, 29 Jul 2011 15:20:59 -0700, Jonas Sicking wrote:
>>
>> Ah, well, then it definitely seems like we should get rid of this
>> feature. The harm is definitely there in that it's adding a feature
>> without solving any problem.
>>
>>
On Fri, 29 Jul 2011 15:20:59 -0700, Jonas Sicking wrote:
Ah, well, then it definitely seems like we should get rid of this
feature. The harm is definitely there in that it's adding a feature
without solving any problem.
For what it's worth, I'm not even convinced there is a problem. The
website
On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor wrote:
> On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson wrote:
>>> Looking specifically at 's ability to fall back to , I
>>> agree that it's not necessarily doing to be widely used, but given th
On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking wrote:
> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson wrote:
>> Looking specifically at 's ability to fall back to , I
>> agree that it's not necessarily doing to be widely used, but given that
>> it's so simple to support and provides such a clean w
On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson wrote:
>> > On Mon, 2 May 2011, Jonas Sicking wrote:
>> >> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson wrote:
>> >> >
>> >> > in a is completely ignor
On Fri, 29 Jul 2011, Jonas Sicking wrote:
> On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson wrote:
> > On Mon, 2 May 2011, Jonas Sicking wrote:
> >> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson wrote:
> >> >
> >> > in a is completely ignored for form submission. In
> >> > fact, any form element at
On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson wrote:
> On Mon, 2 May 2011, Jonas Sicking wrote:
>> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson wrote:
>> >
>> > in a is completely ignored for form submission. In
>> > fact, any form element at all in is ignored for form
>> > submission. See the "
On Mon, 2 May 2011, Jonas Sicking wrote:
> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson wrote:
> >
> > in a is completely ignored for form submission. In
> > fact, any form element at all in is ignored for form
> > submission. See the "construct the form data set" algorithm:
> >
> > http://www
On Mon, May 2, 2011 at 3:36 PM, Ian Hickson wrote:
> On Fri, 31 Dec 2010, Mounir Lamouri wrote:
>> On 12/31/2010 03:20 AM, Ian Hickson wrote:
>> > On Fri, 24 Sep 2010, Mounir Lamouri wrote:
>> >>
>> >> I agree that a child of a datalist element should not block the form
>> >> submission. However,
On Fri, 31 Dec 2010, Mounir Lamouri wrote:
> On 12/31/2010 03:20 AM, Ian Hickson wrote:
> > On Fri, 24 Sep 2010, Mounir Lamouri wrote:
> >>
> >> I agree that a child of a datalist element should not block the form
> >> submission. However, I'm wondering why do we care about this
> >> particular e
On 12/31/2010 03:20 AM, Ian Hickson wrote:
> On Fri, 24 Sep 2010, Mounir Lamouri wrote:
>>
>> I agree that a child of a datalist element should not block the form
>> submission. However, I'm wondering why do we care about this particular
>> edge case when there are a lot of situations where an el
On Fri, 24 Sep 2010, Mounir Lamouri wrote:
>
> I agree that a child of a datalist element should not block the form
> submission. However, I'm wondering why do we care about this particular
> edge case when there are a lot of situations where an element can be
> invalid without any possible act
Hi,
I agree that a child of a datalist element should not block the form
submission. However, I'm wondering why do we care about this particular
edge case when there are a lot of situations where an element can be
invalid without any possible action from the user.
If there is no specific use case
20 matches
Mail list logo
