Re: Mutation events replacement
Hi all,
here is a bit different proposal for mutation events replacement.
This is using the mostly-sync approach, and batching can make it easier
to use with several simultaneous script libraries; each one would use
their own batch.
For performance reasons it might be useful to have an attribute name
filter for AttrChange, but such thing could be added later.
One advantage this approach has is that it doesn't pollute Node API.
-Olli
interface Modification {
/**
* type is either TextChange, ChildListChange or AttrChange.
* (More types can be added later if needed.)
*/
readonly attribute DOMString type;
/**
* Target of the change.
* If an attribute is changed, target is the element,
* if an element is added or removed, target is the node
* which was added or removed.
* If text is changed, target is the CharacterData node which was
* changed.
*/
readonly attribute Nodetarget;
/**
* parent node of the target right before the change happened,
* or null.
*/
readonly attribute NodetargetParent;
/**
* The node which is batching the change.
*/
readonly attribute NodecurrentTarget;
/**
* The name of the attribute which was changed, or null.
*/
readonly attribute DOMString attrName;
/*
* The previous value of the attribute or CharacterData node, or null.
* If a new attribute is added, prevValue is null.
*/
readonly attribute DOMString prevValue;
/*
* The new value of the attribute or CharacterData node, or null.
* If an attribute is removed, newValue is null.
*/
readonly attribute DOMString newValue;
};
[Callback, NoInterfaceObject]
interface ModificationCallback {
void handleBatch(in ModificationBatch aBatch);
};
[Constructor(in ModificationCallback aDoneCallback)]
interface ModificationBatch {
/**
* Modifications is non-empty array only while aDoneCallback
* is called. And while that happens, modifications list doesn't
* change.
*/
readonly attribute Modification[] modifications;
void batchTextChanges(in Node aNode);
void unbatchTextChanges(in Node aNode);
void batchChildListChanges(in Node aNode);
void unbatchChildListChanges(in Node aNode);
void batchAttrChanges(in Node aNode);
void unbatchAttrChanges(in Node aNode);
void batchAll();
void unbatchAll();
};
aDoneCallback is called right before the call which is modifying DOM
returns. If aDoneCallback modifies DOM, new modifications list will be
collected
and callbacks will be called right after the initial aDoneCallback returns.
ModificationBatches are always handled in the order they are *created*.
Callbacks are never called if modifications list is empty.
Example 1:
// log all the attribute changes
var o = new ModificationBatch(function(b) {
for (var i = 0; i
b.modifications.length; ++i) {
var m = b.modifications[i];
if (m.prevValue == null) {
console.log(m.attrName + added);
} else if (m.newValue == null) {
console.log(m.attrName + removed);
} else {
console.log(m.attrName + modified);
}
}
}
);
o.batchAttrChanges(document);
Re: Mutation events replacement
/** * The name of the attribute which was changed, or null. */ readonly attribute DOMString attrName; There should be probably also attribute namespace void batchAttrChanges(in Node aNode); A filter could be added here -void batchAttrChanges(in Node aNode); +void batchAttrChanges(in Node aNode, [optional] in DOMString aReportValues); Where aReportValues could a comma separated list of attr localNames, or *. Default would be to report only that the attribute has changed, but to not include any values.
Re: [IndexedDB] Transaction Auto-Commit
On Aug 4, 2011 12:28 AM, Joran Greef jo...@ronomon.com wrote: On 03 Aug 2011, at 7:33 PM, Jonas Sicking wrote: Note that reads are also blocked if the long-running transaction is a READ_WRITE transaction. Is it acceptable for a writer to block readers? What if one tab is downloading a gigabyte of user data (using a workload-configurable Merkle tree scheme), and another tab for the same application needs to show data? This is exactly why transactions are auto-committing. We don't want someone to start a transaction, download a gigabyte of data, write it to the database, and only after commit the transaction. The auto-committing behavior forces you to download the data first, only then can you start a transaction to insert that data into the database. If someone were syncing a gigabyte of data using a Merkle tree scheme they would probably not consider using a single transaction to persist the data nor would they find it necessary. Rather the point was made to emphasize that a write-intensive task may take place where many write transactions are required, one after the other. For instance, in the previous example, a gigabyte of data may likely consist of a million 1KB text objects, or 250,000 4KB objects, each of which may require a write transaction to update a few parts of the database. Any implementation of IDB where writers blocked readers would perform poorly in this case. But all of this is orthogonal to the question of auto-commit. Are there other reasons in favor of auto-committing transactions? I'm not sure that library writers stand to gain from it, and it forces one to use other methods of concurrency control to match the semantics of server-side databases. The two main reasons is to prevent people from performimg slow running tasks, such as network activities, while keeping the transition open, and to prevent people from accidentally forgetting to commit a transaction, for example if a exception is thrown. IndexedDB allows MVCC in that it allows writers to start while there are still reading transactions running. Firefox currently isn't implementing this though since our underlying storage engine doesn't permit it. IndexedDB does however not allow readers to start once a writing transaction has started. I thought that that was common behavior even for MVCC databases. Is that not the case? Is it more common that readers can start whenever and always just see the data that was committed by the time the reading transaction started? If your database supports MVCC, then by definition there is no reason for writers to block readers. I'd be open to allowing read transactions which are started after a write transaction to see the before-write database contents. Would definitely want input from Microsoft and Google first though. There is also a question if this should be opt-in or default behavior. My gut feeling is to leave this for version 2. Though that of course removes the ability to make it default behaviour.
Re: publish new WD of DOM Core; deadline August 10
On Thu, 04 Aug 2011 21:06:58 +0200, Adrian Bateman adria...@microsoft.com wrote: The name was changed. We weren't terribly keen on the change. It is now causing problems. I've had multiple people contact me confused about this. We should fix the problem. Alright, how about DOM4? This functionality shouldn't be pulled into DOM Core. We believe improvements for mutation events should be kept a separate deliverable for this working group (ADMN). I am not sure what ADMN means. This is in the WG charter. Thanks. (FWIW, several proposals so far have been synchronous.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Mutation events replacement
On 08/04/2011 10:14 PM, David Flanagan wrote:
On 8/4/11 6:38 AM, Olli Pettay wrote:
Hi all,
here is a bit different proposal for mutation events replacement.
This is using the mostly-sync approach, and batching can make it easier
to use with several simultaneous script libraries; each one would use
their own batch.
For performance reasons it might be useful to have an attribute name
filter for AttrChange, but such thing could be added later.
One advantage this approach has is that it doesn't pollute Node API.
-Olli
I'm intrigued by the idea, but confused by the API (or at least by
naming issues in the API).
- ModificationBatch is both a batch of modifications and also a set of
methods for requesting modification batches. Should there be separate
ModificationBatch and ModificationBatcher interfaces?
Why? You have an object which can listen for some modifications and then
at some point call the callback that some modifications have happened.
But perhaps the interface could be called something else. I'd like it to
have batch or some similar meaning in it.
- The pattern of passing a callback function to a constructor is novel
in the DOM. Will this confuse people too much?
Well, I don't think new Foo(callback); is more difficult to understand
than say
var foo = new Foo();
foo.onSomething = callback;
Also, if the callback is
passed to the constructor, there isn't a deregistration method. I assume
that you achieve this by calling unbatchAll(),
Yes that, or calling unbatchFoo if you called batchFoo before.
but that seems
non-parallel.
Registering the callback doesn't need to have anything parallel.
It is the batch*/unbatch* which are parallel.
And batch/unbatchAll are kind of catch-all.
What if the ModificationCallback was passed to the
individual batch/unbatch methods instead?
Well, the whole idea is that the same callback would handle a batch of
modifications.
- The name batchTextChanges() implies to me that it is expressing a
preference to receive text changes in batched form, and that if you
don't call this method you'll still get text changes, just one at a
time. I don't think that is the intent, but that is what the name
implies to me. How about something (verbose) like
addTextChangeBatchListener() (and pass the ModificationCallback to this
method instead of to the constructor)
As I said, the idea is not to have separate ModificationCallbacks for
different types, but to have a callback per ModificationBatch.
If you need different callbacks, you can create a new ModificationBatch.
But yes, the naming can be changed, if it is misleading.
Suggestions welcome :)
-Olli
David
interface Modification {
/**
* type is either TextChange, ChildListChange or AttrChange.
* (More types can be added later if needed.)
*/
readonly attribute DOMString type;
/**
* Target of the change.
* If an attribute is changed, target is the element,
* if an element is added or removed, target is the node
* which was added or removed.
* If text is changed, target is the CharacterData node which was
* changed.
*/
readonly attribute Node target;
/**
* parent node of the target right before the change happened,
* or null.
*/
readonly attribute Node targetParent;
/**
* The node which is batching the change.
*/
readonly attribute Node currentTarget;
/**
* The name of the attribute which was changed, or null.
*/
readonly attribute DOMString attrName;
/*
* The previous value of the attribute or CharacterData node, or null.
* If a new attribute is added, prevValue is null.
*/
readonly attribute DOMString prevValue;
/*
* The new value of the attribute or CharacterData node, or null.
* If an attribute is removed, newValue is null.
*/
readonly attribute DOMString newValue;
};
[Callback, NoInterfaceObject]
interface ModificationCallback {
void handleBatch(in ModificationBatch aBatch);
};
[Constructor(in ModificationCallback aDoneCallback)]
interface ModificationBatch {
/**
* Modifications is non-empty array only while aDoneCallback
* is called. And while that happens, modifications list doesn't
* change.
*/
readonly attribute Modification[] modifications;
void batchTextChanges(in Node aNode);
void unbatchTextChanges(in Node aNode);
void batchChildListChanges(in Node aNode);
void unbatchChildListChanges(in Node aNode);
void batchAttrChanges(in Node aNode);
void unbatchAttrChanges(in Node aNode);
void batchAll();
void unbatchAll();
};
aDoneCallback is called right before the call which is modifying DOM
returns. If aDoneCallback modifies DOM, new modifications list will be
collected
and callbacks will be called right after the initial aDoneCallback
returns.
ModificationBatches are always handled in the order they are *created*.
Callbacks are never called if modifications list is empty.
Example 1:
// log all the attribute changes
var o = new ModificationBatch(function(b) {
for (var i = 0; i b.modifications.length; ++i) {
var m = b.modifications[i];
if (m.prevValue == null) {
[Bug 13063] MessagePort normatively referenced by not defined
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13063 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-04 21:28:44 UTC --- ? -- 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 13065] WindowTimers normatively referenced by not defined
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13065 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-04 21:29:27 UTC --- same as bug 13064? -- 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 13064] WindowBase64 normatively referenced by not defined
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13064 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-04 21:29:00 UTC --- I don't understand what you mean. -- 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 13083] postMessage should have an optional parameter for a synchronous request. Cross-domain AJAX calls are enough of a problem that it merits a supported way of fixing it, and this could be it
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13083 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WONTFIX --- Comment #3 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-04 21:29:49 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: This is intentionally not synchronous. -- 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 13020] No user agent will implement the storage mutex so this passage does not reflect reality
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13020 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED 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 13155] The security considerations section needs to be updated to take CORS into account.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13155 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch 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 13156] The charset parameter is now an optional parameter (even though it can only be set to UTF-8). That should probably be stated here.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13156 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch 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 13063] MessagePort normatively referenced by not defined
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13063
Glenn Adams gl...@skynav.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NEEDSINFO |
--- Comment #2 from Glenn Adams gl...@skynav.com 2011-08-04 21:46:22 UTC ---
An interface/object type MessagePort is referenced numerous times; e.g., the
port IDL attribute below:
4.7.3 Shared workers and the SharedWorker interface
[Constructor(in DOMString scriptURL, in optional DOMString name)]
interface SharedWorker : AbstractWorker {
readonly attribute MessagePort port;
};
However, nowhere in this spec is a definition of MessagePort provided or
referenced.
See the latest draft 28 July 2011.
(In reply to comment #1)
?
--
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 13064] WindowBase64 normatively referenced by not defined
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13064 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|NEEDSINFO |INVALID --- Comment #2 from Glenn Adams gl...@skynav.com 2011-08-04 21:52:30 UTC --- closing... either it was added in subsequent draft or i missed it in my initial review -- 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: Element.create(): a proposal for more convenient element creation
On Wed, Aug 3, 2011 at 8:10 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Aug 3, 2011 at 12:34 AM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
MooTools is basically identical to Prototype, except that you can
additionally set listeners on the element during creation by using a
magical events property in the attribute bag, which takes an object
of event names and functions. This would be nice to look into adding.
Is this much better than just saying eg. Element.create(a, {href:
http://link;, onclick: function(e) { ... } }, link}?
Hmm, is everything exposed as on* attributes now? If so, then yeah,
just do that; no need to mess around with a magic property in the
attributes bag.
This would still be magical as it is setting an IDL attribute rather than a
content attribute.
Hmm. onclick is a content attribute, no? Or do you just mean that
assigning a function directly (rather than a string of code) is
something that can only be done via an IDL attribute?
If so, then good point, but I also expect that this wouldn't be very
confusing.
It would seem very inconsistent if some attributes are set using
elem.setAttribute and others using elem.foo=bar. Would you make the
distinction based on that the attribute name starts with on?
One possible solution would be to be able to specify event handler
attributes in a second object, so something like:
Element.create(a, { href: ... }, { onclick: function(e) { ... } },
link, anotherChild);
On the other hand, it might be ok to say that all attributes whose
name start with on and whose value is a Function object is set using
the IDL property rather than setAttribute.
/ Jonas
[Bug 13071] Once the end of the file is reached, the user agent must dispatch the event one final time, as defined below means an implementation may parse a partial (corrupt) event as a final even
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13071 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch 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 13172] The definition for [MessageEvent] is missing.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13172 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-04 21:54:21 UTC --- Missing how? -- 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 13064] WindowBase64 normatively referenced by not defined
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13064 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|INVALID | --- Comment #3 from Glenn Adams gl...@skynav.com 2011-08-04 21:56:20 UTC --- reopening; sorry for the confusion, i was just looking at the HTML5 spec; the problem is that there is no link from the reference to WindowBase64 in web workers to the definition in HTML5 spec; a link needs to be added to the definition in the HTML5 spec -- 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: CfC: publish new WD of DOM Core; deadline August 10
I support this. On Wed, Aug 3, 2011 at 7:12 AM, Arthur Barstow art.bars...@nokia.com wrote: Anne would like to publish a new WD of DOM Core and this is a Call for Consensus (CfC) to do so: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html Agreeing with this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support for the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps@w3.org by August 10 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. -Art Barstow
[Bug 13065] WindowTimers normatively referenced by not defined
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13065 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NEEDSINFO | --- Comment #2 from Glenn Adams gl...@skynav.com 2011-08-04 21:57:07 UTC --- the problem is that there is no link from the reference to WindowTimers in web workers to the definition in HTML5 spec; a link needs to be added to the definition in the HTML5 spec -- 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 13229] The following text from the Security considerations part of 11 IANA considerations is wrong: An event stream from an origin distinct from the origin of the content consuming the eve
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13229 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WORKSFORME --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-04 22:02:58 UTC --- already 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.
Re: publish new WD of DOM Core; deadline August 10
On 8/4/11 12:21 PM, Anne van Kesteren wrote: On Thu, 04 Aug 2011 21:06:58 +0200, Adrian Bateman adria...@microsoft.com wrote: The name was changed. We weren't terribly keen on the change. It is now causing problems. I've had multiple people contact me confused about this. We should fix the problem. Alright, how about DOM4? I suspect it is the inclusion of the word core that causes the confusion, not the lack of a version number. If you google dom core you get lots of hits for various old Level 2 and Level 3 specs. Given how much this spec removes from level 2 and level 3, it seem strange to give it a version number in the same series... How about WebDOM instead? David This functionality shouldn't be pulled into DOM Core. We believe improvements for mutation events should be kept a separate deliverable for this working group (ADMN). I am not sure what ADMN means. This is in the WG charter. Thanks. (FWIW, several proposals so far have been synchronous.)
[Bug 13678] New: Misleading encoding in FormData objects created on HTML Forms
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13678 Summary: Misleading encoding in FormData objects created on HTML Forms Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 2.0 AssignedTo: ann...@opera.com ReportedBy: wfernandom2...@gmail.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Using xhr_object.send(new FormData(html_form_object)) allows to submit files using xhr instead of using hidden iframes. However, currently, that will send utf-8 encoded data instead of the html_form_object's encoding. This behavior makes hard to web pages to maintain compatibility with older browsers that require hidden iframes and use other encodings than utf-8. PHP, for instance, uses the iso-8859-1 encoding by default. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=669239. -- 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 13681] New: Make FormData.append return the FormData object
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13681 Summary: Make FormData.append return the FormData object Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 2.0 AssignedTo: ann...@opera.com ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org If we change the FormData.append function to return the FormData object on which the function was called, it would allow syntax like myformdata.append(foo, file).append(bar, text).append(baz, blob); as well as xhr.send((new FormData).append(afile, myfile)); -- 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: Element.create(): a proposal for more convenient element creation
On 8/4/11, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 3, 2011 at 8:10 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Aug 3, 2011 at 12:34 AM, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
MooTools is basically identical to Prototype, except that you can
additionally set listeners on the element during creation by using a
magical events property in the attribute bag, which takes an object
of event names and functions. This would be nice to look into adding.
Is this much better than just saying eg. Element.create(a, {href:
http://link;, onclick: function(e) { ... } }, link}?
Hmm, is everything exposed as on* attributes now? If so, then yeah,
just do that; no need to mess around with a magic property in the
attributes bag.
This would still be magical as it is setting an IDL attribute rather than
a
content attribute.
Hmm. onclick is a content attribute, no? Or do you just mean that
assigning a function directly (rather than a string of code) is
something that can only be done via an IDL attribute?
There is an event handler attribute named onclick. There is an event
handler property named onclick. Setting the property does not set the
attribute. Setting the attribute results in the creation of a function
with the value of that attribute as its FunctionBody and an augmented
scope chain. When the attribute is set, the property gets that
browser-generated function function.
The scope of handler attributes is explained in HTML 5, though incompletely:
http://dev.w3.org/html5/spec/Overview.html#event-handler-content-attributes
That's incomplete.
The scope chain of an event handler attribute for a form control would
function as so:
| input type=text onclick=alert([form, type]); value=test
function anonymous() {
with(document) {
with(this.form) {
with(this) {
alert([form, type]);
}
}
}
};
Or alternatively:
document.forms[0].elements[0].setAttribute(onclick, alert(form, type]));
Result:
[object HTMLFormElement],text
Setting the property does not change the attribute. They're two
different things.
If so, then good point, but I also expect that this wouldn't be very
confusing.
I can see why you'd say that, but the fact is that attributes and
properties are different things.
If you take good care not to assign ID and NAME like form or body
(yeah, Google doesn't really heed that rule very well), you might not
see too many problems. And if you never ever use event handler
attributes, you won't get stung by scope augmentation bugs.
I wrote an article on this but Jim's server is perpetually down (as is
my site now). Unsafe Names for Form Controls. Google cache:
http://webcache.googleusercontent.com/search?q=cache:VLOWitVtytgJ:www.jibbering.com/faq/names/event_handler.html+%22Event+Handler+Scope%22+jibberingcd=1hl=enct=clnkgl=usclient=safarisource=www.google.com
See also:
http://code.google.com/p/chromium/issues/detail?id=80911q=bzbarskycolspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS
Though also explained many many years ago by Cornford on c.l.js.
It would seem very inconsistent if some attributes are set using
elem.setAttribute and others using elem.foo=bar.
Yeah, inconsistent. Sounds like jQuery.
Would you make the
distinction based on that the attribute name starts with on?
I'm pretty sure Jonas would not do that.
One possible solution would be to be able to specify event handler
attributes in a second object, so something like:
Element.create(a, { href: ... }, { onclick: function(e) { ... } },
link, anotherChild);
The scope augmentation that goes along with the event handler
attribute is undesirable here.
--
Garrett
