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
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./
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
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
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
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
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
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
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
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
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
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
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 /
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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...
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
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:
36 matches
Mail list logo
