[whatwg] [wf2] DOMControlValueChanged cancelable?

[Anne van Kesteren]

The specification does not really say whether it is cancelable or not
explicitly. Taking into account the text surrounding the event it is probably
not cancelable, but I guess that should be noted.

Also s/fired an/fired on/

Cheers,

Anne


-- 
Anne van Kesteren

Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted

[Lachlan Hunt]

Matthew Raymond wrote:

Lachlan Hunt wrote:
No, command in the current spec represents an abstract form control for 
sharing features among several real form controls.


   The  element is most certainly not a form control, since it
can't be submitted


I know that, I said *abstract* form control, though perhaps I should 
have omitted the word "form".



AIUI, the difference between them can be illustrated as follows:


 
 
 
   
  
  
   
   



   You're mistaken. The  caption actually isn't the menu label
in many cases.


Since the button itself wouldn't actually be visible in WA1 UAs, it's 
really only there for fallback, why can't it be used as the menu's label?



 You would only use the button for submission. Here's a
stripped down version of what Ian has on his weblog:

| 
|   
| 
|   Jump to
|   
| 
| 
| 
| 
|   
| 

   Also, as you point out, the  element could be used instead. So
you'd need either a  or child text, as you see Ian using above.


Why?   is still a button, what difference does it 
make from the button element?


But, if you really don't like overloading the use of the button as the 
menu label as well, then I guess we could add a label, but I think just 
using the button itself has the advantage of less markup and if the 
button isn't required to get the menu, authors won't bother including 
it, which reduces accessibility.



| Label Text
| 
|   
|   
| 


We already have  for form controls, I don't think we need a new 
element for that especially when it's basically still associating a 
label with a form control.  I also think you're overloading the use of 
the menu element too.


Do you like the structure of any of these alternatives? (with the actual 
element names still up for discussion)


1. 
 Jump to
 
   

2. 
 Jump to 
 Go
   

3. 
 Jump to 
 Go
   

4. 
 Jump to
 Jump to
   
 
 Go
   

   Hmm... Is there really a use case where we'd be using  
elements for submenus?


Not that I can think of, but select elements could have submenus using 
the optgroup element, as currently described in the spec.



Not menus, mind you, but menus within menus. If  not, then we could
drop  from the list of possible children for   while
keeping the element itself.


I don't understand your logic behind this.


| 
|   ...
|   
| 


Why does  need to be a child of menu at all?  It's really more 
of an abstraction, rather than a physical control for the user to use. 
Wouldn't it be better for them to be declared within the  or early 
within the  and then referenced by other controls as needed?


--
Lachlan Hunt
http://lachy.id.au/

[whatwg] [wf2] editorial thing regarding wrap attribute

[Anne van Kesteren]

2.14. Extensions to the textarea element

# 'white-space' property values based on the wrap element
# for textarea elements

There is no such thing as a "wrap element".

Cheers,

Anne


-- 
Anne van Kesteren

[whatwg] [wf2] :disabled does not address option inside disabled optgroup

[Anne van Kesteren]

It only addresses form controls nested in a fieldset. However, setting optgroup
to disabled should cause descendents of that, either optgroup or option, to
become disabled as well.


-- 
Anne van Kesteren

Re: [whatwg] [wf2] DOMControlValueChanged cancelable?

[Ian Hickson]

On Thu, 1 Dec 2005, Anne van Kesteren wrote:
>
> The specification does not really say whether it is cancelable or not 
> explicitly. Taking into account the text surrounding the event it is 
> probably not cancelable, but I guess that should be noted.
> 
> Also s/fired an/fired on/

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [wf2] editorial thing regarding wrap attribute

[Ian Hickson]

On Thu, 1 Dec 2005, Anne van Kesteren wrote:
>
> 2.14. Extensions to the textarea element
> 
> # 'white-space' property values based on the wrap element
> # for textarea elements
> 
> There is no such thing as a "wrap element".

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [wf2] :disabled does not address option inside disabled optgroup

[Ian Hickson]

On Thu, 1 Dec 2005, Anne van Kesteren wrote:
>
> It only addresses form controls nested in a fieldset. However, setting 
> optgroup to disabled should cause descendents of that, either optgroup 
> or option, to become disabled as well.

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [wf2] :disabled does not address option inside disabled optgroup

[Anne van Kesteren]

Quoting Ian Hickson <[EMAIL PROTECTED]>:

It only addresses form controls nested in a fieldset. However, setting
optgroup to disabled should cause descendents of that, either optgroup
or option, to become disabled as well.


Fixed.


This also applies to :enabled. Sorry for not bringing that up earlier.


--
Anne van Kesteren

Re: [whatwg] [wf2] :disabled does not address option inside disabled optgroup

[Ian Hickson]

On Thu, 1 Dec 2005, Anne van Kesteren wrote:
>
> Quoting Ian Hickson <[EMAIL PROTECTED]>:
> > > It only addresses form controls nested in a fieldset. However, setting
> > > optgroup to disabled should cause descendents of that, either optgroup
> > > or option, to become disabled as well.
> > 
> > Fixed.
> 
> This also applies to :enabled. Sorry for not bringing that up earlier.

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted

[Matthew Raymond]

Lachlan Hunt wrote:
> Matthew Raymond wrote:
>>Lachlan Hunt wrote:
>>>AIUI, the difference between them can be illustrated as follows:
>>>
>>>
>>> 
>>> 
>>> 
>>>   
>>>  
>>>  
>>>   
>>>   
>>>
>>
>>   You're mistaken. The  caption actually isn't the menu label
>>in many cases.
> 
> Since the button itself wouldn't actually be visible in WA1 UAs, it's 
> really only there for fallback, why can't it be used as the menu's label?

   Because, semantically, it's not actually a label for the . In
fact, semantically, the two controls are only related indirectly via the
.

>> You would only use the button for submission. Here's a
>>stripped down version of what Ian has on his weblog:
>>
>>| 
>>|   
>>| 
>>|   Jump to
>>|   
>>| 
>>| 
>>| 
>>| 
>>|   
>>| 
>>
>>   Also, as you point out, the  element could be used instead. So
>>you'd need either a  or child text, as you see Ian using above.
> 
> Why?   is still a button, what difference does it 
> make from the button element?

   It doesn't matter if it's a  or an ,
because neither have label semantics for anything external to themselves.

> But, if you really don't like overloading the use of the button as the 
> menu label as well, then I guess we could add a label, but I think just 
> using the button itself has the advantage of less markup and if the 
> button isn't required to get the menu, authors won't bother including 
> it, which reduces accessibility.

   You could use the  as a menu label if the  is absent,
but the web author should not be required to use the  as a
label, because that forces them to use inferior fallback. The button as
a label in a fallback scenario just doesn't seem that common to me.

>>| Label Text
>>| 
>>|   
>>|   
>>| 
> 
> We already have  for form controls, I don't think we need a new 
> element for that especially when it's basically still associating a 
> label with a form control.  I also think you're overloading the use of 
> the menu element too.

   The  is associated with a menu, so unless you have a
opposition to that, I don't see your point. It can be argued, however,
that the overloading of  is undesirable, I agree.

> Do you like the structure of any of these alternatives? (with the actual 
> element names still up for discussion)
> 
> 1. 
>  Jump to
>  
>

   Works, though not ideal.

> 2. 
>  Jump to 
>  Go
>

   This works. A  would provide better fallback semantics, though.

> 3. 
>  Jump to 
>  Go
>

   This is fine.

> 4. 
>  Jump to
>  Jump to
>
>  
>  Go
>

   Ditto here as well.

>>   Hmm... Is there really a use case where we'd be using  
>>elements for submenus?
> 
> Not that I can think of, but select elements could have submenus using 
> the optgroup element, as currently described in the spec.

   That's true, and they have multiple levels if you allow 
nesting.

>>Not menus, mind you, but menus within menus. If not, then we could
>>drop  from the list of possible children for  while
>>keeping the element itself.
> 
> I don't understand your logic behind this.

   If there isn't a use case for having  as a direct child of
, why allow it to be the direct child of ??? Furthermore, if
 supports multiple submenu levels, you can just use it for the
whole menu structure rather than a submenu. (Or,  could be require
to be a child of . See below.)

>>| 
>>|   ...
>>|   
>>| 
> 
> Why does  need to be a child of menu at all?  It's really more 
> of an abstraction, rather than a physical control for the user to use. 
> Wouldn't it be better for them to be declared within the  or early 
> within the  and then referenced by other controls as needed?

   Actually, I was thinking the same thing. Hence my comments about it
looking like the XUL element, which I believe to be similar. If you can
create some good examples and/or use cases for this, I'll probably back
you on that one.

   Thought:

| 
|   Menu Item 1
|   ...
| 

   Hmm. In that case, could we just require  like we do for  and
? Perhaps even replace  with , making it more like the
XHTML 2.0 element?

[whatwg] [wf2] change event

[Anne van Kesteren]

Section 4.2 states: "Change and input events must never be triggered by scripted
changes to the control value."

Section 2.13 states: "Whenever the value attribute changes (whether directly or
because the DOM under the element was mutated), a change event is fired on the
output element."

That contradicts each other, not?


-- 
Anne van Kesteren

Re: [whatwg] [wf2] change event

[Ian Hickson]

On Fri, 2 Dec 2005, Anne van Kesteren wrote:
>
> Section 4.2 states: "Change and input events must never be triggered by 
> scripted
> changes to the control value."
> 
> Section 2.13 states: "Whenever the value attribute changes (whether directly 
> or
> because the DOM under the element was mutated), a change event is fired on the
> output element."
> 
> That contradicts each other, no?

 is not a control.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [wf2] change event

[Ian Hickson]

On Thu, 1 Dec 2005, Ian Hickson wrote:
>
> On Fri, 2 Dec 2005, Anne van Kesteren wrote:
> >
> > Section 4.2 states: "Change and input events must never be triggered by 
> > scripted
> > changes to the control value."
> > 
> > Section 2.13 states: "Whenever the value attribute changes (whether 
> > directly or
> > because the DOM under the element was mutated), a change event is fired on 
> > the
> > output element."
> > 
> > That contradicts each other, no?
> 
>  is not a control.

Oh, actually, it seems that it is. I'll fix the spec to exclude  
from the "never" clause you quoted. Oops.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [wf2] change event

[Anne van Kesteren]

Quoting Ian Hickson <[EMAIL PROTECTED]>:

 is not a control.


Section 1.10 states: "The term form control refers to input, output, select,
textarea and button elements. It does not include form, label, datalist,
option, optgroup, or fieldset elements."

The first line of the description of that element (2.13) says basically the
same.

Cheers,

Anne


--
Anne van Kesteren