On Thu, Jun 30, 2011 at 2:11 AM, Jonas Sicking wrote:
> On Wednesday, June 29, 2011, Aryeh Gregor
> wrote:
> > On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sicking wrote:
> >> This new proposal solves both these by making all the modifications
> >> first, then firing all the events. Hence the impleme
Since Dimitri has already said everything I would, and better, I just
want to very quickly second his point about where we are today vs.
where we fear we might be: non-trivial apps have *already* given up on
HTML. Suggesting that there's an un-semantic future that will be
*caused* by the component
On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard wrote:
> On 9/2/11 12:10 PM, Alex Russell wrote:
>>
>> Since Dimitri has already said everything I would, and better, I just
>> want to very quickly second his point about where we are today vs.
>> where we fear we migh
On Fri, Sep 2, 2011 at 3:58 PM, Charles Pritchard wrote:
> On 9/2/11 3:00 PM, Alex Russell wrote:
>>
>> On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard wrote:
>>
>>>
>>> On 9/2/11 12:10 PM, Alex Russell wrote:
>>>
>>>>
>>>&g
On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson wrote:
> On Sat, 3 Sep 2011, Dominic Cooney wrote:
>> >
>> > I think the XBL approach is far superior here -- have authors use
>> > existing elements, and use XBL to augment them. For example, if you
>> > want the user to select a country from a map, you
On Fri, Sep 9, 2011 at 6:38 PM, Sean Hogan wrote:
> On 10/09/11 11:00 AM, Jonas Sicking wrote:
>>
>> On Fri, Sep 9, 2011 at 2:27 PM, Sean Hogan
>> wrote:
>>>
>>> On 10/09/11 3:21 AM, Jonas Sicking wrote:
It's a completely useless function. It just implements the equality
operator.
I would, again, like to bring up the issue of non-constructable
constructors as the default in WebIDL. It is onerous to down-stream
authors to leave such a foot-gun in the spec if they're *expected* to
provide constructors for most classes (and this is JS we're talking
about, so they are) and it is
+1
What Charles said = )
On Wed, Sep 28, 2011 at 5:22 PM, Charles Pritchard wrote:
> On 9/27/2011 11:39 PM, Roland Steiner wrote:
>
>> Expanding on the general web component discussion, one area that hasn't
>> been touched on AFAIK is how components fit within the content model of HTML
>> eleme
On Mon, Sep 26, 2011 at 8:28 AM, Anne van Kesteren wrote:
> On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov
> wrote:
>>
>> Further, instead of packaging Web Components into one omnibus
>> offering, we will likely end up with several free-standing specs or
>> spec addendums:
>>
>> 1) Shadow DO
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and ":scope". He asked me to continue here, so I'll try to keep it
short:
The rooted forms of "querySelector" and "querySelectorAll" are mis-designed.
Discuss
On Tue, Oct 18, 2011 at 5:42 PM, Alex Russell wrote:
> Lachlan and I have been having an...um...*spirited* twitter discussion
> regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
> and ":scope". He asked me to continue here, so I'll try to keep it
> sho
On Tue, Oct 18, 2011 at 6:00 PM, Erik Arvidsson wrote:
> On Tue, Oct 18, 2011 at 09:42, Alex Russell wrote:
>> Ah, but we don't need to care what CSS thinks of our DOM-only API. We
>> can live and let live by building on ":scope" and specifying find* as
low selectors to start with
> combinators. That seems very useful.)
>
> On Tue, Oct 18, 2011 at 9:47 AM, Alex Russell wrote:
>> On Tue, Oct 18, 2011 at 5:42 PM, Alex Russell wrote:
>>> Lachlan and I have been having an...um...*spirited* twitter discussion
>>> r
Can someone explain _why_
> you can't - under absolutely any circumstances - begin a selector with
> a combinator - even if there appears to be wide agreement that it
> makes sense in a finite set of circumstances?
>
>
>
> On Tue, Oct 18, 2011 at 12:42 PM, Alex Russell
;re discussing here.
> Bugs in specific browsers.
>
> jQuery also handles certain custom pseudoselectors, and it might be nice if
> it was possible to register JavaScript functions that qSA would use if it
> found an unknown pseudo (this would make it possible to implement most of
> jQue
On Tue, Oct 18, 2011 at 9:40 PM, Boris Zbarsky wrote:
> On 10/18/11 4:20 PM, Yehuda Katz wrote:
>>
>> * Speeding up certain operations like `#foo` and `body`. There is *no
>> excuse* for it being possible to implement userland hacks that
>> improve on the performance of querySelectorAll.
>
ith
":scope "
> On Oct 18, 2011 7:40 PM, "Alex Russell" wrote:
>>
>> On Tue, Oct 18, 2011 at 6:00 PM, Erik Arvidsson wrote:
>> > On Tue, Oct 18, 2011 at 09:42, Alex Russell
>> > wrote:
>> >> Ah, but we don't need to care what CSS
On Wed, Oct 19, 2011 at 12:46 AM, Sean Hogan wrote:
> On 19/10/11 7:20 AM, Yehuda Katz wrote:
>>
>> I agree entirely.
>>
>> I have asked a number of practitioner friends about this scenario:
>>
>>
>> Content
>>
>>
>> document.getElementById("child").querySelectorAll("div span"); // returns
>> #
On Wed, Oct 19, 2011 at 2:26 AM, Boris Zbarsky wrote:
> On 10/18/11 8:08 PM, Alex Russell wrote:
>>>
>>> The other "excuse" is that adding special cases (which is what you're
>>> asking
>>> for) slows down all the non-special-cas
arity, for common stuff should nearly always win.
> On Tue, Oct 18, 2011 at 6:15 PM, Boris Zbarsky wrote:
>>
>> On 10/18/11 7:38 PM, Alex Russell wrote:
>>>
>>> The resolution I think is most natural is to split on ","
>>
>> That fails with :
On Wed, Oct 19, 2011 at 9:29 AM, Anne van Kesteren wrote:
> On Wed, 19 Oct 2011 17:22:46 +0900, Alex Russell
> wrote:
>>
>> Yehuda is representing jQuery. I'll take his opinion as the global
>> view unless he choses to say he's representing a personal opinio
On Wed, Oct 19, 2011 at 1:54 PM, Lachlan Hunt wrote:
> On 2011-10-18 18:42, Alex Russell wrote:
>>
>> Related and equally important, that querySelector and querySelectorAll
>> are often referred to by the abbreviation "QSA" suggests that its name
>> is bloa
On Wed, Oct 19, 2011 at 7:01 PM, Lachlan Hunt wrote:
> On 2011-10-19 16:08, Alex Russell wrote:
>>
>> On Wed, Oct 19, 2011 at 1:54 PM, Lachlan Hunt
>> wrote:
>>>
>>> I have attempted to address this problem before and the algorithm for
>>> pa
On Thu, Oct 20, 2011 at 3:07 AM, Jonas Sicking wrote:
> On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell wrote:
>> Lachlan and I have been having an...um...*spirited* twitter discussion
>> regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
>> and ":scope
On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sicking wrote:
> On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell wrote:
>> Lachlan and I have been having an...um...*spirited* twitter discussion
>> regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
>> and ":scope
On Thu, Oct 20, 2011 at 12:05 PM, Lachlan Hunt wrote:
> On 2011-10-20 12:50, Alex Russell wrote:
>>
>> On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sicking wrote:
>>>
>>> Oh, and as a separate issue. I think .findAll should return a plain
>>> old JS Array
On Thu, Oct 20, 2011 at 3:14 PM, Boris Zbarsky wrote:
> On 10/20/11 7:18 AM, Alex Russell wrote:
>>
>> No we don't. The fact that there's someone else who has a handle to
>> the list and can mutate it underneath you
>
> There is no sane way to mutate t
+1!
On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
> Hi everyone,
>
> It was pointed out to me on twitter that BlobBuilder can be replaced
> with simply making Blob constructable. I.e. the following code:
>
> var bb = new BlobBuilder();
> bb.append(blob1);
> bb.append(blob2);
> bb.append("
On Fri, Oct 21, 2011 at 12:41 AM, Jonas Sicking wrote:
> On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt
> wrote:
>> Not necessarily. It depends what exactly it means for a selector to
>> contain
>> :scope for determining whether or not to enable the implied :scope
>> behaviour. Consider:
>>
>>
What Tab said = )
On Sun, Oct 30, 2011 at 9:23 AM, Tab Atkins Jr. wrote:
> On Sat, Oct 29, 2011 at 8:28 PM, Cameron McCormack wrote:
>> On 20/10/11 3:50 AM, Alex Russell wrote:
>>>
>>> I strongly agree that it should be an Array *type*, but I think just
>>>
On Sun, Oct 30, 2011 at 1:23 PM, Rick Waldron wrote:
>
>
> On Sat, Oct 29, 2011 at 11:28 PM, Cameron McCormack wrote:
>>
>> On 20/10/11 3:50 AM, Alex Russell wrote:
>>>
>>> I strongly agree that it should be an Array *type*, but I think just
>>> re
On Mon, Oct 31, 2011 at 2:03 PM, Cameron McCormack wrote:
> On 31/10/11 1:56 PM, Alex Russell wrote:
>>
>> Live NodeList instances don't need to be considered here. They're the
>> result of an API which generates them, and that API can be described
>> in te
On Mon, Oct 31, 2011 at 2:18 PM, Charles Pritchard wrote:
> On 10/31/11 2:03 PM, Cameron McCormack wrote:
>>
>> On 31/10/11 1:56 PM, Alex Russell wrote:
>>>
>>> Live NodeList instances don't need to be considered here. They're the
>>> result
What Tab said.
On Tue, Apr 24, 2012 at 5:45 PM, Tab Atkins Jr. wrote:
> On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill wrote:
>> Hmm. I have to say that I disagree that your example below shows a
>> template within a template. That is IMO 1 template wherein there is
>> iteration syntax.
>
> The "it
On Wed, May 2, 2012 at 12:42 AM, Dimitri Glazkov wrote:
> Based on the hallway conversations at the F2F, here are some notes for
> the upcoming Custom Elements spec.
>
> Custom tags vs. "is" attribute
> - "is" attribute is awkward, overly verbose
> - custom tags introduce local semantics
> - gener
Hi all,
Looking at Section 3.4 of the CSP 1.1 draft [1], I'm noticing that the IDL
specified feels very, very strange to use from the JS perspective.
For instance, the name "document.SecurityPolicy" would indicate to a mere
JS hacker like me that the SecurityPolicy is a class from which instances
Inline.
On Mon, Nov 5, 2012 at 9:27 AM, Mike West wrote:
> On Sun, Nov 4, 2012 at 9:58 PM, Alex Russell wrote:
>
>> Looking at Section 3.4 of the CSP 1.1 draft [1], I'm noticing that the
>> IDL specified feels very, very strange to use from the JS perspective.
>>
On Mon, Nov 5, 2012 at 10:56 AM, David Bruant wrote:
> Le 05/11/2012 11:32, Alex Russell a écrit :
>
> On Mon, Nov 5, 2012 at 1:08 AM, Boris Zbarsky wrote:
>
>> On 11/4/12 3:58 PM, Alex Russell wrote:
>>
>>> DOMString toString();
>>>
>>
On Mon, Nov 5, 2012 at 12:14 PM, David Bruant wrote:
> Le 05/11/2012 12:50, Alex Russell a écrit :
>
> On Mon, Nov 5, 2012 at 10:56 AM, David Bruant wrote:
>
>> Le 05/11/2012 11:32, Alex Russell a écrit :
>>
>> On Mon, Nov 5, 2012 at 1:08 AM, Boris Zbarsky wr
Sorry for the late response.
Adding more "create*" methods feels like a bug. I understand that there are
a couple of concerns/arguments here:
- Current implementations that aren't self-hosting are going to have
trouble with the idea of unattached ("floating") ShadowRoot instances
- As a
Greetings Victor!
>
>
> On Dec 10, 2012, at 12:02 PM, Victor Costan wrote:
>
> > Dear Web Applications WG,
> >
> > 1) Please add a File constructor.
>
>
> This has cropped up a few times :) I've logged a spec bug for this
> feature: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20887
>
> Could y
+others who have been involved in the design phase of the Google proposal
So there are several viable points in the design space here. I'll try to
outline them quickly:
1. An internal lifecycle driver for element + shadow creation.
In this strategy, an element's constructor either calls
Comments inline. Adding some folks from the IDB team at Google to the
thread as well as public-webapps.
On Sunday, February 17, 2013, Miko Nieminen wrote:
>
>
> 2013/2/15 Shwetank Dixit
>
>> Why did you feel it was necessary to write a layer on top of IndexedDB?
>>>
>>
>> I think this is the ma
On Wednesday, March 6, 2013, Glenn Maynard wrote:
> On Wed, Mar 6, 2013 at 8:01 AM, Alex Russell
>
> > wrote:
>
>> Comments inline. Adding some folks from the IDB team at Google to the
>> thread as well as public-webapps.
>>
>
> (I don't want to cold
On Wednesday, March 6, 2013, Ian Fette (イアンフェッティ) wrote:
> I seem to recall we contemplated people writing libraries on top of IDB
> from the beginning. I'm not sure why this is a bad thing.
>
It's not bad as an assumption, but it can quickly turn into an excuse for
API design malpractice because
On Wednesday, March 6, 2013, Tobie Langel wrote:
> On Wednesday, March 6, 2013 at 5:51 PM, Jarred Nicholls wrote:
> > This is an entirely different conversation though. I don't know the
> answer to why sync interfaces are there and expected, except that some
> would argue that it makes the code ea
On Thursday, March 14, 2013, Tab Atkins Jr. wrote:
> On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard >
> wrote:
> > On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell
> >
> >
> > wrote:
> >> I don't understand why that's true. Workers have a message
> something else that negates the annoyance of dealing with async code.
>>
>
> I agree, except that async APIs are also useful and relevant in workers.
> Sometimes you want synchronous code and sometimes you want asynchronous
> code, depending on what you're doing.
>
&
On Wed, Nov 27, 2013 at 9:46 AM, Dimitri Glazkov wrote:
> Stepping back a bit, I think we're struggling to ignore the elephant in
> the room. This elephant is the fact that there's no specification (or API)
> that defines (or provides facilities to control) when rendering happens.
> And for that m
fOn Thu, Dec 5, 2013 at 2:14 AM, Ke-Fong Lin wrote:
> >> 1) Sync APIs are inherently easier to use than async ones, and they are
> much
> >> less error prone. JS developers are not C++ developers. Whenever
> possible, it's
> >> just better to make things more simpler and convenient.
> >
> >This a
On Wed, Dec 4, 2013 at 4:38 PM, Charles Pritchard wrote:
>
> On 12/4/13, 2:43 AM, Ke-Fong Lin wrote:
>
>> IMHO, we should make sync APIs available in both dedicated and shared
>> workers.
>> In order of importance:
>>
>> 1) Sync APIs are inherently easier to use than async ones, and they are
>> m
On Tue, Feb 11, 2014 at 5:16 PM, Maciej Stachowiak wrote:
>
> On Feb 11, 2014, at 4:04 PM, Dimitri Glazkov
> wrote:
>
> On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak wrote:
>
>>
>> On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov
>> wrote:
>>
>>
>>
>>> Dimitri, Maciej, Ryosuke - is there a mu
On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren wrote:
> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell
> wrote:
> > Until we can agree on this, Type 2 feels like an attractive nuisance
> and, on
> > reflection, one that I think we should punt to compilers like caja i
On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak wrote:
>
> On Feb 12, 2014, at 4:04 PM, Alex Russell wrote:
>
>
>
> In discussion with Elliot and Erik, there appears to be an additional
> complication: any of the DOM manipulation methods that aren't locked down
>
On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa wrote:
> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn wrote:
>
> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky wrote:
>
>> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>>
>>> Also, I think that the Type 2 encapsulation has the same
>>> characteristics.
On Wed, Feb 12, 2014 at 5:21 PM, Jonas Sicking wrote:
> On Wed, Feb 12, 2014 at 12:06 PM, Marcos Caceres
> wrote:
> > The editors of the [manifest] spec have now closed all substantive
> issues for "v1".
> >
> > The spec defines the following:
> >
> > * A link relationship for manifests (so the
On 14 Feb 2014 17:39, "Ryosuke Niwa" wrote:
>
> On Feb 14, 2014, at 5:17 PM, Alex Russell wrote:
>
>> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa wrote:
>>>
>>> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn
wrote:
>>>>
>>>> On
On Sat, Feb 15, 2014 at 1:57 AM, Maciej Stachowiak wrote:
>
> On Feb 14, 2014, at 9:00 AM, Erik Arvidsson wrote:
>
>
>
>
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak wrote:
>
>>
>> On Feb 13, 2014, at 4:01 PM, Alex Russell
>> wrote:
>>
On Sat, Feb 15, 2014 at 4:57 PM, Ryosuke Niwa wrote:
> Hi all,
>
> I’d like to propose one solution for
>
> [Shadow]: Specify imperative API for node distribution
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429
>
> because select content attribute doesn’t satisfy the needs of
> framework/l
if we
plow on with V1 without a (required) offline story, I'm not sure what we've
really won. Happy for this to go to LC, but wouldn't recommend that Chrome
For Android implement.
> On Saturday, February 15, 2014 at 1:37 AM, Alex Russell wrote:
>
> > I further think th
On Sun, Feb 16, 2014 at 12:52 AM, Ryosuke Niwa wrote:
> On Feb 16, 2014, at 12:42 AM, Ryosuke Niwa wrote:
>
> On Feb 15, 2014, at 11:30 PM, Alex Russell wrote:
>
> On Sat, Feb 15, 2014 at 4:57 PM, Ryosuke Niwa wrote:
>
>> Hi all,
>>
>> I’d like to pr
On Tue, Feb 18, 2014 at 4:59 AM, Arthur Barstow wrote:
> On 2/17/14 9:17 AM, ext Jungkee Song wrote:
>
> On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow
> > art.bars...@nokia.com>> wrote:
>>
>> The only process requirement for a FPWD is that the group record
>> consensus to publish it. H
On Mon, Jun 2, 2014 at 2:06 AM, Jonas Sicking wrote:
> On Fri, May 30, 2014 at 5:40 PM, Jeffrey Walton
> wrote:
> > Are there any platforms providing the feature? Has the feature gained
> > any traction among the platform vendors?
>
> The webapps platform that we use in FirefoxOS and Firefox Des
Hey all,
Apologies for the late notice.
As many SW participants are going to be in town for the WebApps F2F on the
21st, Google San Francisco is hosting a working day, 9am-5pm PST on July
20th to work through open issues and discuss future work.
If you're attending, or would like to, simply RSVP
Thanks everyone! Started a draft agenda page here; please pile in!
https://github.com/slightlyoff/ServiceWorker/wiki/july_20_2015_meeting_agenda
On Wed, Jul 15, 2015 at 10:38 PM, Benjamin Kelly wrote:
> On Sat, Jul 4, 2015 at 7:26 AM, Alex Russell
> wrote:
>
>> As many SW p
Sorry to hear you're leaving us, Art. Your skills and humor will be missed.
On Fri, Jan 29, 2016 at 7:51 AM, Philippe Le Hegaret wrote:
> Thank you Art.
>
> You carried out this group and community over so many years.
>
> Your first email to the AC was entitled "Just say NO?" as a response to a
I have a preference for the second syntax. These sorts of classes
should always be "new"-able.
On Tue, Sep 14, 2010 at 10:46 AM, Jonas Sicking wrote:
> Hi All,
>
> There was some discussions regarding the syntax for generating a
> FormData object based on the data in an existing . I had
> propose
How 'bouts a shorter version of Tab's suggestion: "Web Components" ?
On Thu, Dec 16, 2010 at 5:59 AM, Anne van Kesteren wrote:
> On Thu, 16 Dec 2010 14:51:39 +0100, Robin Berjon wrote:
>>
>> On Dec 14, 2010, at 22:24 , Dimitri Glazkov wrote:
>>>
>>> Looking at the use cases and the problems the
On Tue, Apr 26, 2011 at 7:32 AM, Tab Atkins Jr. wrote:
> On Mon, Apr 25, 2011 at 9:14 PM, Boris Zbarsky wrote:
>> On 4/22/11 8:35 PM, Rafael Weinstein wrote:
>>> Myself and a few other chromium folks have been working on a design
>>> for a formalized separation between View and Model in the brows
On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak wrote:
>
> On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote:
>
>> On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak wrote:
>>>
>>> On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote:
>>>
>
>
>>
>> What do you think?
>>
I do agree the title is important and support either of the
proposed new titles (preference goes with "Resource"). One question
I have here is whether "Domain" would be more accurate than "Origin".
Domain does not capture significance of the scheme and port, while
Origin does. I'm updatin
Wed, 14 Jan 2009 17:52:50 +0100, Alex Russell
wrote:
I do agree the title is important and support either of the
proposed new titles (preference goes with "Resource"). One
question I have here is whether "Domain" would be more accurate
than "Origin".
Domain
Can this be represented in a :not() clause somehow? Foisting more work
onto script is the wrong answer.
Regards
On Jan 26, 2009, at 9:21 AM, Lachlan Hunt wrote:
Lachlan Hunt wrote:
Erik Dahlström wrote:
On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt
wrote:
== 8. Examples
Please add
On Jan 26, 2009, at 1:49 PM, Lachlan Hunt wrote:
Alex Russell wrote:
Can this be represented in a :not() clause somehow? Foisting more
work onto script is the wrong answer.
No.
How about "not yet"?
Needing to do this filtering in script is clearly a spec bug. QSA is
alread
mespaces, but is the selectors API actually going
to be this impoverished? If so, I fear it will prevent the actual
mixing of SVG and HTML in meaningful ways.
Regards
On Jan 26, 2009, at 3:38 PM, Lachlan Hunt wrote:
Alex Russell wrote:
On Jan 26, 2009, at 1:49 PM, Lachlan Hunt wrote:
Ale
>From this thread on whatwg:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019379.html
and per Hixie's request that I re-direct this particular discussion here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019381.html
The DOM function "addEventListener
Wow, I just found this thread again. I suck for having not replied
earlier. Sorry 'bout that. Comments inline.
On Fri, Apr 24, 2009 at 3:23 PM, Doug Schepers wrote:
> Hi, Alex-
>
> Alex Russell wrote (on 4/24/09 5:31 PM):
>>
>> The DOM function "addEventListener&q
On Dec 18, 2009, at 3:09 PM, Marcos Caceres wrote:
On Fri, Dec 18, 2009 at 4:40 AM, Maciej Stachowiak
wrote:
On Dec 17, 2009, at 3:15 PM, Klotz, Leigh wrote:
OK, so is the conclusion that XHR is implementable only in HTML5 and
should be re-titled "XMLHttpRequest in HTML5" or something sim
78 matches
Mail list logo
