Michael is using today (or a
server-side generated inline script block if you want guaranteed
correctness).
Sincerely,
James Greene
Sent from my [smart?]phone
On May 26, 2014 6:37 PM, "Michael Heuberger" <
michael.heuber...@binarykitchen.com> wrote:
> Yeah, something like t
use case.
Sincerely,
James Greene
On Fri, May 23, 2014 at 3:33 AM, Silvia Pfeiffer
wrote:
> I had to deal with this on a script created IMG element the other day. I
> used onerror to deal with it.
> For xmlhttprequest you can use the status field.
> Why is that not enough?
>
I'm not opposed to this idea but... what Is a realistic use case for this?
Sincerely,
James Greene
On Thu, May 22, 2014 at 10:36 PM, Michael Heuberger <
michael.heuber...@binarykitchen.com> wrote:
> Hello WhatWG
>
> There is a need to obtain the HTTP status code for
If we're going to choose a name that abstracts the implementation details
(and rightly so), why not just go with `navigator.concurrency`?
Sincerely,
James Greene
Sent from my [smart?]phone
On May 4, 2014 8:50 AM, "Adam Barth" wrote:
> On Sun, May 4, 2014 at 12:1
ements don't have this map (it would be way too much memory cost),
> so it'll fall back to a standard tree search, exactly as a
> querySelector would.
Hmm, I suppose that makes sense. Bummer. Thanks for the concise
explanation!
Sincerely,
James Greene
On Fri, Oct 18, 2013 a
lement
interface. It would be nice to capitalize on that potential perf boost in
jQuery as well.
Sincerely,
James Greene
On Fri, Oct 18, 2013 at 12:47 PM, Ryosuke Niwa wrote:
> On Oct 18, 2013, at 5:22 AM, Tim Streater wrote:
>
> > On 15 Oct 2013 at 01:18, Glenn Maynard wrote:
Aww, accidentally did a direct reply instead of replying to the list. :(
On Sep 18, 2013 7:01 AM, "James Greene" wrote:
> var q = document.querySelector;
> var qq = document.querySelectorAll;
> On Sep 18, 2013 3:14 AM, "Leon Gilyadov" wrote:
>
>> *The p
f the proposed API used only CSS query selectors without also
allowing the additional NodeType filtering provided "whatToShow", then it
could not not be used to directly gather text nodes.
Might be OK to leave text nodes out... not sure how others use NIs/TWs.
Sincerely,
James Greene
Isn't that what the NodeIterator and TreeWalker APIs are for?
Sincerely,
James Greene
On Jul 27, 2013 1:25 PM, "Ojan Vafai" wrote:
> Realized this should probably be a new thread...
>
>
> On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai wrote:
>
> > On
Isn't that what the NodeIterator and TreeWalker DOM APIs were for?
Sincerely,
James Greene
On Jul 27, 2013 12:58 PM, "Ojan Vafai" wrote:
> On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking wrote:
>
> > On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky wrote:
>
gh that makes
perfect sense to me, I have never noticed it before nor heard of any
browser vendors implementing such. Have there been any such
implementations yet? If so, that's *wonderful* news. :)
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 4:27 PM, James Greene wrote:
> Rick —
completely off-base and
fragments *are* supposed to be most similar to document nodes, I'd agree
with the earlier suggestion that those who want this functionality should
just add it themselves via JS.
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 7:39 PM, Ryosuke Niwa wrote:
>
Rick —
Thanks for clarifying/correcting both my comment and Hixie's!
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 4:24 PM, Rick Waldron wrote:
> On Wed, Jul 24, 2013 at 2:50 PM, Ian Hickson wrote:
>
> > On Fri, 12 Jul 2013, James Greene wrote:
> > > On Fri
I'd love that! Perhaps similar to what Node.js did with their
`uncaughtException`
event <http://nodejs.org/api/process.html#process_event_uncaughtexception>?
Sincerely,
James Greene
On Fri, Jul 12, 2013 at 1:40 PM, Elliott Sprehn wrote:
> Can we just add a new event that
like one of those decisions that might
results in infinite sadness in the future.
Sincerely,
James Greene
On Mon, Mar 11, 2013 at 5:50 AM, Simon Pieters wrote:
> On Tue, 05 Feb 2013 08:20:27 +0100, Elliott Sprehn
> wrote:
>
> On Mon, Feb 4, 2013 at 5:44 PM, O
de us with
a real Error object instances (or even fake ones with shell properties in
the case of cross-domain errors).
If I'm mistaken, please clarify. Thanks!
Sincerely,
James Greene
On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson wrote:
> On Tue, 5 Feb 2013, Nathan Br
*Oh, another option:*
As long as the element does not have CSS styles applied via an ID selector,
you could just change the element ID temporarily rather than visually
hiding it in order to avoid the reflows.
Sincerely,
James Greene
On Wed, Jun 12, 2013 at 12:20 PM, James Greene wrote
at element again and then scroll to it (or
not, up to you).
Sincerely,
James Greene
On Tue, May 14, 2013 at 4:44 PM, Glenn Maynard wrote:
> On Tue, May 14, 2013 at 5:01 PM, Nils Dagsson Moskopp <
> n...@dieweltistgarnichtso.net> wrote:
>
> > The simplest solution
So, to that end, what about just adjusting the spec for the "hashchange"
event to also fire when the page is initially loaded if the URL contains a
fragment identifier (hash)? The other scenarios mentioned would already be
covered by the "hashchange" event.
Sincerely,
Ja
I love that idea!
Sincerely,
James Greene
On Mon, May 13, 2013 at 9:53 PM, Kyle Simpson wrote:
> Increasingly, sites are doing client-side rendering at page load time,
> which is breaking the (useful) functionality of being able to have a #hash
> on a URL that auto-scrolls th
Simon emailed me personally to answer my last question about what's next: "We
wait for the editor to process this thread. It might take a while, but
he'll get to it."
Other than that, there haven't been any discussions that I've been privy to.
Sincerely,
James
Alright... so what's next? I'm assuming this needs further discussion with
other WHATWG members chiming in. If I can help, please let me know. I'd
like to see this request through.
Sincerely,
James Greene
On Fri, May 11, 2012 at 12:26 PM, Simon Pieters wrote:
> On F
t;eval()"
calls...? I may also be thinking of this differently as a JS engineer
versus a browser vendor, so please help clue me in. I'm interested to
learn more on this, and it may help me better appreciate why the
"window.onerror" callback mechanism *didn't* just pass an &
can get
whatever information they want from it. But, if it's a security thing, I
guess I'm willing to accept that....
Sincerely,
James Greene
On Wed, May 9, 2012 at 4:12 AM, Simon Pieters wrote:
> On Wed, 09 May 2012 03:56:29 +0200, James Greene
> wrote:
>
> Full pro
Full proposal details:
https://gist.github.com/3ded0f6e7f0a658b9394
P.S. I had no idea what "product" to file this under in the W3C Bugzilla,
so it has NOT been filed there. I HAVE posted a new topic to the Forums but
it is still awaiting moderator approval.
Sincerely,
James Greene
25 matches
Mail list logo
