Is there time available on the April F2F agenda for discussion of this? If not
in WebApps, would relevant WG members be willing to join us if we found time to
discuss in WebAppSec's timeslot Thursday or Friday?
From: dglaz...@google.com [mailto:dglaz...@google.com] On Behalf Of Dimitri
In looking at [1], I don't see whether the baseURI property should contain
the fragment identifier. I have noticed that WebKit based browsers remove
the fragment identifier and Firefox does not.
Specifically, when a document uses the 'base' element with a URI that
contains a fragment identifier,
On Thu, Mar 14, 2013 at 3:50 PM, Alex Milowski a...@milowski.com wrote:
Meanwhile, the base URI resolution of HTML5 defers to RFC 3986 (section 5)
and does not mention removing it. In section 5.2, you'll see that the
fragment identifier is preserved (as would be expected). Thus, it seems
On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad bh...@paypal-inc.com wrote:
Is there time available on the April F2F agenda for discussion of this?
If not in WebApps, would relevant WG members be willing to join us if we
found time to discuss in WebAppSec’s timeslot Thursday or Friday?
Briefly looking through, I do not see anything that says differently.
Nothing says the fragment identifier should be removed. So, these
specifications are silent on this.
Certainly, having the base URI contain a fragment identifier has no effect
on the resolved URI as the fragment identifier
On Thu, Mar 14, 2013 at 5:16 PM, Alex Milowski a...@milowski.com wrote:
Briefly looking through, I do not see anything that says differently.
Nothing says the fragment identifier should be removed. So, these
specifications are silent on this.
I just meant that going forward you should read
On Thu, Mar 14, 2013 at 10:31 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Thu, Mar 14, 2013 at 5:16 PM, Alex Milowski a...@milowski.com wrote:
Briefly looking through, I do not see anything that says differently.
Nothing says the fragment identifier should be removed. So, these
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 easier
On Thu, 10 Jan 2013 18:24:52 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
And if so, which objects should they be on? Window? Documents?
Elements?
Currently event handlers are available on all of Window, Document and
HTMLElement even if the relevant event just fires on one of them, so I
This is a WG-wide Request for Review [RfR] for the tests Microsoft and
Opera submitted for the Web Workers CR [CR]:
http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/
http://w3c-test.org/webapps/Workers/tests/submissions/Opera/
Simon (Web Workers' `Test Facilitator`) proposed in
Thanks for diving into the conversation Tab! I guess I just need to wait for
Elliott to confirm shadow roots create counter scopes.
Andrei.
From: Tab Atkins Jr. [jackalm...@gmail.com]
Sent: Monday, March 11, 2013 12:53 PM
To: Andrei Bucur
Cc: Elliott
On Thu, Mar 14, 2013 at 12:47 PM, Andrei Bucur abu...@adobe.com wrote:
Thanks for diving into the conversation Tab! I guess I just need to wait for
Elliott to confirm shadow roots create counter scopes.
I talked with him about this at lunch, and he's fine with it.
~TJ
On Thursday, March 14, 2013 at 7:54 PM, Alex Russell wrote:
On Wednesday, March 6, 2013, Tobie Langel wrote:
Sync APIs are useful to do I/O inside of a Worker.
I don't understand why that's true. Workers have a message-oriented API
that's inherently async. They can get back to their
On Thu, 14 Mar 2013 18:15:14 +0100, Dimitri Glazkov
dglaz...@chromium.org wrote:
On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad bh...@paypal-inc.com wrote:
Is there time available on the April F2F agenda for discussion of this?
If not in WebApps, would relevant WG members be willing to join
Here's one scenario where keeping components Documents might be a good
idea. Suppose you just built a multi-threaded parser into your renderer
engine, and you would like to hook it up to start loading multiple
components in parallel. How difficult will it be for you to do this if they
were all
On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell slightly...@google.comwrote:
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
On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell slightly...@google.com
wrote:
I don't understand why that's true. Workers have a message-oriented API
that's inherently async. They can get back to their caller whenevs. What's
On Thursday, March 14, 2013, Tab Atkins Jr. wrote:
On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard gl...@zewt.orgjavascript:;
wrote:
On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell
slightly...@google.comjavascript:;
wrote:
I don't understand why that's true. Workers have a
On Thu, Mar 14, 2013 at 8:58 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
The entire reason for most async (all?) APIs is thus irrelevant in a
Worker, and it may be a good idea to provide sync versions, or do
something else that negates the annoyance of dealing with async code.
I agree,
On Thursday, March 14, 2013, Glenn Maynard wrote:
On Thu, Mar 14, 2013 at 8:58 PM, Tab Atkins Jr.
jackalm...@gmail.comjavascript:_e({}, 'cvml', 'jackalm...@gmail.com');
wrote:
The entire reason for most async (all?) APIs is thus irrelevant in a
Worker, and it may be a good idea to
On Thu, Mar 14, 2013 at 9:41 PM, Alex Russell slightly...@google.comwrote:
I didn't imply they were. But addressing the pain point of asynchronous
code that's hard to use doesn't imply that the only answer is a synchronous
version.
The asynchronous programming model is often inherently
On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov dglaz...@google.comwrote:
Here's one scenario where keeping components Documents might be a good
idea. Suppose you just built a multi-threaded parser into your renderer
engine, and you would like to hook it up to start loading multiple
* Alex Russell wrote:
My *first* approach to this annoyance would be to start adding some async
primitives to the platform that don't suck so hard; e.g., Futures/Promises.
Saying that you should do something does not imply that doubling up on API
surface area for a corner-case is the right
On Thu, Mar 14, 2013 at 10:19 PM, Alex Russell slightly...@google.comwrote:
On Thursday, March 14, 2013, Tab Atkins Jr. wrote:
On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell slightly...@google.com
wrote:
I don't
24 matches
Mail list logo
