Re: [editing] Using public-webapps for editing discussion

[Charles Pritchard]

On 9/15/2011 1:26 PM, Aryeh Gregor wrote:

On Wed, Sep 14, 2011 at 7:30 PM, Arthur Barstow  wrote:

Since some related functionality was included (at one point) in the HTML5
spec, it seems like we should ask the HTML WG for feedback on Aryeh's email.

Aryeh told me there are some related bugs:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13423
  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13425

Maciej, Sam, Ruby - do have a sense if the HTML WG has a (strong) opinion on
Aryeh's question below?

I should point out that the WebApps WG's charter lets it take on specs
split out from HTML5.  For such specs to be merely discussed here
should be no impingement on the HTML WG's scope, a fortiori.


I appreciate you bringing the spec to this group. I'll find time to 
review and comment.

[Bug 14067] Value for createLink and unlink can be null instead of a string

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14067

Aryeh Gregor  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Aryeh Gregor  2011-09-15 22:28:02 UTC ---
Fixed properly this time:

https://dvcs.w3.org/hg/editing/rev/3cc579b879ac

Where "properly" means "with more special cases", naturally.  But it works.

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

[Bug 14067] Value for createLink and unlink can be null instead of a string

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14067

Aryeh Gregor  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

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

[Bug 14067] Value for createLink and unlink can be null instead of a string

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14067

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Aryeh Gregor  2011-09-15 21:10:33 UTC ---
https://dvcs.w3.org/hg/editing/rev/d0760b6d50a5

-- 
Configure bugmail: http://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: [editing] Using public-webapps for editing discussion

[Aryeh Gregor]

On Wed, Sep 14, 2011 at 7:30 PM, Arthur Barstow  wrote:
> Since some related functionality was included (at one point) in the HTML5
> spec, it seems like we should ask the HTML WG for feedback on Aryeh's email.
>
> Aryeh told me there are some related bugs:
>
>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13423
>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13425
>
> Maciej, Sam, Ruby - do have a sense if the HTML WG has a (strong) opinion on
> Aryeh's question below?

I should point out that the WebApps WG's charter lets it take on specs
split out from HTML5.  For such specs to be merely discussed here
should be no impingement on the HTML WG's scope, a fortiori.

On Thu, Sep 15, 2011 at 12:31 AM, Charles Pritchard  wrote:
> I don't see Shelley Powers' objection being addressed. She has expressed
> concerns that the HTML Editing APIs have been taken out of W3C WGs and
> associated processes.

Your wording suggests that the functionality was ever meaningfully
specified within a W3C WG.  This is not the case.  The specification
text in the HTML5 draft was unusable and would have had to be removed
eventually anyway, because it was untestably vague.  The current HTML
Editing APIs specification was written from scratch and was never
within the W3C until now, when it's been moved into a Community Group.

Community Groups are within the W3C.  Presumably the reason the W3C
created Community Groups is because it would like people to use them
for specification development, so using them for that purpose seems
like it should be uncontroversial.  The specification is not covered
by W3C's Process, but in my opinion that's a good thing, for reasons I
have laid out elsewhere in detail.

> Apple, Google and Microsoft representatives have vetoed rich text editing as
> a supported use case for public-canvas-api, the Google/WHATWG editing
> specification is now the -only- supported solution for developers to author
> editing environments.

It is not accurate to refer to the specification as Google or WHATWG.
It's in the public domain, so Google has no more right to it than
anyone else.  Google paid for its development up to this point, but no
one from Google but me has exercised any discretion as to its
contents, and I'll continue working on it under different employment
if necessary.  The spec has nothing to do with the WHATWG, except that
I used their mailing list for a while.

You can refer to it as "the HTML editing specification", since it's
the only one.  Or "the HTML Editing APIs specification", to use its
.  If you would like to disambiguate, you can refer to it as
mine, since I'm the author and editor.

> Aryeh, consider releasing more authority to the W3C process. The
> specification is fairly mature, I'm not seeing push-back on this spec, and I
> know that there are several voices which would better served through formal
> process.

I disagree.  I don't believe that the W3C Process is useful, and in
fact I think it's actively harmful, at least for the type of spec I'm
working on.  I support the W3C Community Groups initiative and believe
it will serve a very valuable purpose, and I object to others'
attempts to undermine the W3C's goals in undertaking that initiative.
If it eventually does prove useful to move the specification to REC
track, that can easily be done at any later date.  There is nothing to
gain and much to lose by prematurely abandoning this trial of the
W3C's bold and commendable attempt to introduce alternative, less
cumbersome ways to develop web specifications.

> Also, try to get this onto the hg repositories, in the same style
> that DOM4 has been entered. It works well for maintaining your CC0/WHATWG
> labels while also providing the W3C with a publishable draft under their own
> restrictions.

The authoritative version control history has been at dvcs.w3.org
since Ian Jacobs gave me access a couple of days ago:

https://dvcs.w3.org/hg/editing

Note that this is the first link for version history at the top of the
draft, with the second one being a github mirror for those who prefer
git:

http://aryeh.name/spec/editing/editing.html

Currently the specification itself is still hosted at aryeh.name
because the Community Group technical infrastructure isn't finished
yet.  As soon as I'm able to post an up-to-date version of the spec at
w3.org, I'll move it there and change the aryeh.name URL to a
redirect.

Proposal to add Mouse Lock to the Web Events Working Group

[Vincent Scheib]

A Mouse Lock API has been under discussion on the W3 public-webapps list
"Mouse Lock"[1] and earlier "Mouse Capture for Canvas"[2].

The primary goal is to enable use cases such as first person perspective 3D
applications. This is done by providing scripted access to mouse movement
data while locking the target of mouse events to a single element and
removing the cursor from view.

I have been working to formalize the discussions into a draft
specification[3]. I propose that the Web Events Working Group consider
adoption of Mouse Lock for formal specification.

Cheers, -Vince

1.
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960
2.
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437
3. http://goo.gl/9G8pd

Additional discussions:
W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557
Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602
Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754

Re: RfC: Is Web Sockets API ready for LC publication? [Was: Re: [websockets] Getting WebSockets API to Last Call]

[Arthur Barstow]

As an update on this RfC, note that ATM, 13777 is the only non-editorial 
bug that remains open:




I would appreciate it, if people would please provide input on this bug.

-AB


On 9/9/11 6:05 PM, ext Brian Raymor wrote:
  13777 - The WebSocket protocol draft (hybi-10) restricts the value 
of subprotocols as follows: The elements that comprise this value 
MUST be non- empty strings with characters in the range U+0021 to 
U+007E not including separator characters as defined

New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in 
this bug.

DOM4 published ; please use www-dom for related discussions

[Arthur Barstow]

DOM4 was published in /TR/ today 
<http://www.w3.org/TR/2011/WD-dom-20110915/>.


Please use www-...@w3.org for all DOM4 discussions.

Re: CfC: new WD of Clipboard API and Events; deadline April 5

[Hallvord R. M. Steen]

On Tue, 06 Sep 2011 00:51:01 +0200, Glenn Maynard  wrote:

I'd hoped to see browsers adjust behavior so clipboard copying happens  
before anything else (before firing DOM events at all), making it more  
difficult for pages to fiddle with the selection before the copy occurs


If we spec'ed that, what would the point of firing the events be?

How would you solve the use cases we're trying to solve?

Your concerns are valid but need UI-work, preferences and other stuff that  
is generally considered UA features and outside of a technical API spec.


--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Re: [DOM4] Remove Node.isSameNode

[Anne van Kesteren]

On Fri, 09 Sep 2011 19:21:53 +0200, Jonas Sicking  wrote:

It's a completely useless function. It just implements the equality
operator. I believe most languages have a equality operator already.
Except Brainfuck [1]. But the DOM isn't implementable in Brainfuck
anyway as it doesn't have objects, so I'm ok with that.


If you can get this removed from Gecko without it causing compatibility  
issues consider it gone from the specification. I'm all for less methods,  
especially useless methods.




[1] http://en.wikipedia.org/wiki/Brainfuck



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [DOM4] Remove Node.isSameNode

[Jonas Sicking]

On Fri, Sep 9, 2011 at 8:05 PM, Charles Pritchard  wrote:
> On 9/9/2011 6:02 PM, Jonas Sicking wrote:
>>
>> On Fri, Sep 9, 2011 at 3:42 PM, Charles Pritchard  wrote:
>>>
>>> On Sep 9, 2011, at 2:27 PM, Sean Hogan  wrote:
>>>
 On 10/09/11 3:21 AM, Jonas Sicking wrote:
>
> It's a completely useless function. It just implements the equality
> operator. I believe most languages have a equality operator already.
> Except Brainfuck [1]. But the DOM isn't implementable in Brainfuck
> anyway as it doesn't have objects, so I'm ok with that.
>
> [1] http://en.wikipedia.org/wiki/Brainfuck
>
 If a DOM implementation returns  node-wrappers instead of exposing the
 actual nodes then you could end up with different node-refs for the same
 node. I'm not sure whether that violates other requirements of the spec.
>>>
>>> A similar method is present in the JS libs too, like jQuery. If it is
>>> necessary, is a Node.isSameType useful?
>>
>> I take it you mean "isSameNode", right?
>>
>> Do you have a pointer to the jQuery function?
>>
>> / Jonas
>>
>
> For jQuery, I think the is() method is the one; it's used for various
> things, but $(element).is($(element)) returns true, I believe.
> Typically that parameter is going to be selector, or an already existing
> variable, resulting from perhaps another selector.
>
> http://api.jquery.com/is/
>
>
>
> I meant isSameType: as a shortcut to comparing nodeType and Element local
> name.
> element.isSameType(myParagraphElement);
>
> I'm not a fan of the  if(element instanceof HTMLParagraphElement) style.
> This is just some sugar.
>
> isSameType (in the same style of isEqualNode):
> The isSameType(node) method must return true if all of the following
> conditions are true, and false otherwise:
> * node is not null.
> * node's nodeType attribute value is the same as the context object's
> nodeType attribute value.
>
> The following are also equal, depending on node:
>
> DocumentType
>    Its name, public ID, and system ID.

So it sounds like the jQuery function is infact not the same thing as
the isSameNode function. Something like the jQuery isSameType might be
more interesting, so feel free to suggest that in a separate thread.

/ Jonas

Re: [DOM4] Remove Node.isSameNode

[Jonas Sicking]

On Fri, Sep 9, 2011 at 7:24 PM, Bjoern Hoehrmann  wrote:
> * Jonas Sicking wrote:
>>It's a completely useless function. It just implements the equality
>>operator. I believe most languages have a equality operator already.
>
> It's quite normal for object models to not guarantee that "the" equality
> operator works for object identity comparison, COM being a prime example
> where this is only guaranteed for IUnknown pointers. Leading to issues
> like http://www.mail-archive.com/mozilla-xpcom@mozilla.org/msg05045.html
> but that's life.

This just means that for COM objects, the equality operator is not the
C++ equality operator. You'll note that COM generally doesn't
introduce a isSameX function for each and every interface, but instead
relies on people QIing to IUnknown.

> It is also useful to have this as function available in
> environments where "the object identity operator" is not available as a
> function. In JavaScript, if function arity is ignored as is typical,
>
>  [].some.call(nodelist, node.isSameNode, node)
>
> can be used to check whether a node is in a node list, the "equivalent"
>
>  [].some.call(nodelist, function(elem) { return elem === node; })
>
> is a good bit worse if you want to use this as condition in an if block
> as you would run past line length restrictions easily and would have to
> put this on several lines.

This logic would also dictate that we should introduce isNotSameNode,
isParentNode, isNextSiblingNode, isPreviousSiblingNode, etc functions.
And of course, isSameBlob, isSameXMLHttpRequest, isSameCSSRule etc.

I would prefer to have people write the little bit of extra code
needed in your second example above.

> Using proxying wrappers is quite a common
> practise http://code.activestate.com/lists/python-list/399236/ so I do
> not see why everybody should spend resources removing this method.

I can guarantee that the people that will have to spend resources
removing this function would spend more resources if it's kept. Just
in the last two weeks I've spent more resources ensuring that this
function works than it would take for me to remove it from Firefox.

/ Jonas