headers
Arthur Barstow | 9 Feb 14:21
Picon

What is the plan for DOM3 Events spec?

Hi All,

I noticed the DOM3 Events Editor's Draft hasn't changed in what CVS 
calls "3 months" [1]. Is someone really going to push this spec on the 
Recommendation track or should we start a CfC to formally stop work on 
it? If the former, who is going to do what and when?

-Thanks, AB

[1] http://dev.w3.org/cvsweb/2006/webapi/DOM-Level-3-Events/html/
Permalink | Reply | 1 comment |
headers
Anne van Kesteren | 8 Feb 14:47
Picon
Favicon
Gravatar

Optimize setting textContent?

In https://bugzilla.mozilla.org/show_bug.cgi?id=725221 roc (cc'd, not  
subscribed to the list) suggests optimizing textContent by special casing  
the scenario where the first child is a text node and the string being set  
is non-empty. This would affect mutation observers and makes the setting  
algorithm more complicated, but it is also a performance win (in some  
implementations at least). Opinions?

--

-- 
Anne van Kesteren
http://annevankesteren.nl/
Permalink | Reply | 8 comments |
headers
bugzilla | 7 Feb 04:38
Picon

[Bug 15921] New: The WheelEvent.initWheelEvent modifiersListArg parameter should be documented

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15921

           Summary: The WheelEvent.initWheelEvent modifiersListArg
                    parameter should be documented
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM3 Events
        AssignedTo: schepers <at> w3.org
        ReportedBy: dominicc <at> chromium.org
         QAContact: member-webapi-cvs <at> w3.org
                CC: mike <at> w3.org, www-dom <at> w3.org

The documentation for this parameter says:

"Refer to the MouseEvent.initMouseEvent() method for a description of this
parameter."

However MouseEvent.initMouseEvent does not have this parameter.

--

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berengar Lehr | 6 Feb 17:22
Gravatar

Undocumented paramter

Hy,

I found an undocumented parameter in
http://www.w3.org/TR/DOM-Level-3-Events/

WheelEvent.initWheelEvent has parameter DOMString modifiersListArg,
MouseEvent.initMouseEvent() does not have this parameter and hence no
documentation even so the documentation of of WheelEvent.initWheelEvent
states:

> modifiersListArg of type DOMString
> Refer to the MouseEvent.initMouseEvent() method for a description of
this parameter.

It would be wonderfull if this parameter could be documented.

Greetings,
Berengar Lehr
Permalink | Reply | 1 comment |
headers
François REMY | 3 Feb 13:04
Picon
Favicon
Gravatar

[progress-events] Loading, Interactive and Error states for downloaded resources -- fallback content

Dear DOM Working Group,

After some requests in the CSS Working Group (www-style) [1], I would like 
to see if it was possible to start a thread on a common Object Model for 
progress and load state on downloaded resources.

The problem is the following: many of us would like to see an ":error" and a 
":loading" pseudo-classes introduced in CSS to match IMG, IFRAME, SCRIPT or 
VIDEO tags based on their load state. However, it quickly appeared that the 
CSS working group didn’t have the tools in hand to specify what the ":error" 
and ":loading" pseudo classes should match. My first attempt was to use the 
readyState property but the property can take a different set of values (and 
even different return types) on each element so it’s not a suitable 
solution. Since readyState is killed by its legacy issues, let’s define 
something new that takes in consideration that problem.

A resource may fails to load for many reasons, but the two most important 
issues are :
    (1) failled to download to resource
    (2) failled to interpret the resource (=unrecognized format).

For the download part, I propose to reuse the HttpRequest model defined in 
XHR Level 2. It could work easily for any kind of download process.

For the interpretation part, I propose the following model, based on a 
ResourceInterpreter. The ResourceInterpreter is specific to each media type 
an has the following defintion :

IResourceInterpreter := interface {
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Pieters | 31 Jan 08:49
Picon
Favicon

Re: Rename "DOM4 Events"

On Mon, 30 Jan 2012 21:17:44 +0100, Jacob Rossi  
<Jacob.Rossi <at> microsoft.com> wrote:

> I'm happy to entertain a different name. However, I have concerns with  
> "User Interface Events" since UIEvent is a particular interface out of  
> many included in the spec.

I don't understand why that is a problem. The HTML spec also has an  
element named "html" out of many included.

> If we were to scope this entirely to event constructors, we could name  
> it just that:  "DOM Event Constructors".

Most event constructors are defined elsewhere: DOM4, HTML, Progress  
Events, etc.

> But I have a feeling this spec could become a nice place for event  
> additions that are beyond the scope of DOM4 (e.g. extensions to DOM3  
> Event interfaces, new interfaces, e.g.).

Personally I think it would be "nice" if the event definitions were  
removed from DOM3 Events and moved into this spec, so that the event  
definition and its constructor are at the same place, just like the other  
events.

> If I understand Anne's concern, it's that folks will be diverted to  
> "DOM4 Events" for the general event model despite that being in DOM3  
> Events and DOM4.  Perhaps we can combat that with a very obvious section  
> at the top of the spec pointing to DOM4/D3E as the foundation upon which  
> this spec extends?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Oakley | 26 Jan 13:09

[DOM3Events] KeyboardEvent key and char clarification

As far as I can tell the rules for these properties are as follows:

The 'char' property:
The text generated by this key given the current modifiers, including
dead keys but excluding composition keys and IME.  If there was no text
then it is the empty string.

The 'key' property:
If there is something appropriate in the key values list (§ 6.2.7.2),
then use the name in the table.  If the 'char' property is not the empty
string then the value of the 'char' property.  Otherwise we can make
something up (that matches [A-Z][0-9a-zA-Z]* and is fairly sensible).

At this point I'm confused by the character values in the key values
list - they appear to be the normal character values you would get for
the given key.

Why do we use 'Tab' as the key for the tab key rather than the relevant
character (\u0009)?  Other keys also have names even though there are
appropriate characters.

Section 6.2 says that the backspace key has a different character value
and key value, but this key is not listed in the key table and I would
expect both of these to be the Unicode backspace character (\u0008).

Have I misread the specification?

--

-- 
Andrew Oakley
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kentaro Hara | 25 Jan 18:11

Re: "DOM4 Events" Proposal (was: Spec proposals for Event constructors)

Regarding event constructors, the draft Jacob wrote looks great to me.

http://html5labs.com/dom4events/

If we have consensus on the spec, I think that we should move forward
to publishing it at w3.org and progressing it towards a standard.

>>> Another feature I've been considering to add to DOM4 Events is the
>>> ability to inspect the list of registered event listeners on a node.

I think this feature would be controversial. I suggest that we move
forward to publishing the spec without adding the feature for now.
Practically, I feel that we should not block the work to define event
constructors by discussions around the new features.

People have been hoping for event constructors, especially for
MouseEvent and KeyboardEvent, because they are widely used and their
init{Mouse,Keyboard}Event(...) have soooo many arguments. In addition,
other Events (i.e. Event, CustomEvent, ProgressEvent, HashChangeEvent,
MessageEvent, ErrorEvent, PageTransitionEvent, PopStateEvent and
CloseEvent) already have constructors in their specs.

Best Regards

On Tue, Jan 24, 2012 at 10:13 PM, Alex Russell <slightlyoff <at> chromium.org> wrote:
> On Thu, Oct 20, 2011 at 10:09 AM, Ian Hickson <ian <at> hixie.ch> wrote:
>> On Thu, 20 Oct 2011, Jacob Rossi wrote:
>>>
>>> Another feature I've been considering to add to DOM4 Events is the
>>> ability to inspect the list of registered event listeners on a node.
(Continue reading)

Permalink | Reply | 9 comments |
headers
bugzilla | 24 Jan 16:32
Picon

[Bug 15695] New: Should MutationCallback be a callback *interface*?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15695

           Summary: Should MutationCallback be a callback *interface*?
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM
        AssignedTo: annevk <at> opera.com
        ReportedBy: Ms2ger <at> gmail.com
         QAContact: member-webapi-cvs <at> w3.org
                CC: mike <at> w3.org, Olli.Pettay <at> gmail.com, www-dom <at> w3.org

--

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Permalink | Reply | 0 comments |
headers
Filipus Klutiero | 21 Jan 23:14
Picon

DOM Level 2 HTML: Note about onsubmit is misplaced in HTMLFormElement spec (in enctype attribute rather than in submit method) (was Re: Minor formatting error in HTMLFormElement spec)

Dean Brettle wrote:

> In the spec for HTMLFormElement:
>
> http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357
>
> The following text should probably appear under the submit method
> instead of the enctype attribute:
>
> <quote>
> Note: The onsubmit even handler is not guaranteed to be triggered when
> invoking this method. The behavior is inconsistent for historical
> reasons and authors should not rely on a particular one.
> </quote>
>
> Also, "even" should be "event".
>
> --Dean

I agree. I think fixing this would be quite important. The behavior of 
.submit() is causing lots of confusion. See for example:
http://bugs.jquery.com/ticket/3115
http://bugs.jquery.com/ticket/4930
http://bugs.jquery.com/ticket/9704

By the way, the description of the submit method reads:
> submit
>     Submits the form. It performs the same action as a submit button.

I don't think the last sentence is correct. Using a submit input will
(Continue reading)

Permalink | Reply | 3 comments |
headers
Giuseppe Pascale | 20 Jan 16:45
Picon
Favicon

[DOM3 events] Editorial change

I think the text starting with

"Lorem ipsum dolor sit amet, consectetur adipisicing elit," here
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#remote-control

cannot be implemented and should be removed ;)

/g

--

-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software
Permalink | Reply | 0 comments |

Gmane