RE: focus/blur events

Hi, Ian-

I agree that we should use normative language (such as "must", "should",
"may") in the DOM3 Spec, but I don't agree that that is the sole criterion
for whether something is defined in a Spec. The intent of terms such as
"occurs", "is", and "can be" is clear to most people.

In fact, nothing in that entire section uses normative language, nor is the
section marked explictly as normative [1]. DOMFocusIn is just as well
defined as "click":

| click
|     The click event occurs when the pointing device button is clicked over
an 
|     element. A click is defined as a mousedown and mouseup over the same
screen
|     location. The sequence of these events is:
| 
|         mousedown
|         mouseup
|         click
|        
| 
|     If multiple clicks occur at the same screen location, the sequence
repeats 
|     with the detail attribute incrementing with each repetition. This
event is 
|     valid for most elements.
| 
|         * Bubbles: Yes
|         * Cancelable: Yes
|         * Context Info: screenX, screenY, clientX, clientY, altKey,
ctrlKey, 
|         shiftKey, metaKey, button, detail


If you are trying to make another point besides the need for greater
precision going forward, please state your point more clearly.
 

[1] http://www.w3.org/TR/DOM-Level-2-Events/events.html

Regards-
Doug
 

Ian Hickson wrote:
| 
| On Wed, 29 Mar 2006, Mark Birbeck wrote:
| > 
| > On the one hand, the DOMFocusIn and Out events are in the 
| DOM 2 Events spec,
| > and have been for nearly six years.
| 
| Have they? Look at the spec. This is the sum total of the spec for 
| DOMFocusIn:
| 
| | DOMFocusIn
| |     The DOMFocusIn event occurs when an EventTarget 
| receives focus, for 
| |     instance via a pointing device being moved onto an 
| element or by 
| |     tabbing navigation to the element. Unlike the HTML event focus, 
| |     DOMFocusIn can be applied to any focusable EventTarget, 
| not just 
| |     FORM controls.
| |
| |        * Bubbles: Yes
| |        * Cancelable: No
| |        * Context Info: None
| 
| What does it normatively define? Nothing other than the name, and it 
| doesn't even require support for that. It doesn't require any 
| UA to fire 
| the event. This definition is effectively worthless.
| 
| So what does it mean for DOMFocusIn to be "in" the DOM2 Events spec?
| 
| That's what I'm asking.
| 
| 
| > But do you mean that really they should be in a separate 
| spec? That DOM 
| > 3 Events should focus on the architecture, whilst the 
| actual naming and 
| > behaviour of the events themselves should be elsewhere? If 
| so, I for one 
| > would certainly agree with that, especially since many 
| events will be 
| > little 'clusters' based around some defined functionality. A much 
| > smaller, leaner spec purely concentrating on control 
| navigation could 
| > describe these events.
| 
| Exactly. If a spec wants to use an event, it should define 
| the event -- 
| which means defining normative testable conformance criteria 
| stating when 
| the event must be fired, on what it must be fired, what the default 
| actions are, what event interface the object should use, what the 
| attributes should be initialised to, and so forth.
| 
| DOM2 Events doesn't do any of that.

Received on Thursday, 30 March 2006 06:11:14 UTC