DOM Level 2 HTML obsolete? (Re: DOM Level 2 HTML: Note about onsubmit is misplaced in HTMLFormElement spec (in enctype attribute rather than in submit method))

On 2012-01-22 20:42, Ian Hickson wrote:
> On Sat, 21 Jan 2012, Filipus Klutiero wrote:
>> 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>
>> 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
>> trigger onsubmit. The submit method will not.
> That spec is obsolete now; for a contemporary and more thorough definition
> of the HTMLFormElement DOM API, please see the HTML standard:
>
>     http://whatwg.org/html#htmlformelement

Re: DOM Level 2 HTML obsolete?

On Thu, 2 Feb 2012, Filipus Klutiero wrote:
> 
> I must say it is far from obvious that DOM Level 2 HTML is obsolete. 
> Even looking at http://www.w3.org/standards/techs/html#stds I get to 
> http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html which 
> doesn't say anything about the DOM.

Yeah, it's a known issue. See, e.g. this thread:

   http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread.html#msg245

--

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

[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 {

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

Hello

I am not actively pursuing this at the moment, but perhaps there's
something useful to dig up from this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/thread.html#31315

There's some more discussion on the bug:
https://bugs.webkit.org/show_bug.cgi?id=71216

:DG<

On Fri, Feb 3, 2012 at 4:04 AM, François REMY <fremycompany_pub <at> yahoo.fr> wrote:
> 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 :

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

Thanks for the links. I note that some of the proposed pseudo-classes 
inteserects the ones that were proposed at www-style, which is an 
interesting fact.

However, adding pseudo-classes per-element is a bad idea since it will lead 
to inconsistencies. It should be discussed at the CSS Working Group, anyway.

I think I'm going to start a CSS editor draft about it, in the hope an UA 
implementor will take it to a higher level.

-----Message d'origine----- 
From: Dimitri Glazkov
Sent: Friday, February 03, 2012 6:34 PM
To: François REMY
Cc: DOM WG ; Alex Mogilevsky ; Lea Verou
Subject: Re: [progress-events] Loading, Interactive and Error states for 
downloaded resources -- fallback content

Hello

I am not actively pursuing this at the moment, but perhaps there's
something useful to dig up from this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/thread.html#31315

There's some more discussion on the bug:
https://bugs.webkit.org/show_bug.cgi?id=71216

:DG<

On Fri, Feb 3, 2012 at 4:04 AM, François REMY <fremycompany_pub <at> yahoo.fr> 

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

[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.

Re: Undocumented paramter

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/

Re: Optimize setting textContent?

On 02/08/2012 03:47 PM, Anne van Kesteren wrote:
> 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?
>
>

Quite horrible special case. APIs should be consistent whenever possible.
innerHTML has the same behavior as textContent. When setting
textContent/innerHTML, all the existing nodes are removed.

-Olli