Re: [whatwg] Please review use cases relating to embedding micro-data in text/html
The contacts section uses event where it meant contact On 4/23/09, Ian Hickson i...@hixie.ch wrote: [bcc'ed previous participants in this discussion] Earlier this year I asked for use cases that HTML5 did not yet cover, with an emphasis on use cases relating to semantic microdata. I list below the use cases and requirements that I derived from the response to that request, and from related discussions. I would appreciate it if people could review this list for errors or important omissions, before I go through the list to work out whether these use cases already have solutions, or whether we should have solutions for these use cases in HTML, or whether we should address these use cases with other technologies, or whatnot. I encourage people to focus on the use cases themselves, rather than on potential solutions; various solutions to all these use cases have already been argued in great detail and I have already read all those e-mails, blog comments, wiki faqs, etc, carefully. My primary concern right now is in making sure that these are indeed the use cases people care about, so that whatever we add to the spec can be carefully evaluated to make sure it is in fact solving the problems that we want solving. == Exposing known data types in a reusable way USE CASE: Exposing calendar events so that users can add those events to their calendaring systems. SCENARIOS: * A user visits the Avenue Q site and wants to make a note of when tickets go on sale for the tour's stop in his home town. The site says October 3rd, so the user clicks this and selects add to calendar, which causes an entry to be added to his calendar. * A student is making a timeline of important events in Apple's history. As he reads Wikipedia entries on the topic, he clicks on dates and selects add to timeline, which causes an entry to be added to his timeline. * TV guide listings - browsers should be able to expose to the user's tools (e.g. calendar, DVR, TV tuner) the times that a TV show is on. * Paul sometimes gives talks on various topics, and announces them on his blog. He would like to mark up these announcements with proper scheduling information, so that his readers' software can automatically obtain the scheduling information and add it to their calendar. Importantly, some of the rendered data might be more informal than the machine-readable data required to produce a calendar event. Also of importance: Paul may want to annotate his event with a combination of existing vocabularies and a new vocabulary of his own design. (why?) * David can use the data in a web page to generate a custom browser UI for adding an event to our calendaring software without using brittle screen-scraping. REQUIREMENTS: * Should be discoverable. * Should be compatible with existing calendar systems. * Should be unlikely to get out of sync with prose on the page. * Shouldn't require the consumer to write XSLT or server-side code to read the calendar information. * Machine-readable event data shouldn't be on a separate page than human-readable dates. * The information should be convertible into a dedicated form (RDF, JSON, XML, iCalendar) in a consistent manner, so that tools that use this information separate from the pages on which it is found have a standard way of conveying the information. * Should be possible for different parts of an event to be given in different parts of the page. For example, a page with calendar events in columns (with each row giving the time, date, place, etc) should still have unambiguous calendar events parseable from it. --- USE CASE: Exposing contact details so that users can add people to their address books or social networking sites. SCENARIOS: * Instead of giving a colleague a business card, someone gives their colleague a URL, and that colleague's user agent extracts basic profile information such as the person's name along with references to other people that person knows and adds the information into an address book. * A scholar and teacher wants other scholars (and potentially students) to be able to easily extract information about who he is to add it to their contact databases. * Fred copies the names of one of his Facebook friends and pastes it into his OS address book; the contact information is imported automatically. * Fred copies the names of one of his Facebook friends and pastes it into his Webmail's address book feature; the
[whatwg] Typo
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-pattern-attribute
says:
For example, the following snippet:
label Part number:
input pattern=[0-9][A-Z]{3} name=part
title=A part number is a digit followed by three
uppercase letters./
/label
...could cause the UA to display an alert such as:
part number is a digit followed by three uppercase letters.
You cannot complete this form until the field is correct.
which is missing the A in the last-but-one line.
--
Philip Taylor
exc...@gmail.com
[whatwg] Exposing EventTarget to JavaScript
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript. This would mean that JavaScript can
instantiate and extend event targets and dispatch events to these
objects would work just like it does for DOM elements today.
For example:
var et = new EventTarget;
...
et.addEventListener('foo', fun, false);
...
et.dispatchEvent(eventObject);
would call the handler fun.
The example above actually works today if you replace new
EventTarget with document.createElement('div').
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
Then addEventListener and dispatchEvent should work as expected on
MyClass objects.
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Re: [whatwg] Exposing EventTarget to JavaScript
As a reminder, the syntax {new Option()} (Netscape DOM) is deprecated to the
syntax {document.createElement(OPTION)} (W3C DOM). The requested syntax
{new Event()} would be inconsistent with that design decision. OTOH, the
syntax {new XMLHTTPRequest()} has already been adopted, perhaps because
{document.createXMLHTTPRequest()} would be too specific?
A bit confused,
Chris
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 10:00 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript. This would mean that JavaScript can
instantiate and extend event targets and dispatch events to these
objects would work just like it does for DOM elements today.
For example:
var et = new EventTarget;
...
et.addEventListener('foo', fun, false);
...
et.dispatchEvent(eventObject);
would call the handler fun.
As we discussed off-list, I absolutely support this, but with shorter
names. The DOM names for these interfaces are dumb. Idiomatic JS
prefers short over long, so the above example should be able to be
written as:
var et = new EventTarget();
et.listen(foo, fun); // default phase to false
et.dispatch(evtObj);
Similarly, the DOM interface should be modified to allow these aliases
for the existing names.
Regards
The example above actually works today if you replace new
EventTarget with document.createElement('div').
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
Then addEventListener and dispatchEvent should work as expected on
MyClass objects.
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Re: [whatwg] Exposing EventTarget to JavaScript
2009/4/24 Erik Arvidsson erik.arvids...@gmail.com:
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript. This would mean that JavaScript can
instantiate and extend event targets and dispatch events to these
objects would work just like it does for DOM elements today.
For example:
var et = new EventTarget;
...
et.addEventListener('foo', fun, false);
...
et.dispatchEvent(eventObject);
would call the handler fun.
The example above actually works today if you replace new
EventTarget with document.createElement('div').
This should not work. This is because the DOM event system (used for
elements) is different from the scripting event system (used for
windows, xmlhttprequest, workers, etc.). The former requires a
document through which the event flows (capture - target - bubble
phases). No document = no event.
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
Then addEventListener and dispatchEvent should work as expected on
MyClass objects.
This is a matter of host language, not of DOM. In Java, you just do
public class MyClass implements EventTarget {
}
and the same in ES6 (ES-Harmony)
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
Why do you need an EventTarget?
In most cases you can emulate the same behavior with a Javascript
library, without more work on the UA.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Giovanni
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 10:30 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/4/24 Erik Arvidsson erik.arvids...@gmail.com:
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript. This would mean that JavaScript can
instantiate and extend event targets and dispatch events to these
objects would work just like it does for DOM elements today.
For example:
var et = new EventTarget;
...
et.addEventListener('foo', fun, false);
...
et.dispatchEvent(eventObject);
would call the handler fun.
The example above actually works today if you replace new
EventTarget with document.createElement('div').
This should not work. This is because the DOM event system (used for
elements) is different from the scripting event system (used for
windows, xmlhttprequest, workers, etc.). The former requires a
document through which the event flows (capture - target - bubble
phases). No document = no event.
This is a bug, not a design constraint.
JavaScript should be extended to support event dispatch (as Erik
outlines) and it should be done in such a way as to cast the DOM event
system as an implementation of that dispatch mechanism. Suggesting
that JS and DOM shouldn't be more tightly integrated because they
havent' been more tightly integrated in the past isn't a legit
argument.
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
Then addEventListener and dispatchEvent should work as expected on
MyClass objects.
This is a matter of host language, not of DOM. In Java, you just do
public class MyClass implements EventTarget {
}
and the same in ES6 (ES-Harmony)
It's safe to fully ignore Java.
Regards
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
Why do you need an EventTarget?
In most cases you can emulate the same behavior with a Javascript
library, without more work on the UA.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Giovanni
Re: [whatwg] Exposing EventTarget to JavaScript
2009/4/24 Alex Russell slightly...@google.com:
On Fri, Apr 24, 2009 at 10:30 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/4/24 Erik Arvidsson erik.arvids...@gmail.com:
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript. This would mean that JavaScript can
instantiate and extend event targets and dispatch events to these
objects would work just like it does for DOM elements today.
For example:
var et = new EventTarget;
...
et.addEventListener('foo', fun, false);
...
et.dispatchEvent(eventObject);
would call the handler fun.
The example above actually works today if you replace new
EventTarget with document.createElement('div').
This should not work. This is because the DOM event system (used for
elements) is different from the scripting event system (used for
windows, xmlhttprequest, workers, etc.). The former requires a
document through which the event flows (capture - target - bubble
phases). No document = no event.
This is a bug, not a design constraint.
JavaScript should be extended to support event dispatch (as Erik
outlines) and it should be done in such a way as to cast the DOM event
system as an implementation of that dispatch mechanism. Suggesting
that JS and DOM shouldn't be more tightly integrated because they
havent' been more tightly integrated in the past isn't a legit
argument.
DOM = Document Object Model = a set of APIs for representing and
manipulating documents
If you need pure scripting interfaces, you can write your own library,
without reusing EventTarget, that has been used outside its scope with
debatable results. (what does event.stopPropagation() do for
XMLHttpRequest events?)
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
Then addEventListener and dispatchEvent should work as expected on
MyClass objects.
This is a matter of host language, not of DOM. In Java, you just do
public class MyClass implements EventTarget {
}
and the same in ES6 (ES-Harmony)
It's safe to fully ignore Java.
Why?
Moreover, is it safe to fully ignore Python or Perl? This is not the
opinion of the SVGWG, in SVGTiny12.
And Java bindings are provided by WebIDL and all DOM specifications.
Regards
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
Why do you need an EventTarget?
In most cases you can emulate the same behavior with a Javascript
library, without more work on the UA.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Giovanni
Re: [whatwg] Exposing EventTarget to JavaScript
I like the basic idea, but I think drawing too much inspiration from DOM events is a bad idea. What does it mean to capture a pure JS event? Further, the DOM event model has problems. It would be nice if events were first-class, not strings. It would be more idiomatic JS, I would argue, to do someObject.onClick.add(handler). - a
Re: [whatwg] Exposing EventTarget to JavaScript
Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript.
Why do you want the eventTarget interface as opposed to a sane callback
function registration setup?
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
So this already works, no?
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
What, precisely, is the use case for this in general? In the DOM,
propagating events to parents makes sense (esp. because parents are
unique). What would be the use case in a general object graph?
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
Possibly for good reasons? In some implementations the document is in
fact baked into the event for various security purposes.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
It's not really clear to me what the benefits of using the (rather
suboptimal, from the JS point of view) DOM EventTarget API for generic
JS callback dispatch are.
-Boris
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, 24 Apr 2009, Erik Arvidsson wrote:
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario it
would be good if an implementation of the EventTarget interface could be
exposed to JavaScript. This would mean that JavaScript can instantiate
and extend event targets and dispatch events to these objects would work
just like it does for DOM elements today.
This seems like a reasonable idea, but would be more appropriately made
available in the DOM3 Events specification, being developed in the W3C
public-webapps working group.
On Fri, 24 Apr 2009, Kristof Zelechovski wrote:
As a reminder, the syntax {new Option()} (Netscape DOM) is deprecated to the
syntax {document.createElement(OPTION)} (W3C DOM).
This isn't correct; new Option() is perfectly valid and not deprecated.
On Fri, 24 Apr 2009, Alex Russell wrote:
As we discussed off-list, I absolutely support this, but with shorter
names. The DOM names for these interfaces are dumb. Idiomatic JS prefers
short over long, so the above example should be able to be written as:
var et = new EventTarget();
et.listen(foo, fun); // default phase to false
et.dispatch(evtObj);
Similarly, the DOM interface should be modified to allow these aliases
for the existing names.
I encourage you to bring this up on the public-webapps list.
On Fri, 24 Apr 2009, Giovanni Campagna wrote:
This should not work. This is because the DOM event system (used for
elements) is different from the scripting event system (used for
windows, xmlhttprequest, workers, etc.). The former requires a document
through which the event flows (capture - target - bubble phases). No
document = no event.
This does not appear to be accurate either, though DOM3 Events maybe needs
to be made clearer on the topic.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 11:46, Boris Zbarsky bzbar...@mit.edu wrote: It's not really clear to me what the benefits of using the (rather suboptimal, from the JS point of view) DOM EventTarget API for generic JS callback dispatch are. One of the benefits is a consistent API. I do agree that the EventTarget API is suboptimal and so are most of the DOM APIs but it is what we got and we need tie the lose ends and make ends meet. -- erik
Re: [whatwg] Exposing EventTarget to JavaScript
On Apr 24, 2009, at 11:29 AM, Aaron Boodman wrote: I like the basic idea, but I think drawing too much inspiration from DOM events is a bad idea. What does it mean to capture a pure JS event? There's really two aspects to the DOM event model. One is the basic addEventListner / dispatchEvent mechanism, which allows objects to have event listeners attached. The other is the bubble/capture event flow in the DOM tree. It can make sense for an object to be an EventTarget without participating in bubble/capture, because it is not part of the DOM document tree. An example of this is XMLHttpRequest. Further, the DOM event model has problems. It would be nice if events were first-class, not strings. It would be more idiomatic JS, I would argue, to do someObject.onClick.add(handler). It's a bit late in the game to change the DOM itself to work that way. And having some other event mechanism that works like this, while DOM events continue to work as they do, would be confusing I think. One advantage to string event names is that users of the DOM can invent custom event names at will. In addition, it is possible to register for events that are not supported without having to do feature testing. There are certainly downsides to the design but it is not without precedent. Regards, Maciej
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 10:58 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/4/24 Alex Russell slightly...@google.com:
On Fri, Apr 24, 2009 at 10:30 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/4/24 Erik Arvidsson erik.arvids...@gmail.com:
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript. This would mean that JavaScript can
instantiate and extend event targets and dispatch events to these
objects would work just like it does for DOM elements today.
For example:
var et = new EventTarget;
...
et.addEventListener('foo', fun, false);
...
et.dispatchEvent(eventObject);
would call the handler fun.
The example above actually works today if you replace new
EventTarget with document.createElement('div').
This should not work. This is because the DOM event system (used for
elements) is different from the scripting event system (used for
windows, xmlhttprequest, workers, etc.). The former requires a
document through which the event flows (capture - target - bubble
phases). No document = no event.
This is a bug, not a design constraint.
JavaScript should be extended to support event dispatch (as Erik
outlines) and it should be done in such a way as to cast the DOM event
system as an implementation of that dispatch mechanism. Suggesting
that JS and DOM shouldn't be more tightly integrated because they
havent' been more tightly integrated in the past isn't a legit
argument.
DOM = Document Object Model = a set of APIs for representing and
manipulating documents
That strong distinction between a theoretical OM for some abstract DOM
vs. the actual real-world use cases of JavaScript is the primary
consumer has allowed DOM APIs to be mangled beyond usability for far
too long.
If you need pure scripting interfaces, you can write your own library,
without reusing EventTarget, that has been used outside its scope with
debatable results. (what does event.stopPropagation() do for
XMLHttpRequest events?)
If those events are dispatching down a chain of listeners on some
event, it stops that chain dispatch. The idea that somehow calling a
function in JS and firing an event in the DOM are totally different
thigns that deserve totally different listener APIs is an artifact of
a time when we had much less experience about how these things are
used in the real world. Dispatch is dispatch. Function calls are
events. Treating them differently because they happened to originate
from one part of the platform and not the other is crazy.
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
Then addEventListener and dispatchEvent should work as expected on
MyClass objects.
This is a matter of host language, not of DOM. In Java, you just do
public class MyClass implements EventTarget {
}
and the same in ES6 (ES-Harmony)
It's safe to fully ignore Java.
Why?
Moreover, is it safe to fully ignore Python or Perl?
For the purpose of designing DOM APIs for the real world, absolutely.
They are not the design center. Python has already left the building
(see lxml and the ElementTree API for details on why sane people
abandoned W3C DOM wholesale).
This is not the
opinion of the SVGWG, in SVGTiny12.
And Java bindings are provided by WebIDL and all DOM specifications.
This is a historical artifact which doesn't need to blight the design
of DOM in it's primary use-case. If anything, we should be expressing
Java bindings as a special case, not as the common-case.
Regards
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:09 PM, Alex Russell slightly...@google.com wrote: Even in the XHR case, adding more than one listener is currently a pain. Part of the goal here would be to make event dispatch across lists of listeners as natural in JS as it is in DOM. Nit: I believe this has been fixed in XHR (it now supports addEventListener, if that's what you were referring to). - a
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:16 PM, Aaron Boodman a...@google.com wrote: On Fri, Apr 24, 2009 at 2:09 PM, Alex Russell slightly...@google.com wrote: Even in the XHR case, adding more than one listener is currently a pain. Part of the goal here would be to make event dispatch across lists of listeners as natural in JS as it is in DOM. Nit: I believe this has been fixed in XHR (it now supports addEventListener, if that's what you were referring to). Ahh, yeah, thanks for the clarification. I wasn't aware of that change. Regards
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript.
Why do you want the eventTarget interface as opposed to a sane callback
function registration setup?
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
So this already works, no?
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
What, precisely, is the use case for this in general? In the DOM,
propagating events to parents makes sense (esp. because parents are unique).
What would be the use case in a general object graph?
Most of the JS object graphs that you'll see in the wild either
represent data hierarchies (wherein updates might trigger a UI change)
or wrapped sets of DOM nodes as a way to make up for the fact that you
can't freaking subclass Element from JS. In the latter case, it's
natural to need it to keep up the facade. In the former, it's a
performance convenience.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
Possibly for good reasons? In some implementations the document is in fact
baked into the event for various security purposes.
I think individual call sites overriding their dispatch is sane, but
hopefully uncommon.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
It's not really clear to me what the benefits of using the (rather
suboptimal, from the JS point of view) DOM EventTarget API for generic JS
callback dispatch are.
I don't think the proposal would be to use it as-is. Clearly it needs
beefing up to serve as a good aspect system for JS, but it's the right
starting place. Treating function calls as message sends or events to
be dispatched gives you a nice way of building after-advice into JS
objects, and with a little bit of massaging, could also give you
before and around advice. There's some friction between the Event
object and the arguments object, but not so much that it would be
insurrmountable to recast DOM event dispatch as sub-case of regular JS
function calling. JS libraries provide ways to try to unify these
interfaces (at huge expense), so moving it into the language makes the
most sense.
Regards
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell wrote: Something missing from this (and from Erik's original mail) is the ability to enumerate listeners. This has been brought up before. 1) There are some serious security concerns here. 2) It's not clear what the enumeration should actually return. EventListener objects? JS Function objects? Something else? Last I checked people couldn't even agree on this (both have pros and cons). And other than a debugger, I have yet to see a usecase for this. Do you have a specific one in mind? Even in the XHR case, adding more than one listener is currently a pain. How so, exactly? Part of the goal here would be to make event dispatch across lists of listeners as natural in JS as it is in DOM. The only natural thing in DOM is the event flow from target to root. That concept doesn't make much sense in the absence of a linear data structure (the list of ancestors, here). Is your real use case just to call a bunch of listeners in a defined order? -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
Erik Arvidsson wrote: On Fri, Apr 24, 2009 at 11:46, Boris Zbarsky bzbar...@mit.edu wrote: It's not really clear to me what the benefits of using the (rather suboptimal, from the JS point of view) DOM EventTarget API for generic JS callback dispatch are. One of the benefits is a consistent API. OK, true. But if the API is a bad fit, this might not be enough to want to use it. I do agree that the EventTarget API is suboptimal and so are most of the DOM APIs but it is what we got and we need tie the lose ends and make ends meet. Why is the right approach to this to add addEventListener and its baggage to everything instead of adding a sane API to everything? -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell wrote: Most of the JS object graphs that you'll see in the wild either represent data hierarchies (wherein updates might trigger a UI change) or wrapped sets of DOM nodes as a way to make up for the fact that you can't freaking subclass Element from JS. In the latter case, it's natural to need it to keep up the facade. In the former, it's a performance convenience. Agreed for the latter case (though at that point whatever is doing the wrapping can also handle forwarding the listener sets to the real DOM nodes). I'm not sure what the performance issue with the former case is. Can you elaborate? Possibly for good reasons? In some implementations the document is in fact baked into the event for various security purposes. I think individual call sites overriding their dispatch is sane, but hopefully uncommon. I'm not sure how that relates to what I said... It's not really clear to me what the benefits of using the (rather suboptimal, from the JS point of view) DOM EventTarget API for generic JS callback dispatch are. I don't think the proposal would be to use it as-is. OK. -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:42 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Alex Russell wrote:
Something missing from this (and from Erik's original mail) is the
ability to enumerate listeners.
This has been brought up before.
1) There are some serious security concerns here.
2) It's not clear what the enumeration should actually return.
EventListener objects? JS Function objects? Something else?
Last I checked people couldn't even agree on this (both have
pros and cons).
Array of function objects. That would let you do useful things with it
like unshifting onto the front or slicing to remove some set of
listeners.
And other than a debugger, I have yet to see a usecase for this. Do you
have a specific one in mind?
Even in the XHR case, adding more than one listener is currently a
pain.
How so, exactly?
Aaron's note about addEventListener solves it, but in the common case
where a JS system wants to have multiple callbacks, they either wind
up carrying around their own event listener system (e.g.,
dojo.connect()) or a Deferred pattern to wrap functions which only
support direct dispatch from a single call site.
Part of the goal here would be to make event dispatch across
lists of listeners as natural in JS as it is in DOM.
The only natural thing in DOM is the event flow from target to root. That
concept doesn't make much sense in the absence of a linear data structure
(the list of ancestors, here).
I think what I'd like to see is a way for this interface to allow
arbitrary JS object to specify what their ancestor is. That way
hierarchical JS objects can dispatch up.
Is your real use case just to call a bunch of listeners in a defined order?
Consider some API that defines an event:
thinger = {
happened: function(){
// processes some state here
}
};
Today, JS toolkits provide various ways of listening for something
invoking this. In Dojo, I'd say:
dojo.connect(thinger, happened, function(){ ... });
Other systems have similar conveniences, but in general they all exist
to keep developers from needing to do:
(function() {
var old_happened = thinger.happened;
thinger.happened = function() {
// ...
return old_happened.apply(this, arguments);
};
})();
This method of building callbacks on existing APIs is not, to use
your word, sane.
Regards
Re: [whatwg] Exposing EventTarget to JavaScript
Forwarded to public-weba...@w3.org
On Fri, Apr 24, 2009 at 14:52, Alex Russell slightly...@google.com wrote:
On Fri, Apr 24, 2009 at 2:42 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Alex Russell wrote:
Something missing from this (and from Erik's original mail) is the
ability to enumerate listeners.
This has been brought up before.
1) There are some serious security concerns here.
2) It's not clear what the enumeration should actually return.
EventListener objects? JS Function objects? Something else?
Last I checked people couldn't even agree on this (both have
pros and cons).
Array of function objects. That would let you do useful things with it
like unshifting onto the front or slicing to remove some set of
listeners.
And other than a debugger, I have yet to see a usecase for this. Do you
have a specific one in mind?
Even in the XHR case, adding more than one listener is currently a
pain.
How so, exactly?
Aaron's note about addEventListener solves it, but in the common case
where a JS system wants to have multiple callbacks, they either wind
up carrying around their own event listener system (e.g.,
dojo.connect()) or a Deferred pattern to wrap functions which only
support direct dispatch from a single call site.
Part of the goal here would be to make event dispatch across
lists of listeners as natural in JS as it is in DOM.
The only natural thing in DOM is the event flow from target to root. That
concept doesn't make much sense in the absence of a linear data structure
(the list of ancestors, here).
I think what I'd like to see is a way for this interface to allow
arbitrary JS object to specify what their ancestor is. That way
hierarchical JS objects can dispatch up.
Is your real use case just to call a bunch of listeners in a defined order?
Consider some API that defines an event:
thinger = {
happened: function(){
// processes some state here
}
};
Today, JS toolkits provide various ways of listening for something
invoking this. In Dojo, I'd say:
dojo.connect(thinger, happened, function(){ ... });
Other systems have similar conveniences, but in general they all exist
to keep developers from needing to do:
(function() {
var old_happened = thinger.happened;
thinger.happened = function() {
// ...
return old_happened.apply(this, arguments);
};
})();
This method of building callbacks on existing APIs is not, to use
your word, sane.
Regards
--
erik
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:43 PM, Boris Zbarsky bzbar...@mit.edu wrote: Erik Arvidsson wrote: I do agree that the EventTarget API is suboptimal and so are most of the DOM APIs but it is what we got and we need tie the lose ends and make ends meet. Why is the right approach to this to add addEventListener and its baggage to everything instead of adding a sane API to everything? What would be a better approach? You gain a lot from consistency and doing something that developers are already intimately familiar with. Personally, addEventListener seems good enough to me and it's already there. I'm not totally opposed to coming up with something better than addEventListener, but it's hard to argue one way or another without a counter-proposal. Ojan
Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
On Thu, 4 Dec 2008, Markus Ernst wrote: Ian Hickson schrieb: Why is that a problem? Is converting one to the other a common occurance? I'm not really convinced it's that much work. Assuming that the radio buttons and/or checkboxes are written in a consistent manner, which they usually are, a simple regexp search-and-replace on the source is usually enough to convert them. [...] Well, as far as I get the various discussions in the WHATWG list, many of them are about one of the following: - Making things easier - Introducing features into HTML that are commonly solved by client-side (e.g. the extensions to the input element) or server-side scripting (e.g. solving the login/logout problem in HTML) Thus the question, is converting select to radio/checkbox groups common? I don't think it is. Are there oft-used JS libraries that do this? - Improving language consistency (e.g. the discussions about elements such as abbr, dfn, small, b etc.) These carefully avoid changing the syntax, though. :-) So let me, as a conclusion, repeat two points out of the suggestions I made earlier, which I think would be quite helpful, and which do not cause backwards compatibility problems, as they degrade to the default behaviour of the elements in older UAs. After that I will not insist in this topic anymore... :-) 1. Introduce a type attribute to the select element, which can change the output into a list of radio buttons (in normal mode) resp. checkboxes (in multiple mode). Why can't you just use input type=radio/input type=checkbox? (Note: On the long term, this is really just a stylistic issue, and XBL2 with CSS will be able to achieve this anyway.) 2. Introduce a multiline attribute to input type=text, possibly supplemented by a rows attribute. Why can't you just use textarea? We don't want to add features that don't really add new abilities, unless they really help something that people do a lot. Do people do this a lot? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
On Thu, 4 Dec 2008, Markus Ernst wrote: This CSS3 module is indeed an interesting approach, anyway I don't see in this spec how possible conflicts between the form structure and it's presentation can be avoided or handled. Start with: select name=gender option value=fFemale/option option value=mMale/option /select Now you can easily change the presentation into a radio button group, which is fine: select name=gender style=appearance:radio-group But then an author does this: select name=gender style=appearance:checkbox-group Now there is a conflict, as the form structure allows only a single selection, while the presentation allows a multiple one. It's not clear that the underlying element can actually get multiple selections here (I would argue it cannot); but this is an issue for CSS3 UI, not for HTML5. This does not only affect the rendering of the element and the reaction to user actions, but is even likely to break the handling of the submitted value, as server-side handlers often expect either a single value or an array of values and are not configured to cope with both of them. A conforming browser wouldn't send values that violate the rules HTML5 describes, which in this case prevents the scenario you describe, regardless of the presentation layer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Fwd: Entity parsing
On 23 May 2008, at 03:50, Ian Hickson wrote: On Thu, 28 Jun 2007, Øistein E. Andersen wrote: 1) Is it useful to handle unterminated entities followed by an alphanumerical character like IE does? [...] 2) HTML 4.01 allows the semicolon to be omitted in certain cases. [...] Firefox and Safari both support this, and it would seem meaningless to change the way conforming documents are parsed [...] 3) Will new entities ever be needed? If yes, can new entities adopt existing conformance criteria and parsing rules? [...] New entities have since been added, and the rules for parsing entities (sorry, named character references) have been changed a bit. However, I am reluctant to change this from what we have now, since what we have now works well. How strongly do you feel about this? I think I may have expressed my concern in rather too abstract terms previously. The named character references currently present in HTML5 can be subdivided (roughly) into the following subsets: IE4 HTML4 HTML5 Approximately 100 named character references are included in the IE4 set, 200 in the HTML4 set, and 2,000 in the HTML5 set. When a named character reference is followed by a semicolon, it clearly has to be expanded, but how to handle non-semicolon-terminated character references is less obvious. Let IE4 (resp. HTML4, HTML5) be a non-semicolon-terminated named character reference from the IE4 (resp. HTML4, HTML5) set, and let . (full stop) represent any character other than semicolon, and ^ (circumflex) any character which is (roughly) not an ASCII letter or digit (i.e., [^a-zA-Z0-9]). Not completely unreasonable sets of character references to expand (outside of attribute values) include: 1) IE4^ 2) IE4. 3) HTML4^ 4) IE4. HTML4^ 5) HTML4. 6) IE4. HTML5^ 7) HTML4. HTML5^ 8) HTML5. (The set of character references to be expanded in attribute values could be obtained by replacing . by ^ above.) Currently, Opera follows 1), IE 2), and Safari and Firefox 3). My main concern is that HTML4^ is actually legitimate in HTML4 and works in both Safari and Firefox today, and that HTML5 should not change the rendering of valid HTML4 pages unless there is a good reason to do so. 4) does not break any valid HTML4 pages and does also not cause any character references to be expanded which are not already expanded in either IE or both Safari and Firefox, so this should be possible to implement. [Options 5), 6) and 8) can, to a greater or lesser extent, be specified more easily, but might be too controversial. There are pages relying on, e.g., `10ndash20' to work, though, so handling character references in a more liberal way would actually have some benefits; only invalid mark-up would be affected in any case; and the negative effects are to a certain extent compounded by the more conservative treatment in attribute values. That being said, I do of course realise that it will be seen as safer not to expand too many character references as long as the actual impact remains difficult to quantify.] -- Øistein E. Andersen
Re: [whatwg] More template feedback
On Thu, 4 Dec 2008, Mike Schinkel wrote:
Ian Hickson wrote:
This only works if the form data is in the format you need it in. Say
that you have a calendar-like feature -- if the server uses
.../year/month/day/...
...as the URL form, you can't just convert an input type=date value
into that URL, so you still have to have script or server-side
redirection or some logic in the templating language -- and short of
making it turing complete, the templating language won't ever be a
complete solution.
Nothing in HTML has ever been able to handle all potential use cases so
bringing this up is a red herring. 85% is far better than 0%.
Sure, but in this case it's not clear to me we're anywhere near 85%. Most
blogs seem to use the above syntax, for instance.
What are the places that allow you to write forms but don't allow you
to write scripts on either the client or the server?
WordPress.com, Typepad.com, Posterous.com, Vox.com, MySpace, Facebook, and a
myriad of forums and online content sites where people publish content but
don't control the servers.
I don't see evidence that there are places that let you do forms and
service interaction but don't let you have scripts or server-side
scripts.
That's because you've not been paying attention to are large segment on
the HTML authoring spectrum.
For example: http://support.wordpress.com/code/3/
But this also disallows form, so form templates wouldn't be any help
here either.
And are you really expecting search engines to fill in forms that
would use templates?
YES!! Why would they not, if they could?
How would they know what to say?
Given the following, how would they not know what to say?
form template=http://example.com/{color}/;
select name=color
option value=redRed/option
option value=greenGreen/option
option value=blueBlue/option
/select
input type=submit
/form
Even I don't know what to say here, how would a search engine? Is the
correct answer red, green, or blue?
What about for:
form template=/{x}/
input name=x
input type=submit
/form
What should the search engine write in?
You don't have to do redirects, just support two URIs, one for the
permalinks (nice URIs) one for form submissions (parsing query data).
Without redirects you get fragmentation of PageRank and the duplicate
content penalty.
Use rel=canonical.
What if the user types something that isn't supported by
weather.com, like the string x?
HTTP handles that elegantly; 404.
With all due respect, that is hardly elegant.
That's a Red Herring anyway. The important use-cases are using
Select/Option and using open-ended URI (such as for search.)
For search, surely a query parameter is the right solution.
If the list of URIs is finite, then there's no need for a form. Just have
a list of links and style it as you wish (e.g. as a dropdown).
Also, why can't you just do:
form method=get action=http://www.weather.com/search/enhanced;
input type=text name=where/
input type=submit value=Check Weather!
/form
So obvious it hurts: Because I don't current control Weather's server
and they have no http://www.weather.com/search/enhanced URL.
Yes they do. Did you try it? It works just like yours would, except
with better error-handling.
One positive example does not support a generality.
I was just taking the example you gave, and showing that you didn't need
templates to achieve it. It wasn't supposed to support a generality.
I don't really follow what you're saying here. I see no practical
difference between URI templates and normal forms in terms of Google
crawling the results.
Normal forms? Google is not going to try to parse out javascript
code that is custom to a website nor user added form attributes.
No, but it can use unscripted forms today the same as it could use
templated forms.
You are arguing that google will try to grok code in Javascript where
there isn't even any standard? Srsly?
No, I'm arguing that it can use _unscripted_ forms today the same as it
could use templated forms.
Also, adding a template attribute to a form element w/o it being in
spec causes it to fail validation; I thought validation was a holy
grail but you are instead suggesting we write HTML that doesn't
validate? Why only argue for validation when it is convenient?
Validation is a tool, not a holy grail.
It may be a tool but it is a tool far too many people require because of
the standardistas who have convinced them it is require. Your proposal
to just add a custom attribute and try to get people to support it is
a non-starter.
The custom attributes will validate. data-template= is valid in HTML5.
http://www.whatwg.org/specs/web-apps/current-work/#attr-data-*
I don't think anyone is denying that it is useful in certain cases.
The question is whether it will be used
Re: [whatwg] More template feedback
On Fri, 5 Dec 2008, Erik Wilde wrote: i think by looking at the decisions what to focus on and what to add to html5, it is fair to say that the current html5 spec mostly focuses on making the web a better place for browser-based applications. which is an important and worthwhile thing to do, but it really has a specific subset of the web in mind, and specific business models, if i dare say so. when thinking of the interests involved, it is apparent that there are more influential entities who are interested in a better web for browser-based applications, whereas there are fewer major voices arguing for the web becoming a better large-scale information system, because this interest is not so much coupled with direct business interests of any major player. That is indeed the focus; in fact what is now the HTML5 spec was originally called Web Applications 1.0. personally, i think it is unfortunate that this almost inevitably undervalues the benefits of turning the web into a better information system (and not just a better ajax platform), and i am wondering how the html5 process could be tweaked to be a bit better balanced between these two issues. HTML4 was focused on a better information system, at the cost of Web apps. HTML5 is just redressing the balance. I imagine going forward that both of these, along with other use cases, will be handled equally. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When closing the browser
On Sat, 13 Dec 2008, Philipp Serafin wrote: Ian Hickson schrieb: On Fri, 12 Dec 2008, Bil Corry wrote: Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if there was a way to distinguish between the user taking an action which leaves the site vs. taking an action that returns to the site. For privacy, it shouldn't reveal which specific action triggered the event, but knowing if the user is leaving the site means webapps can finally auto-logout the user, which in turn greatly improves security. If the goal is auto-logout, then what you describe wouldn't help, as it would have false-positives (leaving the site when another tab still has the site open) You can solve this easily, just use the same algorithm that SessionStorange uses to determine if the session is closed. In other words, only set this value to true if the user closes the tab/navigates to another domain *and* if there are no other open tabs for this domain. SessionStorage doesn't ever close the session explicitly (though it commonly gets into situations where it can never be reached again, at which point the browser can reap it). However, even if it did, that doesn't work -- there could well be other sessions (other windows entirely) that are logged into the same site. and false-negatives (a crash wouldn't log out the user). I think a responsible server implementation would use this *in addition* to session timeouts, not instead of them. I think if we have as a use case making something that provides a better logout solution, it should fix the actual use case significantly better than existing solutions. Why do session cookies not address this already? I think there are still scenarios where it would be valuable for the server to know *exactly when* the user logged out. One example would be those XY is online badges you see in many internet forums today. Today, those have a margin of error of about 15 to 20 minutes at best. In my own experience, closing the page is not a good indicator of when I've logged out. I often have tabs open that I'm not planning on returning to, and I often close tabs only to reopen them shortly after. I see the same behaviour with others. So it's not clear to me that this would really improve matters. With session cookies, if the client doesn't send more requests, the server after all has to guess if you logged out or if you're just taking your time. So you have to wait for a pretty long timeout period in any case. Even if a 15 minute timeout is not so much of a problem from a user perspective, it's still a lot of memory a (potentially buisy) has to keep around longer than really necessary. It's not clear to me why keeping a user logged in should take significant memory, but maybe I don't understand the use case well enough. Could you elaborate? For most sites, a user would just be a row in a database, surely. You can't simply force-logout the user inside onunload either, because of the false positives above. Depending on the situation, maybe a better solution would be for a shared worker to have a WebSocket connection to the server, and for the server to take the closing of the WebSocket connection as a logout. This addresses all the concerns like multiple tabs, timeouts, crashes, etc. On Sat, 13 Dec 2008, Calogero Alex Baldacchino wrote: If the goal is auto-logout *as soon as the user leaves the site*, whenever the downside of a possible new login request during the same session is not a usability concern, a (session) cookie lifetime must be shortened, for instance by adding an expiration timing (e.g., for a session cookie, something like 'sessionID=asdf1234fdas.exp=current gmt date + 3 seconds;'), this way if the user reloads the page or navigates a tab history the server will likely recieve such modified cookie before its 'expiration' and abort an atuo-logout process (a cached webapp may check cookies as well), otherwise, whenever recieving an 'expired' cookie, the logout would trigger immediately; if the client-side script knew the user is leaving the site, any cookie might be removed. This seems like the better short-term solution, yes. But such wouldn't solve the server-side logout concern: to invalidate any login data, in the above scenario an expired cookie must be recieved, thus possibly giving a cookie thief a longer time to work. Of course, there are solutions to address that. If there is a security concern, please use real encryption! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell wrote:
2) It's not clear what the enumeration should actually return.
EventListener objects? JS Function objects? Something else?
Last I checked people couldn't even agree on this (both have
pros and cons).
Array of function objects.
What about event listeners that are not backed by a JS function? Say
actual objects in JS with a handleEvent function, or listeners
implemented in other languages?
And other than a debugger, I have yet to see a usecase for this. Do you
have a specific one in mind?
Even in the XHR case, adding more than one listener is currently a
pain.
How so, exactly?
Aaron's note about addEventListener solves it, but in the common case
where a JS system wants to have multiple callbacks, they either wind
up carrying around their own event listener system (e.g.,
dojo.connect()) or a Deferred pattern to wrap functions which only
support direct dispatch from a single call site.
It's still not clear to me what that has to do with the questions I asked...
The only natural thing in DOM is the event flow from target to root. That
concept doesn't make much sense in the absence of a linear data structure
(the list of ancestors, here).
I think what I'd like to see is a way for this interface to allow
arbitrary JS object to specify what their ancestor is. That way
hierarchical JS objects can dispatch up.
OK. That makes some sense, assuming that the common case is that there
is in fact at most one ancestor. I don't have any data on whether
this is the common case; is it?
Is your real use case just to call a bunch of listeners in a defined order?
...
Other systems have similar conveniences, but in general they all exist
to keep developers from needing to do:
(function() {
var old_happened = thinger.happened;
thinger.happened = function() {
// ...
return old_happened.apply(this, arguments);
That still doesn't answer my question. You need such chaining in the
DOM, say, if you use the on* properties. But if you addEventListener,
you can have multiple listeners for a given event. The only caveat is
that dispatch order is undefined. So again, is the goal to have
multiple listeners per event, or to be able to enforce a specific
ordering on them? If the latter, would simply requiring dispatch in
addition order (which is, after all exactly what your example above
does) be sufficient?
This method of building callbacks on existing APIs is not, to use
your word, sane.
Oh, absolutely agreed.
-Boris
Re: [whatwg] Exposing EventTarget to JavaScript
Ojan Vafai wrote:
What would be a better approach?
I believe Alex proposed some in this thread as aliases for
addEventListener. Those looked a lot better to me, for what it's worth.
If a linear list of things the event is targeting is sufficient, of
course, and we're ok with the random third argument of addEventListener
being carted around, then we might be ok using it...
From my point of view, in addition to the things already mentioned, an
issue with addEventListener is that removing requires a match of both
the listener and the bubbles arg. So for example:
node.addEventListener(foo, function() { ... }, false);
if I want to remove it later, I suddenly have to pull the function out
and give it a name. And then on the remove end duplicate the foo and
false. Maybe it's just me, but I'd have much preferred something like:
var token = node.addEventListener(foo, function() { ... });
// later on
node.removeEventListener(token);
or some such.
-Boris
Re: [whatwg] Exposing EventTarget to JavaScript
Ojan Vafai wrote: If a linear list of things the event is targeting is sufficient, of course, and we're ok with the random third argument of addEventListener being carted around, then we might be ok using it... I think this is sufficient. Although it is a bit unfortunate that dispatch order is undefined. Those are unrelated issues, aren't they? The linear list I was referring to is the proposed parentNode (or equivalent) chain; order there is well-defined, presumably. For each element in this list, one can have multiple listeners for the event; the dispatch order here is currently undefined, but that could be changed. Is there a reason that they can't dispatch in a guaranteed order? You'd probably have to check with the folks who wrote DOM2 Events, if the question is why the spec says what it says. If the question is about current implementations, nothing obvious jumps out at me in the one implementation I'm familiar with (Gecko's). -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 6:37 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Ojan Vafai wrote:
What would be a better approach?
I believe Alex proposed some in this thread as aliases for
addEventListener. Those looked a lot better to me, for what it's worth.
I have no problem with adding these aliases as long as the DOM and JS APIs
match. I agree that listen/unlisten are better names.
If a linear list of things the event is targeting is sufficient, of course,
and we're ok with the random third argument of addEventListener being carted
around, then we might be ok using it...
I think this is sufficient. Although it is a bit unfortunate that dispatch
order is undefined. It would be great if we could just agree that dispatch
order is the order the handlers were registered in. I don't know the
technical details here though. Is there a reason that they can't dispatch in
a guaranteed order?
From my point of view, in addition to the things already mentioned, an issue
with addEventListener is that removing requires a match of both the listener
and the bubbles arg. So for example:
node.addEventListener(foo, function() { ... }, false);
if I want to remove it later, I suddenly have to pull the function out and
give it a name. And then on the remove end duplicate the foo and false.
Maybe it's just me, but I'd have much preferred something like:
var token = node.addEventListener(foo, function() { ... });
// later on
node.removeEventListener(token);
Yes, I completely agree that this is a significant shortcoming of
addEventListener. It seems like we could safely add this to the current API.
In short, I'm happy with evolving addEventListener to make it suck less if
we can keep the JS and DOM APIs consistent.
Ojan
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 7:26 PM, Boris Zbarsky bzbar...@mit.edu wrote: Ojan Vafai wrote: If a linear list of things the event is targeting is sufficient, of course, and we're ok with the random third argument of addEventListener being carted around, then we might be ok using it... I think this is sufficient. Although it is a bit unfortunate that dispatch order is undefined. Those are unrelated issues, aren't they? The linear list I was referring to is the proposed parentNode (or equivalent) chain; order there is well-defined, presumably. For each element in this list, one can have multiple listeners for the event; the dispatch order here is currently undefined, but that could be changed. Sorry, I had misread this. Although, I think a linear list of things the event is targeting is sufficient. Is there a reason that they can't dispatch in a guaranteed order? You'd probably have to check with the folks who wrote DOM2 Events, if the question is why the spec says what it says. If the question is about current implementations, nothing obvious jumps out at me in the one implementation I'm familiar with (Gecko's). Yeah, I'm more interested in implementation difficulties. I can't think of anything obvious in WebKit's implementation either, but I'm not too familiar with the event handling code. Ojan
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:59 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Apr 24, 2009 at 2:43 PM, Boris Zbarsky bzbar...@mit.edu wrote: Erik Arvidsson wrote: I do agree that the EventTarget API is suboptimal and so are most of the DOM APIs but it is what we got and we need tie the lose ends and make ends meet. Why is the right approach to this to add addEventListener and its baggage to everything instead of adding a sane API to everything? What would be a better approach? Turning an interface into a class doesn't make any sense at all. EventTarget is an interface. It would be trivial to create a new DOM object that implements EventTarget. Boris pointed out that there are some problems with addEventListener. Lets not ignore those. Trying to shoehorn an existing API to accomodate new functionality, in light of existing problems sounds like a bad idea. EventTarget should not become a Constructor. You gain a lot from consistency and doing something that developers are already intimately familiar with. Changing EventTarget from an interface into a Constructor would create less consistency in the behavior of instances implementing (or Extending) EventTarget, would result in less consistency in the expected behavior of such objects, and would reduce consistency in the EventTarget interface (old vs new). If you want consistency in an API, use a different one. The new one ignore |useCapture|, so clients wanting to use both could use duckTyping. Garrett
[whatwg] Parsing RFC3339 constructs
On Fri, 2 Jan 2009, Asbjørn Ulsberg wrote: Reading the spec, I have to wonder: Does HTML5 need to specify as much as it does inline? Can't more of it be referenced to ISO 8601 or even better; RFC 3339? I really fancy how Atom (RFC 4287) has defined date constructs: http://www.atompub.org/rfc4287.html#date.constructs Does not RFC 3339 defined date and time in a satisfactory manner to use directly in HTML5? The problem isn't so much the syntax definitions as the parsing definitions. We need very specific parsing rules; it's not clear that there is anything to refer to that does the job we need here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
