Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Jarred Nicholls]

On Thu, Mar 14, 2013 at 10:19 PM, Alex Russell wrote:

>
>
> 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-oriented API
>> >> that's inherently async. They can get back to their caller "whenevs".
>> What's
>> >> the motivator for needing this?
>> >
>> > Being able to write synchronous code is one of the basic uses for
>> Workers in
>> > the first place.  Synchronously creating streams is useful in the same
>> way
>> > that other synchronous APIs are useful, such as FileReaderSync.
>> >
>> > That doesn't necessarily mean having a synchronous API for a complex
>> > interface like this is the ideal approach (there are other ways to do
>> it),
>> > but that's the end goal.
>>
>> Yes, this seems to be missing the point of Workers entirely.  If all
>> you have are async apis, you don't need Workers in the first place, as
>> you can just use them in the main thread without jank.
>
>
I wouldn't say that.  Async code will eventually be scheduled to execute on
the UI thread, which can cause contention with other tasks that must run on
that same UI thread.  Using a worker thread to perform (async) XHR requests
and JSON decoding while the UI thread focused on other rendering tasks was
one of the methods we (Sencha) used to increase News Feed performance for
Fastbook.  I agree with a lot of what you're saying re: workers, but I
don't agree that they wouldn't be needed if all we had were async apis.


>  Workers exist
>> explicitly to allow you to do expensive synchronous stuff without
>> janking the main thread.  (Often, the expensive synchronous stuff will
>> just be a bunch of calculations, so you don't have to explicitly break
>> it up into setTimeout-able chunks.)
>>
>> 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.
>>
>
> 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.
>

+1.  Libraries cover that fairly well; albeit I think we all would enjoy
such things to be first-class citizens of the platform.  I've seen some
good looking implementations and some decent control flow libraries.  I use
https://github.com/caolan/async a lot in node projects.


> Saying that you should do something does not imply that doubling up on API
> surface area for a corner-case is the right solution.
>

I agree.  It may have seemed like a good and simple idea at first - well
intentioned for sure - but upon reflection we have to admit it's sloppy, a
greater surface area to maintain, and the antithesis of DRY.  It's not what
I personally would expect from a modern, quality JS api, and I'm probably
not the only web dev to share that feeling.  At the risk of making a
blanketed statement using anecdotal evidence, I would claim that
overindulgence from modern libraries in existence today has raised the
expectations of web devs in how the web platform architects new apis.


>
>> > (FYI, the messaging in Workers isn't inherently async; it just happens
>> to
>> > only have an async interface.  There's been discussion about adding a
>> > synchronous interface to messaging.)
>>
>> Specifically, this was for workers to be able to synchronously wait
>> for messages from their sub-workers.  Again, the whole point for async
>> worker messaging is to prevent the main thread from janking, which is
>> irrelevant inside of a worker.
>>
>> ~TJ
>>
>

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Bjoern Hoehrmann]

* 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 solution.

http://lists.w3.org/Archives/Public/www-archive/2008Jul/0009.html was my
"first approach". Workers of course have it much easier, they just need
a single waiting primitive to make an asynchronous API synchronous. I've
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1016.html
argued against duplicating APIs for workers as proposed here, but so far
without much success, it would seem...
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [webcomponents]: Making produce DocumentFragments

[Dominic Cooney]

On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov wrote:

> 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 just DocumentFragments in the same document?
>

Given that having components be parsed in the same document complicates the
specification, complicates the implementation (for example resolving
relative resources), might threaten some optimizations (multi-threaded
parsing), and gives a benefit that authors could achieve using tools to
crunch multiple component files into one, I propose that:

Each resource is loaded in its own document.

What about the type of the Component's content attribute? Should that be
DocumentFragment or Document?

Dominic


> On Mon, Mar 11, 2013 at 4:13 PM, Dimitri Glazkov wrote:
>
>> Hi folks!
>>
>> Just had a quick discussion with Elliott and he suggested that instead of
>> building full-blown Documents, the  just make
>> DocumentFragments, just like  does.
>>
>> Looking at
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document-object
>>  and
>> the bunch of APIs that will never be useful on a document without a
>> browsing context, I think it's a pretty good idea. It should make also
>> components more lightweight.
>>
>> The only problem is that now I have to figure out how to specify this
>> without just flat-out stealing, err... I mean reusing, large swaths of
>> HTML5 spec. But I'll take this one for the team.
>>
>> :DG<
>>
>
>


-- 
Email SLA  •
Google+

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Glenn Maynard]

On Thu, Mar 14, 2013 at 9:41 PM, Alex Russell wrote:

> 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 inconvenient
compared to synchronous code, and synchronous APIs (whether at the
individual API level, or at another level such as synchronous messaging or
yieldable coroutines) are indeed the only practical solution that's been
proposed so far.  I believe this is a fundamental issue, but if you have a
concrete alternative proposal to make then by all means do so (in another
thread).  Otherwise, this just isn't helpful.

This is not a particularly hard or subtle point.
>

(Let's try to remain civil.)

-- 
Glenn Maynard

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Alex Russell]

On Thursday, March 14, 2013, Glenn Maynard wrote:

> On Thu, Mar 14, 2013 at 8:58 PM, Tab Atkins Jr. 
> 
> > wrote:
>
>> 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, 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 Thu, Mar 14, 2013 at 9:19 PM, 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 solution.
>
>
> "Futures" are nothing but a different async API.  They're in no way
> comparable to synchronous code.
>

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. This is not a particularly hard or subtle point.


> But, as I said, it's true that a second synchronous interface isn't
> necessarily the best solution for complex APIs like IndexedDB.  At least in
> this particular case, if we have a synchronous messaging API I might call
> the synchronous IDB interface unnecessary.
>
> --
> Glenn Maynard
>
>

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Glenn Maynard]

On Thu, Mar 14, 2013 at 8:58 PM, Tab Atkins Jr. wrote:

> 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, 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 Thu, Mar 14, 2013 at 9:19 PM, 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 solution.


"Futures" are nothing but a different async API.  They're in no way
comparable to synchronous code.

But, as I said, it's true that a second synchronous interface isn't
necessarily the best solution for complex APIs like IndexedDB.  At least in
this particular case, if we have a synchronous messaging API I might call
the synchronous IDB interface unnecessary.

-- 
Glenn Maynard

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Alex Russell]

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-oriented API
> >> that's inherently async. They can get back to their caller "whenevs".
> What's
> >> the motivator for needing this?
> >
> > Being able to write synchronous code is one of the basic uses for
> Workers in
> > the first place.  Synchronously creating streams is useful in the same
> way
> > that other synchronous APIs are useful, such as FileReaderSync.
> >
> > That doesn't necessarily mean having a synchronous API for a complex
> > interface like this is the ideal approach (there are other ways to do
> it),
> > but that's the end goal.
>
> Yes, this seems to be missing the point of Workers entirely.  If all
> you have are async apis, you don't need Workers in the first place, as
> you can just use them in the main thread without jank.  Workers exist
> explicitly to allow you to do expensive synchronous stuff without
> janking the main thread.  (Often, the expensive synchronous stuff will
> just be a bunch of calculations, so you don't have to explicitly break
> it up into setTimeout-able chunks.)
>
> 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.
>

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 solution.


> > (FYI, the messaging in Workers isn't inherently async; it just happens to
> > only have an async interface.  There's been discussion about adding a
> > synchronous interface to messaging.)
>
> Specifically, this was for workers to be able to synchronously wait
> for messages from their sub-workers.  Again, the whole point for async
> worker messaging is to prevent the main thread from janking, which is
> irrelevant inside of a worker.
>
> ~TJ
>

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Tab Atkins Jr.]

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-oriented API
>> that's inherently async. They can get back to their caller "whenevs". What's
>> the motivator for needing this?
>
> Being able to write synchronous code is one of the basic uses for Workers in
> the first place.  Synchronously creating streams is useful in the same way
> that other synchronous APIs are useful, such as FileReaderSync.
>
> That doesn't necessarily mean having a synchronous API for a complex
> interface like this is the ideal approach (there are other ways to do it),
> but that's the end goal.

Yes, this seems to be missing the point of Workers entirely.  If all
you have are async apis, you don't need Workers in the first place, as
you can just use them in the main thread without jank.  Workers exist
explicitly to allow you to do expensive synchronous stuff without
janking the main thread.  (Often, the expensive synchronous stuff will
just be a bunch of calculations, so you don't have to explicitly break
it up into setTimeout-able chunks.)

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.

> (FYI, the messaging in Workers isn't inherently async; it just happens to
> only have an async interface.  There's been discussion about adding a
> synchronous interface to messaging.)

Specifically, this was for workers to be able to synchronously wait
for messages from their sub-workers.  Again, the whole point for async
worker messaging is to prevent the main thread from janking, which is
irrelevant inside of a worker.

~TJ

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Glenn Maynard]

On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell wrote:

> 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 to read/write for some devs.
>> Since this is mirrored throughout other platform APIs, I wouldn't count
>> this as a fault in IDB specifically.
>>
>> 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 caller "whenevs".
> What's the motivator for needing this?
>

Being able to write synchronous code is one of the basic uses for Workers
in the first place.  Synchronously creating streams is useful in the same
way that other synchronous APIs are useful, such as FileReaderSync.

That doesn't necessarily mean having a synchronous API for a complex
interface like this is the ideal approach (there are other ways to do it),
but that's the end goal.

(FYI, the messaging in Workers isn't inherently async; it just happens to
only have an async interface.  There's been discussion about adding a
synchronous interface to messaging.)

-- 
Glenn Maynard

Re: [webcomponents]: Making produce DocumentFragments

[Dimitri Glazkov]

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 just DocumentFragments in the same document?

:DG<


On Mon, Mar 11, 2013 at 4:13 PM, Dimitri Glazkov wrote:

> Hi folks!
>
> Just had a quick discussion with Elliott and he suggested that instead of
> building full-blown Documents, the  just make
> DocumentFragments, just like  does.
>
> Looking at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document-object
>  and
> the bunch of APIs that will never be useful on a document without a
> browsing context, I think it's a pretty good idea. It should make also
> components more lightweight.
>
> The only problem is that now I have to figure out how to specify this
> without just flat-out stealing, err... I mean reusing, large swaths of
> HTML5 spec. But I'll take this one for the team.
>
> :DG<
>

Re: security model of Web Components, etc. - joint work with WebAppSec?

[Charles McCathie Nevile]

On Thu, 14 Mar 2013 18:15:14 +0100, Dimitri Glazkov  
 wrote:



On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad  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?


http://www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics Shows
agenda wide open so far. Should we just plop something into one of the
slots?


Yep, that's a reasonable thing to do...

cheers

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Tobie Langel]

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 caller "whenevs". What's 
> the motivator for needing this?
There's no need per se. Sync API are easier to handle, and given you're already 
out of the UI thread, blocking in that context isn't much of an issue.
> > They're also critical for data consistency in some scenarios, e.g. updating 
> > the database after a successful xhr request when a worker is about to be 
> > terminated.
> 
> Unload-catching is a known bug in much o the web platform. Why would we 
> enable it here?

Nevermind. The Web Worker termination process (now?) says scripts get aborted 
anyway.

--tobie

Re: [shadow-dom] Counters and list item counting

[Tab Atkins Jr.]

On Thu, Mar 14, 2013 at 12:47 PM, Andrei Bucur  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

RE: [shadow-dom] Counters and list item counting

[Andrei Bucur]

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 Sprehn; public-webapps
Subject: Re: [shadow-dom] Counters and list item counting

On Thu, Mar 7, 2013 at 1:43 AM, Andrei Bucur  wrote:
> Hello,
>
> I want to clarify a certain situation:
>   
> A
> 
> 
> X
> Y
> 
> 
> C
>   
>
> How is this case supposed to be rendered?
> 1. A
> 2. 1. X
> 2. Y
> 3. C
>
> or
>
> 1.  A
> 2,3. X
> 4. Y
> 5. C
>
> Basically, do we want the shadow root to become the counting root for the 
> s inside the shadow or we let them go through the upper boundary and use 
> the  instead?
> I would vote for the first rendering as it seems to better respect the shadow 
> encapsulation. If so, it also means we need to prevent the propagation of the 
> type, reversed etc. attributes of the parent 
> to the shadow s, right?

Hm, either rendering is consistent with what we've already answered.
I think I'm with you, saying that the shadow root is also a root for
counter scopes.  I'd like Elliot to comment before I commit to
anything, though, as he knows more about WebKit's counter
implementation.

~TJ

RfR: Web Workers Test Cases; deadline March 28

[Arthur Barstow]

This is a WG-wide Request for Review [RfR] for the tests Microsoft and 
Opera submitted for the Web Workers CR [CR]:





Simon (Web Workers' `Test Facilitator`) proposed in [1] the tests are 
sufficient to test the CR's exit criteria.


If you have any comments, please send them to 
public-webapps-testsu...@w3.org by March 28.


If you review any set of the tests and find no issues, please state that 
as a reply to this RfR (so we can get a sense of whether or not anyone 
reviewed the tests).


In the absence of any comments, these tests will be considered Approved 
by the WG.


-Thanks, AB

[RfR] 
[CR] 
[1] 

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Simon Pieters]

On Thu, 10 Jan 2013 18:24:52 +0100, Boris Zbarsky  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  
suggest we do that.


--
Simon Pieters
Opera Software

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Alex Russell]

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 to read/write for some devs.
> Since this is mirrored throughout other platform APIs, I wouldn't count
> this as a fault in IDB specifically.
>
> 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 caller "whenevs".
What's the motivator for needing this?


> They're also critical for data consistency in some scenarios, e.g.
> updating the database after a successful xhr request when a worker is about
> to be terminated.
>

Unload-catching is a known bug in much o the web platform. Why would we
enable it here?

Re: Node.baseURI and Fragment Identifiers

[Alex Milowski]

On Thu, Mar 14, 2013 at 10:31 AM, Anne van Kesteren wrote:

> On Thu, Mar 14, 2013 at 5:16 PM, Alex Milowski  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 the latest stuff. And
> as far as I can tell they're not silent on it. They simple resolve the
> URL and that's it. No chopping fragments going on.
>
>
Yes.  You're right and I believe the WebKit browser are just in error on
this.  I just wanted to confirm that I'm not missing something somewhere.

Thanks.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Re: Node.baseURI and Fragment Identifiers

[Anne van Kesteren]

On Thu, Mar 14, 2013 at 5:16 PM, Alex Milowski  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 the latest stuff. And
as far as I can tell they're not silent on it. They simple resolve the
URL and that's it. No chopping fragments going on.


-- 
http://annevankesteren.nl/

Re: Node.baseURI and Fragment Identifiers

[Alex Milowski]

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 comes from the reference and
not the base URI.


On Thu, Mar 14, 2013 at 9:23 AM, Anne van Kesteren  wrote:

> On Thu, Mar 14, 2013 at 3:50 PM, Alex Milowski  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
> > that Firefox is right.
>
> Yes. I recommend reading the latest material on the matter going forward
> though:
>
> http://dom.spec.whatwg.org/
> http://www.whatwg.org/specs/web-apps/current-work/multipage/
>
> Cheers,
>
>
> --
> http://annevankesteren.nl/
>



-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Re: security model of Web Components, etc. - joint work with WebAppSec?

[Dimitri Glazkov]

On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad  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?
>
http://www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics Shows
agenda wide open so far. Should we just plop something into one of the
slots?

:DG<

Re: Node.baseURI and Fragment Identifiers

[Anne van Kesteren]

On Thu, Mar 14, 2013 at 3:50 PM, Alex Milowski  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
> that Firefox is right.

Yes. I recommend reading the latest material on the matter going forward though:

http://dom.spec.whatwg.org/
http://www.whatwg.org/specs/web-apps/current-work/multipage/

Cheers,


-- 
http://annevankesteren.nl/

Node.baseURI and Fragment Identifiers

[Alex Milowski]

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, Firefox and WebKit will differ.  Who is
correct?

This (DOM Core) specification defers to other specifications which are not
referenced by [1].

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
that Firefox is right.

[1] http://www.w3.org/TR/domcore/#concept-node-base-url
[2] http://tools.ietf.org/html/rfc3986#section-5.2

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

RE: security model of Web Components, etc. - joint work with WebAppSec?

[Hill, Brad]

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 
Glazkov
Sent: Monday, March 11, 2013 1:23 PM
To: Arthur Barstow
Cc: Hill, Brad; public-webapp...@w3.org; WebApps WG (public-webapps@w3.org)
Subject: Re: security model of Web Components, etc. - joint work with WebAppSec?

On Sat, Mar 9, 2013 at 4:36 AM, Arthur Barstow 
mailto:art.bars...@nokia.com>> wrote:
[ Apology for top-posting and continuing the cross-posting ]

Hi Brad,

Thanks, yes earlier security review and feedback would be good.

My preference is to use public-webapps (solely) for all discussions related to 
Web Components (WC).

Re discussing security and WC f2f, I added a joint meeting between these two 
groups as a potential agenda topic for WebApps' April 25-26 f2f meeting [1] but 
I did not allocate a specific day+time slot because it could be a bit premature 
right now. That said, if you, or Dimitri, or other WC people have a specific 
day+time you would prefer, please speak up and note we intend to meet all day 
on the 25th but only until noon on the 26th. (Of course we can cancel the joint 
meeting if it turns out there is no need to meet.)

I am happy to help facilitate this. Please let me know how I can help.

:DG<