Re: More questions about contextual reference nodes
On 2011-04-09 19:14, Boris Zbarsky wrote:
On 4/9/11 6:27 AM, Lachlan Hunt wrote:
There were cases in JQuery where the script wanted to iteratively run a
selector on all nodes in a collection, and return elements that are
descendants of those elements. This allows :scope to be used in those
cases by passing the collection as the refNodes. There was previous
discussion of this somewhere in the public-webapps archive.
Hmm... ok.
As a simple example of that, this works in JQuery:
pspan/span
pspan/span
pspan/span
script
alert($(p).find(span).length)
/script
But is jquery's collection a JS Array?
The object returned by the $() function isn't an array. It's a custom
object that mimics the functionality of an array. This means that as
currently defined, refElements could not accept a JQuery object as the
parameter like so:
var p = $(p.foo)
Var a = $(a);
a[0].matchesSelector(:scopea, p)
This would instead require scripts to do this:
a[0].matchesSelector(:scopea, p.toArray())
JQuery effectively defines .toArray() as a function that returns:
Array.prototype.slice.call( this, 0 );
Would it be useful, and is it possible to define the refElements
parameter to accept any object that contains a .length and indexed
properties, just like a JQuery object? i.e. Can we make this work?
var x = {}
x[0] = el1;
x[1] = el2;
x[2] = el3;
x.length = 3;
a.matchesSelector(:scopea, x);
I also have to include one for HTMLCollection, which doesn't inherit
from NodeList.
Yeah, that's broken... I wonder whether we can just fix that in Web DOM
Core or something
Yes, I'd like to fix it somehow. I'm not yet sure how.
WebIDL says sequences are passed by value and arrays are passed by
reference. So I suspect using an array is better here so that it doesn't
have to create a copy.
The by reference thing only happens for array host objects, which a JS
Array is not. So the copy would effectively happen in either case, I
believe, for JS Array.
OK. Then I'm not sure what the practical difference between the
Element[] or sequenceElement would be then, nor which one to use.
Yes, I would like feedback about the best way to define this,
particularly for Arrays. In particular, how to address the following
cases.
var ref = [];
ref[0] = el1;
ref[100] = el2;
That will contain almost a million empty cells. Will iterating through
that cause any unwanted performance issues?
I believe my current Gecko implementation (using our existing variant
facilities, since that's all we have to deal with overloads for the
moment) will allocate a C array with 101 entries, then ignore it
because not everything in the array is an Element.
A DOM binding implementation using WebIDL arrays or sequences would
allocate a C++ array with 101 entries, all of which except for the
first and last are null. Then the actual implementation of the selectors
API will walk this array and add only the first and last entry to the
set of scope elements. I think. I'm pretty sure this is true for Array;
the behavior for sequence is less clear to me. And maybe this can all be
optimized in implementations, somehow... Ccing Cameron for his input.
Should we require arrays to contain contiguous Elements and only
iterate up to the first empty or non-Element cell, ignoring
anything beyond that?
If using webidl array/sequence types, that would help with the
iteration, but not the large allocation.
OK, does that mean it's not really worth defining like that?
ref[1] = string;
Should passing this now throw an exception, or should it just accept
that ref[0] was an element and use that?
Webidl array/sequence would throw in this case, I think.
Yes, I just checked and I think you may be right. The WebIDL algorithm
to convert an ECMAScript array to an IDL value of type T[] iterates the
array and says:
While i n:
Let x be the result of calling [[Get]] on V with property name
ToString(i).
Set Ei to be the result of converting x to an IDL value of type T.
Set i to i + 1.
I think the second step in the loop should throw a TypeError if the
object can't be converted to the correct type (Element, in this case).
But WebIDL doesn't seems very clear about this, so I may be wrong.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Support for matchesSelector()
On 2011-04-08 16:41, Boris Zbarsky wrote:
On 4/8/11 6:44 AM, Lachlan Hunt wrote:
We are thinking that implementing with a prefix as
Element.oMatchesSelector() is unnecessary
Well, one obvious question is whether we now have good reasons to
believe that the name and number/meaning of the arguments won't change.
The name is highly unlikely to change. There's never been any
suggestion that matchesSelector is an inappropriate name and no requests
to change it that I'm aware of.
2. Using the :scope selector in existing implementations will throw a
syntax error.
That seems, to me, like something that should prevent unprefixing, no?
The same issue will occur with any new selector that gets added in the
future. The only real difference between this and any other is that
support for :scope will inherently imply refElement support.
This means that if a script in the future wants to use a selector with
:scope, they will still be able to detect whether or not a given browser
supports it using a try/catch block.
Yes, but should it have to?
3. The existing querySelector methods also don't have a prefix, but
selectors api 2 also extends those in the same way with refNodes. This
should not be a problem for those methods.
This is true, for the reasons you described, but trying to use the new
features for the existing methods does involve that try/catch pattern
you noted. But should we really require its use for matchesSelector?
There are obvious benefits to having matchesSelector support imply that
:scope is supported too...
I'm not entirely sure what you consider to be obvious benefits. Do you
think authors should be able to do this?
if (el.matchesSelector) {
// Confirms that browser supports :scope and refNodes
} else if (el.mozMatchesSelector) {
...
} else ...
Are there any other obvious benefits that I may be missing?
I should note that the way the old methods were extended is somewhat
worrisome: as soon as a UA implements the new refNodes thing we're stuck
with it. So I really hope that either we're very sure that's what we
want to do or that UAs are careful about implementing until we get to
that very sure level. I'd prefer the former, since I've been
considering implementing this stuff.
I'm fine with waiting till we're very sure, and I hope we can get to
that stage soon. Do you have any suggestions for how we could lower the
risk of unforeseen problems in the future?
I think it makes sense for matchesSelector and querySelector to use a
common API design and accept the same parameters.
As far as I know, there are a few options we have:
1. Leave the spec as is and implement with the refElements parameter.
This has the advantage of keeping the API simple.
2. Create a more generic extension mechanism, such as an options
parameter. Then define the method as
matchesSelector(selector, options);
Where options is defined to take an object with various properties, like
this:
options = {
ref: [el1, el2], // Reference nodes
ns: [...], // Namespaces
... // Other future extensions
}
This would allow for easier extensions in the future where the method
just ignores unknown options, but at the expense of a more complex
syntax. It's not clear what the chances are of wanting more extensions,
nor if it's worth the complexity cost to go down such a path now merely
as a precaution.
2a. Initially do what the spec says (#1), and then if such extensions
are wanted in the future, overload the method in a backwards compatible
way to accept both an refElements or an options object (#2). That is,
if adding a 3rd parameter or introducing a new method is undesirable.
3. Introduce new methods every time we want to add a new feature.
This isn't the most scalable, but might be the best option when it comes
to namespace support, if we ever decide it's necessary to support that.
I'd rather not have to do it for refElements, since it would mean that
the existing methods and the new methods without refElements would be
functionally identical.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: How many ways to save store app data?
On Mon, Mar 28, 2011 at 4:21 PM, Arthur Barstow art.bars...@nokia.com wrote: Louis-rémi's thread [1] on AppCache led to discussions about other storage related APIs including DataCache, Google Gears, IDB and the File * APIs. Of note, Google Gears is basically gone (as of Google Chrome 12 and similar): http://gearsblog.blogspot.com/2011/03/stopping-gears.html
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Tue, Mar 29, 2011 at 2:37 PM, Arthur Barstow art.bars...@nokia.com wrote:
http://dev.w3.org/2006/webapi/clipops/clipops.html
If you have any comments or concerns about this proposal, please send them
to public-webapps by April 5 at the latest.
Sorry, i've been doing other stuff
[editorial]
Mathematical information
With content such as mathematics, simply copying rendered text and pasting it
into another application generally leads to most of the semantics being lost.
I think math is more appropriate here.
And probably leads to the loss of most of the semantics.
Also, the XML source could be placed in the clipboard with the appropriate
transformation occurring when pasting.
The XML source can also ...
I find when pasting problematic. At paste time might be better, or
some indication of which side is doing the transformation.
---
interface ClipboardEvent : Event {
void initClipboardEvent (in DOMString eventType, in boolean canBubble, in
boolean cancelable, in DOMString dataType, in DOMString data);
doesn't seem to allow for multiple flavors.
clipboardData of type DataTransfer, readonly
The clipboardData attribute is an instance of the DataTransfer interface
which lets a script read and manipulate values on the system clipboard during
user-initiated copy, cut and paste operations. The associated drag data store
is a live but filtered view of the system clipboard, exposing all data types
the implementation knows the script can safely access.
safely seems underspecified, you probably should clarify that this
includes not exposing anything for synthetic events.
5.3 Determining the target property for clipboard events
In an editable context, the event object's target property must refer to the
element that contains the start of the selection in document order, i.e. the
end that is closer to the beginning of the document.
iirc DOMRanges can have start after end to indicate that the user has
made a selection in reverse. Is there a reason to ignore that
information and give different targets each time the user extends the
selection?
Calling getData() too many or too few arguments should throw
calling foo() _with_
Calling clearData() empties the system clipboard, or removes the specified
type of data from the clipboard. See HTML5 for details [HTML5].
This has issues. If the user has inserted something the user cares
about into the system clipboard, then allowing a web page to stomp on
it is annoying. Something needs to protect the user from such web
apps.
Calling getData() from within a paste event handler will return the clipboard
data in the specified format. See HTML5 for details [HTML5].
doesn't explain what should happen when the web app tries to paste a
content type the user agent has decided it shouldn't have access to.
The event is asyncronous but must be dispatched before keyup events for the
relevant keys.
asynchronous
The user might paste hidden data which the user is not aware of.
.. not aware of is kinda messy. Also, perhaps hidden data already
indicates the user doesn't know about it?
The implementation must not download referenced online resources and expose
their contents in the FileList.
s/and/or/
Objects implementing the DataTransfer interface to return clipboard data
must not be available outside the ClipboardEvent event handler.
If a script stores a reference to an object implementing the DataTransfer
interface to use from outside the ClipboardEvent event handler, all methods
must be no-ops when called outside the expected context
Implementations must not let scripts create synthetic clipboard events to
get access to real clipboard data
the last two points are missing periods
Implementations must handle scripts that try to place excessive amounts of
data on the clipboard gracefully.
I hope gracefully is flexible. If my impl wants to terminate the
page, it should be able to do so. (I don't expect it to do so, but I
reserve the right)
Remove all of the following elements: SCRIPT, APPLET, OBJECT, FORM, INPUT,
BUTTON, TEXTAREA, SELECT, OPTION, OPTGROUP and comment nodes. For all
mentioned elements except FORM, also remove all child nodes.
I can imagine doing magical things with a style tag...
However, removing the active value from a select seems suboptimal.
If you see:
State: [ |v]
And use it to get:
State: [ Washington |v]
When you copy it, do you expect:
State: or State: Washington? I expect the latter, it's
considerably more useful.
Re: CfC: new WD of Clipboard API and Events; deadline April 5
comments on a couple of timeless' comments. On Sun, 10 Apr 2011 18:20:35 +0200, timeless timel...@gmail.com wrote: On Tue, Mar 29, 2011 at 2:37 PM, Arthur Barstow art.bars...@nokia.com wrote: http://dev.w3.org/2006/webapi/clipops/clipops.html If you have any comments or concerns about this proposal, please send them to public-webapps by April 5 at the latest. Sorry, i've been doing other stuff [editorial] Mathematical information With content such as mathematics, simply copying rendered text and pasting it into another application generally leads to most of the semantics being lost. I think math is more appropriate here. Disagree. In explanatory text the more correct term is clearer. math is only american in usage, and avoiding the feeling that it is a typo would reduce congitive dissonance without being incorrect. Calling clearData() empties the system clipboard, or removes the specified type of data from the clipboard. See HTML5 for details [HTML5]. This has issues. If the user has inserted something the user cares about into the system clipboard, then allowing a web page to stomp on it is annoying. Something needs to protect the user from such web apps. Yes - should that comment be on HTML5 though, or alternatively is there a reason not to copy it? The user might paste hidden data which the user is not aware of. .. not aware of is kinda messy. Also, perhaps hidden data already indicates the user doesn't know about it? not realising it is there? Remove all of the following elements: SCRIPT, APPLET, OBJECT, FORM, INPUT, BUTTON, TEXTAREA, SELECT, OPTION, OPTGROUP and comment nodes. For all mentioned elements except FORM, also remove all child nodes. I can imagine doing magical things with a style tag... However, removing the active value from a select seems suboptimal. If you see: State: [ |v] And use it to get: State: [ Washington |v] When you copy it, do you expect: State: or State: Washington? I expect the latter, it's considerably more useful. Agree. -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: More questions about contextual reference nodes
On 2011-04-10 13:30, Lachlan Hunt wrote:
But is jquery's collection a JS Array?
The object returned by the $() function isn't an array. It's a custom
object that mimics the functionality of an array...
var p = $(p.foo)
Var a = $(a);
a[0].matchesSelector(:scopea, p)
...
Would it be useful, and is it possible to define the refElements
parameter to accept any object that contains a .length and indexed
properties, just like a JQuery object? i.e. Can we make this work?
var x = {}
x[0] = el1;
x[1] = el2;
x[2] = el3;
x.length = 3;
a.matchesSelector(:scopea, x);
I reviewed WebIDL again, and I think I've started to understand the
difference between sequenceT and T[] now.
As I understand it, the algorithm to convert an ECMAScript object to an
IDL sequence should work with any object that has a length property and
indexed values containing Node objects. That is true for an Array of
Nodes, NodeList, HTMLCollection and the above JQuery case, they can all
be handled in the same way.
This seems to differ from the algorithm given for T[], which requires
that the object be either an array host object or a native object, which
would not handle the JQuery case. The sequenceT type seems more
generic than that as the algorithm seems to be able to support any
object with a length and indexed properties.
I've updated and simplified the spec to handle the above case using the
parameter sequenceNode. I still need to update the prose to say that
while the collections may contain any Node, only Element nodes are added
to the list of contextual reference elements. But the following cases
should all work.
1. Array of Elements
document.querySelector(:scopea, [el1, el2, el3]);
2. NodeList
document.querySelector(:scopea, el.childNodes);
3. NodeList converted to an array
document.querySelector(:scopea,
Array.prototype.slice.call(el.childNodes, 0));
// Conversion to an array is unnecessary here, but just showing that
// it will work anyway.
4. HTMLCollection
s.matchesSelector(:scope~a, document.images);
5. Objects with indexed properties, including JQuery
var x = {}
x[0] = el1;
x[1] = el2;
x[2] = el3;
x.length = 3;
document.querySelector(:scopea, x);
x = $(.foo, .bar);
a.matchesSelector(:scopea, x);
a.matchesSelector(:scopea, x.toArray());
// Unnecessary converstion to array here
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: More questions about contextual reference nodes
On 04/09/2011 07:14 PM, Boris Zbarsky wrote: On 4/9/11 6:27 AM, Lachlan Hunt wrote: I also have to include one for HTMLCollection, which doesn't inherit from NodeList. Yeah, that's broken... I wonder whether we can just fix that in Web DOM Core or something If people are willing to implement that, certainly. -- Ms2ger
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Sun, Apr 10, 2011 at 9:30 PM, Charles McCathieNevile cha...@opera.com wrote: Disagree. In explanatory text the more correct term is clearer. math is only american in usage, and avoiding the feeling that it is a typo would reduce congitive dissonance without being incorrect. ok not realising it is there? sounds good
