Reminder: RfC: LCWD of Web Storage ; deadline November 15

[Arthur Barstow]

 Original Message 
Subject:RfC: LCWD of Web Storage ; deadline November 15
Resent-Date:Thu, 27 Oct 2011 11:04:52 +
Resent-From:
Date:   Thu, 27 Oct 2011 07:04:19 -0400
From:   ext Arthur Barstow 
To: public-webapps 



On October 25 a LCWD of Web Storage was published:

  http://www.w3.org/TR/2011/WD-webstorage-20111025/

Please send all comments to public-webapps@w3.org by November 15.

Re: "We just ran out of time ..." [Was: Re: Component Model f2f: Actionable things]

[Robin Berjon]

On Nov 3, 2011, at 05:38 , Arthur Barstow wrote:
> Well, we may get together more frequently than just the annual TPAC meeting 
> week. If folks think that would be useful (e.g. in 6 months), please speak up 
> and we can take it from there. Otherwise, WebApps' next f2f meeting is during 
> the 2012 TPAC meeting in Lyon, FR Oct 29 - Nov 2.

I think that it would be useful for WebApps to get together more frequently 
(without overdoing it). I'm a big fan of async work in general, but getting 
people in the same room once in a while helps bang long standing issues into 
shape and also release whatever pent up tension may have been building.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Who is the audience?

[Robin Berjon]

On Nov 7, 2011, at 20:52 , Dimitri Glazkov wrote:
> One theme that was easy to observe at the conference was the pondering
> around who those mysterious consumers of what we do are, how to reach
> them, and how to reason about them. I heard people speak of Web
> Authors and Web Developers and making various distinctions about them.
> 
> I heard some folks of arguing that this audience of ours prefers
> markup over scripts, and when faced with concrete examples of the
> opposite, retort that those are just some script library folk, not the
> majority.
> 
> It made me think that perhaps pure democracy as means of assessing the
> needs of such a vast, enormously uneven (in terms of skill and
> influence) audience is severely flawed. And moreover, it's likely
> responsible for the sad situation we're in today, where markup is a
> rare craft, cutting-edge Web apps are nothing but bootstraps for
> loading script, and the actual Web influencers (like jQuery engineers)
> actually have to send designated ambassadors into our realm to try and
> reason with us.

The problem of getting input from our audience is a long-standing one. There 
are clearly way too many web developers out there for us to ask them all, which 
means getting feedback requires mediation. In turn, mediation has all sorts of 
problems, including the usual clique and confirmation biases that can kick in 
despite the best of intentions.

During the "jQuery Standards Group" breakout, we agreed to kick off the Script 
Library Community Group (http://www.w3.org/community/scriptlib/) which could 
serve as a venue for developers to come provide their ideas and feedback 
without having to follow a fire hose mailing list such as this one or being 
crushed to bits by untactful folks. I think it would also make sense for spec 
writers to send "What do you prefer?" questions there.

There aren't many people on the group yet since it's so fresh, but I think that 
we can solve that rather quickly. Spreading the word as to its existence is 
certainly recommended :)

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

HTML Editing APIs is already in scope [Was: Re: Draft Minutes: 31 October 2011 f2f meeting]

[Arthur Barstow]

Below is a followup on the short discussion we had on October 31 re the 
HTML Editing APIs ...


On 11/1/11 10:05 AM, Arthur Barstow wrote:
The DRAFT minutes from the October 31 f2f meeting are in the following 
document and copied below:


http://www.w3.org/2011/10/31-webapps-minutes.html

12. [16]Charter/Editing


http://www.w3.org/2011/10/31-webapps-minutes.html#item12



Charter/Editing

   ArtB: I know Aryeh was working on Editing
   ... but he didn't make a commitment
   ... do we let him continue working in the CG
   ... do we pick it up now, pick it up later?

   ryosuke: i'd like to see it in the charter

   ArtB: aryeh felt that having it in a CG to do work forward
   ... but he didn't object to this WG finalizing it

   chaals: in the absence of someone driving it in Web Apps
   ... I think it would be a bad idea
   ... especially without the resources

   Josh_Soref: How is this any different from the previous charter
   item?

  #whatwg: AryehGregor "Microsoft Corp. has joined the HTML
   Editing APIs Community Group"

   chaals: I am proposing that we reject Editing APIs under similar
   circumstances
   ... given that there is a CG
   ... I feel we should let them alone given they already have a CG and
   we aren't likely to add much

   ryosuke: there's a difference in complexity
   ... Editing is much more complicated
   ... I think it will take a couple of years before it's ready

   adrianba: Microsoft just joined the CG with the intent of helping it
   there

   chaals: does anyone propose that we move editing into the WG?

   RESOLUTION: We will not move Editing into this WG


The following part of the charter does make the HTML Editing APIs in 
scope for WebApps:


[[
http://www.w3.org/2010/webapps/charter/#others

Specifically, because of the close relationship of the WebApps WG and 
the HTML WG in terms of participants, market, and community, the WebApps 
WG may opt to take on a limited number of specifications which were 
initially part of the HTML5 specification that have been split off for 
more general use with other languages.

]]

My summary is: although HTML Editing APIs is in scope for WebApps, and 
we agreed to use public-webapps for related discussions [1], given no 
one has agreed to actively drive the spec in WebApps, we will not 
include it as an explicit deliverable in WebApps' charter update. If 
anyone disagrees with this summary, please speak up.


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1617.html

Re: HTML Editing APIs is already in scope [Was: Re: Draft Minutes: 31 October 2011 f2f meeting]

[Aryeh Gregor]

On Tue, Nov 8, 2011 at 9:17 AM, Arthur Barstow  wrote:
> My summary is: although HTML Editing APIs is in scope for WebApps, and we
> agreed to use public-webapps for related discussions [1], given no one has
> agreed to actively drive the spec in WebApps, we will not include it as an
> explicit deliverable in WebApps' charter update. If anyone disagrees with
> this summary, please speak up.

I think this situation is ideal for the time being.

Re: State of subclassing and tag names in the component model

[Dominic Cooney]

Hi Boris,

This is my current thinking, although this blends/steals a lot of ideas
from TPAC:

There are two kinds of components—ones that are a refinement of something
in HTML, like a select element or a button; and ones that have no genuine
peer in HTML.

This is the litmus test: If you were writing this today, would you start
with a div or span? Then your component is probably the second kind.

Custom tag names have a number of downsides:

A. Markup with custom tags could actually be hard to write, because the
HTML parser will have to have permissive behavior around custom tags that
won’t match developer’s intuition of how parsing works. We could let
component authors specify a context for parsing, but that would require
them to understand the parser, which is a high bar.

B. The semantics of custom tags are weak. A UA that doesn’t run JavaScript
would have to assign them a pretty neutral meaning, at least at first. (A
page well-authored for fallback may never expose a UA to this problem
though.)

C. As you point out, existing specs, implementations, stylesheets and
libraries expect certain tag names, and custom tags break that. That is a
difficult practical problem.

Recalling the two kinds of components, I think custom tag names are a bad
fit for the first kind—the kind that have a semantic cousin in HTML. A, B
and C will be problems for these kinds of components.

For the second kind, B and C are less of a problem because the component is
something totally new. Maybe custom tag names could work for those kinds of
components.

I think the way forward is for us to work on components that use an
existing tag name, and identify the component with an attribute, for now. I
think that this is superior to custom tag names for the first kind of
component, and it can trivially be used for the second kind of
component—just use div or span as the tag name.

Dominic

On Tue, Nov 8, 2011 at 6:29 AM, Boris Zbarsky  wrote:

> All,
>
> At this I've lost track of what the current proposals are on tag names in
> the component model.  I've been thinking about this a bit, and I would like
> us to look at a particular use case: subclassing  and adding some
> behavior to it.
>
> An obvious question: Should the localName/tagName of the resulting element
> be "img" or something else?
>
> The way I see it, if it's "img" then everything should Just Work for this
> element and component binding just has to be done via an attribute.
>
> If it's something else, then as far as I can tell we would probably need
> to change various specifications to look at whatever "img" is for this
> element (not the localName anymore).  This likely includes various parts of
> HTML5, possibly selector matching for UA and maybe user stylesheets, and so
> forth.  Furthermore, the result would still not be treated as an image by
> various script libraries out there.  But maybe that's desirable?
>
> In any case, for every single place where one could consider what sort of
> element one has we would need to specify whether it's the localName that's
> being used or whatever other property evaluates to "img" or
> HTMLImageElement in this context.
>
> Is that a reasonable summary of the state of things?
>
> -Boris
>
>

[Bug 14727] New: Deleting doesn't handle non-normalized sublists correctly

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14727

   Summary: Deleting doesn't handle non-normalized sublists
correctly
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: minor
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


Test for delete command:

  foo{}bar

This should be equivalent to

  foo{}bar

but isn't.  See bug 13976.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13976] Backspacing in between two lists should merge them

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13976

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Aryeh Gregor  2011-11-08 16:27:39 UTC ---
https://dvcs.w3.org/hg/editing/rev/b3afc97ff16e

I added a whole bunch more tests than the ones from comment 0.  See bug 14727
for the sublist normalization issue.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 14729] New: Inline formatting should add wrappers inside empty blocks

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14729

   Summary: Inline formatting should add wrappers inside empty
blocks
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


See bug 13831 comment 6.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13831] Deleting a block should leave style tags nested inside

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13831

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Aryeh Gregor  2011-11-08 16:44:26 UTC ---
https://dvcs.w3.org/hg/editing/rev/d461532af710

Filed bug 14729 for comment 6.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 14729] Inline formatting should add wrappers inside empty blocks

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14729

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Aryeh Gregor  2011-11-08 17:30:48 UTC ---
https://dvcs.w3.org/hg/editing/rev/0e6c95119654

This turned out to be easy -- I just changed the definition of "formattable
node" (although it took a couple of tries to get it right).  It turns out that
was a good abstraction to use.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13973] Refactor delete stuff

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13973

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Aryeh Gregor  2011-11-08 17:32:47 UTC ---
I don't see much more to change, offhand.  If I run into more headaches when
doing delete stuff, I guess I'll do more refactoring then of whatever parts
seem to be flaky.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Consolidating charter changes

[Arthur Barstow]

During the October 31 meeting, we discussed [1] various additions, 
changes and deletions for WebApps' current charter [2]. To consolidate 
the various proposals, I created the following doc:




My expectation is that Doug will this information when he drafts our 
updated charter.


Comments on this doc and our future charter welcome. However, if we are 
going to add any new deliverables, I think there should be broad 
agreement on the spec, including prior commitment to drive the spec 
through all of the phases of the process including testing and 
implementations.


Chaals, IanF - I included some actions/questions for you (mostly 
recorded at the f2f meeting).


-AB

[1] http://www.w3.org/2011/10/31-webapps-minutes.html
[2] http://www.w3.org/2010/webapps/charter/

Re: State of subclassing and tag names in the component model

[Boris Zbarsky]

On 11/8/11 10:32 AM, Dominic Cooney wrote:

There are two kinds of components—ones that are a refinement of
something in HTML, like a select element or a button; and ones that have
no genuine peer in HTML.

This is the litmus test: If you were writing this today, would you start
with a div or span? Then your component is probably the second kind.


Yes, agreed.


Recalling the two kinds of components, I think custom tag names are a
bad fit for the first kind—the kind that have a semantic cousin in HTML.
A, B and C will be problems for these kinds of components.


Yes.


I think the way forward is for us to work on components that use an
existing tag name, and identify the component with an attribute, for
now.


Sounds good.

-Boris

Re: Consolidating charter changes

[James Hawkins]

To clarify, should we comment on this thread or in the wiki?

Thanks,
James

On Tue, Nov 8, 2011 at 9:37 AM, Arthur Barstow wrote:

> During the October 31 meeting, we discussed [1] various additions, changes
> and deletions for WebApps' current charter [2]. To consolidate the various
> proposals, I created the following doc:
>
> 
> >
>
> My expectation is that Doug will this information when he drafts our
> updated charter.
>
> Comments on this doc and our future charter welcome. However, if we are
> going to add any new deliverables, I think there should be broad agreement
> on the spec, including prior commitment to drive the spec through all of
> the phases of the process including testing and implementations.
>
> Chaals, IanF - I included some actions/questions for you (mostly recorded
> at the f2f meeting).
>
> -AB
>
> [1] 
> http://www.w3.org/2011/10/31-**webapps-minutes.html
> [2] 
> http://www.w3.org/2010/**webapps/charter/
>
>
>

Re: Consolidating charter changes

[Arthur Barstow]

I propose using the mail list and then after we get consensus, the wiki 
is updated accordingly.


On 11/8/11 1:04 PM, ext James Hawkins wrote:

To clarify, should we comment on this thread or in the wiki?

Thanks,
James

On Tue, Nov 8, 2011 at 9:37 AM, Arthur Barstow > wrote:


During the October 31 meeting, we discussed [1] various additions,
changes and deletions for WebApps' current charter [2]. To
consolidate the various proposals, I created the following doc:



My expectation is that Doug will this information when he drafts
our updated charter.

Comments on this doc and our future charter welcome. However, if
we are going to add any new deliverables, I think there should be
broad agreement on the spec, including prior commitment to drive
the spec through all of the phases of the process including
testing and implementations.

Chaals, IanF - I included some actions/questions for you (mostly
recorded at the f2f meeting).

-AB

[1] http://www.w3.org/2011/10/31-webapps-minutes.html
[2] http://www.w3.org/2010/webapps/charter/

[Bug 13893] Only HTML elements should be editable

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13893

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Aryeh Gregor  2011-11-08 19:24:21 UTC ---
https://dvcs.w3.org/hg/editing/rev/f4f95c3f51d6

I'm not actually testing this requirement anywhere for the time being, since
it's a bit niche.  There's no way to actually create  or  right now
using the editing APIs anyway.  But the requirement is now there.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

IndexedDB: IDBIndex.multientry attribute?

[Joshua Bell]

Should IDBIndex (and IDBIndexSync) expose a readonly boolean "multientry"
attribute reflecting the multientry flag of the index?

The index's unique flag is exposed in this way. Is there a reason the
multientry flag is not?

Re: [indexeddb] Implicit Transaction Request associated with failed transactions

[David Grogan]

On Wed, Oct 26, 2011 at 4:36 PM, Israel Hilerio wrote:

> On Friday, October 14, 2011 2:33 PM, Jonas Sicking wrote:
> > On Thu, Oct 13, 2011 at 10:57 AM, Israel Hilerio 
> > wrote:
> > > On Monday, October 10, 2011 10:10 PM, Jonas Sicking wrote:
> > >> On Thu, Oct 6, 2011 at 3:30 PM, Israel Hilerio  >
> > wrote:
> > >> > On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking wrote:
> > >> >> On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking 
> > wrote:
> > >> >> > On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio
> > >> >> > 
> > >> >> wrote:
> > >> >> >> Based on previous conversations, it seems we've agreed that
> > >> >> >> there are
> > >> >> situations in which a transaction could failed independent of
> > >> >> explicit requests (i.e. QUOTA_ERR, TIMEOUT_ERR).  We believe that
> > >> >> this can be represented as an implicit request that is being
> > >> >> triggered by a transaction.  We would like to add this concept to
> > >> >> the spec.  The benefit of doing this is that it will allow
> > >> >> developers to detect the error code associated with a direct
> > >> >> transaction failure.  This is
> > >> how we see the concept being used:
> > >> >> >>
> > >> >> >> trans.onerror = function (e) {
> > >> >> >> //eventTarget is mapped to an implicit transaction that was
> > >> >> >> created behind the scenes to track the transaction
> > >> >> >>
> > >> >> >>  if (e.eventTarget.errorCode === TIMEOUT_ERR) {
> > >> >> >>// you know the transaction error because of a timeout
> > >> >> >> problem
> > >> >> >>  }
> > >> >> >>  else if (e.eventTarget.errorCode === TIMEOUT_ERR) {
> > >> >> >>   // you know the transaction error because of a quota problem
> > >> >> >>  }
> > >> >> >> }
> > >> >> >>
> > >> >> >> Our assumption is that the error came not from an explicit
> > >> >> >> request but
> > >> >> from the transaction itself.  The way it is today, the
> > >> >> e.eventTarget will not exists (will be undefined) because the
> > >> >> error was not generated from an explicit request.  Today,
> > >> >> eventTargets are only populated from explicit requests.
> > >> >> >
> > >> >> > Good catch!
> > >> >> >
> > >> >> > We had a long thread about this a while back with the subject
> > >> >> > "[IndexedDB] Reason for aborting transactions". But it seems to
> > >> >> > have fizzled with no real conclusion as to changing the spec. In
> > >> >> > part that seems to have been my fault pushing back at exposing
> > >> >> > the reason for a aborted transaction.
> > >> >> >
> > >> >> > I think I was wrong :-)
> > >> >> >
> > >> >> > I think I would prefer adding a .errorCode on IDBTransaction
> > >> >> > through (or .errorName or .error or whatever we'll end up
> changing it
> > to).
> > >> >> > This seems more clear than creating a implicit request object.
> > >> >> > It'll also make it easy to find the error if you're outside the
> > >> >> > error handler. With the implicit request, you have no way of
> > >> >> > getting to the request, and thus the error code, from code
> > >> >> > outside the error handler, such from code that looks at the
> > >> >> > transaction after it has
> > >> run.
> > >> >> >
> > >> >> > And the code above would work exactly as is!
> > >> >> >
> > >> >> > Let me know what you think?
> > >> >>
> > >> >> In detail, here is what I suggest:
> > >> >>
> > >> >> 1. Add a .errorCode (or .errorName/.error) property on
> > >> >> IDBTransaction/IDBTransactionSync.
> > >> >> 2. The property default to 0 (or empty string/null) 3. In the
> > >> >> "Steps for aborting a transaction" add a new step between the
> > >> >> current steps
> > >> >> 1 and 2 which says something like "set the errorCode property of
> > >> >> transaction to code".
> > >> >>
> > >> >> This way the reason for the abort is available (through the
> > >> >> transaction) while firing the "error" event on all still pending
> > >> >> requests in step 2. The reason is also available while firing the
> > >> >> "abort" event on the transaction itself.
> > >> >>
> > >> >> / Jonas
> > >> >
> > >> > Independent on how we handler error, we like this approach!  This
> > >> > is our
> > >> interpretation of the impact it will have on the overall feature.
> > >> >
> > >> > SCENARIO #1:
> > >> > Whenever there is an error on a request, the error value associated
> > >> > with the
> > >> request will be assigned to the transaction error value.
> > >> > The error value in the transaction will be available on the
> > >> IDBTransaction.onerror and IDBTransaction.onabort handlers.
> > >> >
> > >> > SCENARIO #2:
> > >> > Whenever there is an error associated with the transaction (e.g.
> > >> > QUOTA or
> > >> TIMEOUT ), the error value associated with the failure (e.g. QUOTA or
> > >> TIMEOUT) will be assigned to the transaction error value.  The error
> > >> value in the transaction will be available on the
> > >> IDBTransaction.onerror and IDBTransaction.onabort handlers.
> > >> >
> > >> > SCENARIO #3:
> > >> > A developer uses the IDBTransaction.abort() method to 

Re: Consolidating charter changes

[James Hawkins]

Under 'Additions Agreed':
* Web Intents - this will be a joint deliverable with DAPI WG

Pedantically, not politically: My recollection is that the agreement was
only to add Web Intents to the Webapps charter (neither accepting nor
denying a joint deliverable with DAPI).  The status of the joint
deliverable is still a possibility, just technically not agreed upon as of
yet.  It may be best to reword this to state that the possibility still
exists, so those not in attendance don't get the idea that we agreed to a
joint deliverable at the meeting.

Thanks,
James

On Tue, Nov 8, 2011 at 9:37 AM, Arthur Barstow wrote:

> During the October 31 meeting, we discussed [1] various additions, changes
> and deletions for WebApps' current charter [2]. To consolidate the various
> proposals, I created the following doc:
>
> 
> >
>
> My expectation is that Doug will this information when he drafts our
> updated charter.
>
> Comments on this doc and our future charter welcome. However, if we are
> going to add any new deliverables, I think there should be broad agreement
> on the spec, including prior commitment to drive the spec through all of
> the phases of the process including testing and implementations.
>
> Chaals, IanF - I included some actions/questions for you (mostly recorded
> at the f2f meeting).
>
> -AB
>
> [1] 
> http://www.w3.org/2011/10/31-**webapps-minutes.html
> [2] 
> http://www.w3.org/2010/**webapps/charter/
>
>
>

Re: IndexedDB: IDBIndex.multientry attribute?

[Jonas Sicking]

Yes! Please file a bug on this. We really should be tracking these types of
things in bugs as we approach last call. We noticed tidy that .cmp still
returns reversed results for example.

/ Jonas

On Tuesday, November 8, 2011, Joshua Bell  wrote:
> Should IDBIndex (and IDBIndexSync) expose a readonly boolean "multientry"
attribute reflecting the multientry flag of the index?
> The index's unique flag is exposed in this way. Is there a reason the
multientry flag is not?
>

RE: [indexeddb] Implicit Transaction Request associated with failed transactions

[Israel Hilerio]

On Tuesday, November 08, 2011 2:09 PM, David Grogan wrote:
>On Wed, Oct 26, 2011 at 4:36 PM, Israel Hilerio  wrote:
>>On Friday, October 14, 2011 2:33 PM, Jonas Sicking wrote:
>>> > The firing of error events on the transaction should only be of two types:
>>> propagation error events or transaction error events.
>>> >
>>> > This should allow devs the ability to handle data error objects inside 
>>> > their
>>> IDBRequest.onerror handler and transaction commit error on their
>>> IDBTransaction.onerror handler.  The only difference is that QuotaError and
>>> TimeoutError would wouldn't be cancellable and will always bubble.
>>>
>>> Not quite sure what you mean by "propagation error events". Do you mean
>>> events that are fired on a request, but where the transaction.onerror 
>>> handler
>>> is called during the event's bubble phase?
>>>
>>> If so I think this sounds good. However there's still the matter of defining
>>> when a "transaction error event" should be fired.
>>> Transactions currently fail to commit in at least the following
>>> circumstances:

>>Yes, by "propagation error events" I meant events that are fired on a 
>>request, but where the transaction.onerror handler is called during the 
>>event's bubble phase.

>>> A) When transaction.abort() is explicitly called
>>> B) When a .put or .add request fails due to a 'unique' constraint violation 
>>> in an
>>> index, and the result "error" event *isn't* canceled using
>>> event.preventDefault()
>>> C) When an exception is thrown during a event handler for a "error" event
>>> D) When an exception is thrown during a event handler for a "success" event
>>> E) When a index is created with a 'unique' constraint on an objectStore 
>>> which
>>> already has data which violates the constraint.
>>> F) When a request fails due to database error (for example IO error) and the
>>> resulting "error" event *isn't* canceled using
>>> event.preventDefault()
>>> G) When a transaction fails to commit due to a quota error
>>> H) When a transaction fails to commit due to a IO error
>>> I) When a transaction fails to commit due to a timeout error
>>
>>Great list :-)
>>
>>>
>>> I've probably missed some places too.
>>>
>>> In which of these occasions do you think we should fire an "error"
>>> event on the transaction before firing the "abort" event? And note that in
>>> *all* of the above cases we will fire a "abort" event on the transaction.
>>>
>>> >From the discussion so far, it sounds like you *don't* want to fire an
>>> "error" event for at least for situation A, which makes sense to me.
>>>
>>> Whatever situations we decide to fire an "error" event in, I'd like there 
>>> to be
>>> some sort of consistency. I'd also like to start by looking at use cases 
>>> rather
>>> than just at random pick situations that seem good.
>>>
>>> So, if anyone think we should fire error events targeted at the transaction 
>>> in
>>> any of the above situations, please state use cases, and which of the above
>>> situations you think should generate an error event.
>>>
>>> Additionally, I'm not sure that we need to worry about I) above. I) only
>>> happens when there are timeouts specified, which only is possible in the
>>> synchronous API. But in the synchronous API we never fire any events, but
>>> simply let IDBDatabaseSync.transaction throw an exception.
>>>
>>> / Jonas
>>
>>I believe that error events on the transaction should be fired for individual 
>>request related issues:
>>B) When a .put or .add request fails due to a 'unique' constraint violation 
>>in an index, and the result "error" event *isn't* canceled using 
>>event.preventDefault()
>>C) When an exception is thrown during an event handler for a "error" event
>>D) When an exception is thrown during an event handler for a "success" event
>>E) When an index is created with a 'unique' constraint on an objectStore 
>>which already has data which violates the constraint.
>>F) When a request fails due to database error (for example IO error) and the 
>>resulting "error" event *isn't* canceled using event.preventDefault()
>>
>>However, I don't believe we should fire error events on the transaction for 
>>transaction related issues:
>>G) When a transaction fails to commit due to a quota error
>>H) When a transaction fails to commit due to a IO error
>>
>>My fundamental argument is that these are two different types of error cases, 
>>request and fatal errors.  I believe that developers want to handle request 
>>errors because 
>>they can do something about them.  These request errors are reflections of 
>>problems related to individual requests (i.e. add, put, delete record issues 
>>or schema related >>issues).  Preventing their default behavior will allow 
>>devs to add 99 records into the db but ignore the last 1 record that failed 
>>without having to restart the >>transaction.

>>On the other hand, fatal errors are different. They are associated with a 
>>backend problem that is not necessarily a reflection of a single

Re: innerHTML in DocumentFragment

[Ojan Vafai]

Providing concise, easy and XSS safe ways to generate a DOM is certainly
something we have to solve. I don't think sandbox is the best way to
achieve this. Specifically, I don't believe sandbox on iframes actually
strips the script elements, does it? It just doesn't execute them.

If we want to continue down the string->DOM approach, then I agree with
Jonas, we need to define an algorithm for safe innerHTML and use it in all
the places where we can currently set HTML. I'm open to supporting this
use-case because the XHR pattern is so common.

The other solution being proposed for easy, safe DOM creation is
quasi-literals, which I believe we should definitely also do. In those
cases, you'd have something like:
var myDom = html'foo';

The browser would provide a built-in html function that returns a DOM and
uses the browser's html parser. These are not strings though, so you can't
use the response from an XHR here.

On Mon, Nov 7, 2011 at 8:36 PM, Jonas Sicking  wrote:

> On Mon, Nov 7, 2011 at 8:23 PM, Ryan Seddon  wrote:
> > On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai  wrote:
> >>
> >> I don't really follow. Script won't execute until you append the
> fragment
> >> to the DOM, at which point the fragment itself doesn't go in the DOM,
> just
> >> it's children. So, I'm not really sure what sandboxing on fragments
> would
> >> do.
> >
> > If I was ajaxing in potentially hostile content that had malicious script
> > tags in it it would be ideal to "sandbox" the content so the HTML parser
> in
> > the browser would strip the content for me.
> >
> > xhr.responseText = " > src="//malicious.site/cookieStealer.js">content";
> >
> > var frag =  document.createDocumentFragment();
> >
> > frag.sandbox = "";
> > frag.innerHTML = xhr.responseText; // it's sandboxed so the script(s)
> will
> > be stripped by the parser.
> >
> > document.body.appendChild(frag);
> >
> > The following article demonstrates the same concept using an iframe with
> the
> > sandbox attribute set[1]. This to me would also make sense to be
> extended to
> > fragments.
> >
> > [1]
> >
> http://community.jboss.org/people/wesleyhales/blog/2011/08/28/fixing-ajax-on-mobile-devices
>
> I do think we should add something like this, however I think we
> should have a more explicit syntax for it. There's an old thread with
> subject "innerStaticHTML" in the WHATWG list which discusses this
> topic and various possible syntaxes.
>
> Note that inserting a untrusted piece of HTML into your document is
> interesting not just when dealing with document fragments. Both
> div.innerHTML as well as div.insertAdjecentHTML(...) seems like they
> could use "safe" variants.
>
> In short, I think a separate thread is needed for this :)
>
> / Jonas
>

[Bug 14735] New: [IndexedDB] Add multientry attribute to IDBIndex

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14735

   Summary: [IndexedDB] Add multientry attribute to IDBIndex
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jsb...@chromium.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


IDBIndex (and IDBIndexSync) should expose a readonly boolean "multientry"
attribute reflecting the multientry flag of the index

This is already present for the unique flag

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Sanatising HTML content through sandboxing

[Ryan Seddon]

Right now there is no simple way to sanitise HTML content by stripping it
of any potentially malicious HTML such as scripts etc.

In the "innerHTML in DocumentFragment" thread I suggested following the
sandbox attribute approach that can be applied to iframes. I've moved this
out into its own thread, as Jonas suggested, so as not to dilute the
innerHTML discussion.

There was mention of a suggested API called *innerStaticHTML* as a
potential solution to this, I personally would prefer to reuse the sandbox
approach that the iframes use.

e.g.

xhr.responseText = "contentM/h1>";

var div = document.createElement("div");

div.sandbox = ""; // Static content only
div.innerHTML = xhr.responseText;

document.body.appendChild(div);

This could also apply to a documentFragment and any other applicable DOM
API's, being able to let the HTML parser do what it does best would make
sense.

The advantage of this over a new API is that it would also allow the use of
the space separated tokens to white list certain things within the HTML
being parsed into the document and open it to future extension.

-Ryan

Re: innerHTML in DocumentFragment

[Daniel Cheng]

The clipboard events  spec has some
text about HTML sanitization. It might be good to make sure any work in
this area is shared.

Daniel

On Tue, Nov 8, 2011 at 17:10, Ojan Vafai  wrote:

> Providing concise, easy and XSS safe ways to generate a DOM is certainly
> something we have to solve. I don't think sandbox is the best way to
> achieve this. Specifically, I don't believe sandbox on iframes actually
> strips the script elements, does it? It just doesn't execute them.
>
> If we want to continue down the string->DOM approach, then I agree with
> Jonas, we need to define an algorithm for safe innerHTML and use it in all
> the places where we can currently set HTML. I'm open to supporting this
> use-case because the XHR pattern is so common.
>
> The other solution being proposed for easy, safe DOM creation is
> quasi-literals, which I believe we should definitely also do. In those
> cases, you'd have something like:
> var myDom = html'foo';
>
> The browser would provide a built-in html function that returns a DOM and
> uses the browser's html parser. These are not strings though, so you can't
> use the response from an XHR here.
>
> On Mon, Nov 7, 2011 at 8:36 PM, Jonas Sicking  wrote:
>
>> On Mon, Nov 7, 2011 at 8:23 PM, Ryan Seddon 
>> wrote:
>> > On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai  wrote:
>> >>
>> >> I don't really follow. Script won't execute until you append the
>> fragment
>> >> to the DOM, at which point the fragment itself doesn't go in the DOM,
>> just
>> >> it's children. So, I'm not really sure what sandboxing on fragments
>> would
>> >> do.
>> >
>> > If I was ajaxing in potentially hostile content that had malicious
>> script
>> > tags in it it would be ideal to "sandbox" the content so the HTML
>> parser in
>> > the browser would strip the content for me.
>> >
>> > xhr.responseText = "> >
>> src="//malicious.site/cookieStealer.js">content";
>> >
>> > var frag =  document.createDocumentFragment();
>> >
>> > frag.sandbox = "";
>> > frag.innerHTML = xhr.responseText; // it's sandboxed so the script(s)
>> will
>> > be stripped by the parser.
>> >
>> > document.body.appendChild(frag);
>> >
>> > The following article demonstrates the same concept using an iframe
>> with the
>> > sandbox attribute set[1]. This to me would also make sense to be
>> extended to
>> > fragments.
>> >
>> > [1]
>> >
>> http://community.jboss.org/people/wesleyhales/blog/2011/08/28/fixing-ajax-on-mobile-devices
>>
>> I do think we should add something like this, however I think we
>> should have a more explicit syntax for it. There's an old thread with
>> subject "innerStaticHTML" in the WHATWG list which discusses this
>> topic and various possible syntaxes.
>>
>> Note that inserting a untrusted piece of HTML into your document is
>> interesting not just when dealing with document fragments. Both
>> div.innerHTML as well as div.insertAdjecentHTML(...) seems like they
>> could use "safe" variants.
>>
>> In short, I think a separate thread is needed for this :)
>>
>> / Jonas
>>
>
>

Re: [indexeddb] Implicit Transaction Request associated with failed transactions

[David Grogan]

On Tue, Nov 8, 2011 at 4:54 PM, Israel Hilerio wrote:

> On Tuesday, November 08, 2011 2:09 PM, David Grogan wrote:
> >On Wed, Oct 26, 2011 at 4:36 PM, Israel Hilerio 
> wrote:
> >>On Friday, October 14, 2011 2:33 PM, Jonas Sicking wrote:
> >>> > The firing of error events on the transaction should only be of two
> types:
> >>> propagation error events or transaction error events.
> >>> >
> >>> > This should allow devs the ability to handle data error objects
> inside their
> >>> IDBRequest.onerror handler and transaction commit error on their
> >>> IDBTransaction.onerror handler.  The only difference is that
> QuotaError and
> >>> TimeoutError would wouldn't be cancellable and will always bubble.
> >>>
> >>> Not quite sure what you mean by "propagation error events". Do you mean
> >>> events that are fired on a request, but where the transaction.onerror
> handler
> >>> is called during the event's bubble phase?
> >>>
> >>> If so I think this sounds good. However there's still the matter of
> defining
> >>> when a "transaction error event" should be fired.
> >>> Transactions currently fail to commit in at least the following
> >>> circumstances:
>
> >>Yes, by "propagation error events" I meant events that are fired on a
> request, but where the transaction.onerror handler is called during the
> event's bubble phase.
>
> >>> A) When transaction.abort() is explicitly called
> >>> B) When a .put or .add request fails due to a 'unique' constraint
> violation in an
> >>> index, and the result "error" event *isn't* canceled using
> >>> event.preventDefault()
> >>> C) When an exception is thrown during a event handler for a "error"
> event
> >>> D) When an exception is thrown during a event handler for a "success"
> event
> >>> E) When a index is created with a 'unique' constraint on an
> objectStore which
> >>> already has data which violates the constraint.
> >>> F) When a request fails due to database error (for example IO error)
> and the
> >>> resulting "error" event *isn't* canceled using
> >>> event.preventDefault()
> >>> G) When a transaction fails to commit due to a quota error
> >>> H) When a transaction fails to commit due to a IO error
> >>> I) When a transaction fails to commit due to a timeout error
> >>
> >>Great list :-)
> >>
> >>>
> >>> I've probably missed some places too.
> >>>
> >>> In which of these occasions do you think we should fire an "error"
> >>> event on the transaction before firing the "abort" event? And note
> that in
> >>> *all* of the above cases we will fire a "abort" event on the
> transaction.
> >>>
> >>> >From the discussion so far, it sounds like you *don't* want to fire an
> >>> "error" event for at least for situation A, which makes sense to me.
> >>>
> >>> Whatever situations we decide to fire an "error" event in, I'd like
> there to be
> >>> some sort of consistency. I'd also like to start by looking at use
> cases rather
> >>> than just at random pick situations that seem good.
> >>>
> >>> So, if anyone think we should fire error events targeted at the
> transaction in
> >>> any of the above situations, please state use cases, and which of the
> above
> >>> situations you think should generate an error event.
> >>>
> >>> Additionally, I'm not sure that we need to worry about I) above. I)
> only
> >>> happens when there are timeouts specified, which only is possible in
> the
> >>> synchronous API. But in the synchronous API we never fire any events,
> but
> >>> simply let IDBDatabaseSync.transaction throw an exception.
> >>>
> >>> / Jonas
> >>
> >>I believe that error events on the transaction should be fired for
> individual request related issues:
> >>B) When a .put or .add request fails due to a 'unique' constraint
> violation in an index, and the result "error" event *isn't* canceled using
> event.preventDefault()
> >>C) When an exception is thrown during an event handler for a "error"
> event
> >>D) When an exception is thrown during an event handler for a "success"
> event
> >>E) When an index is created with a 'unique' constraint on an objectStore
> which already has data which violates the constraint.
> >>F) When a request fails due to database error (for example IO error) and
> the resulting "error" event *isn't* canceled using event.preventDefault()
> >>
> >>However, I don't believe we should fire error events on the transaction
> for transaction related issues:
> >>G) When a transaction fails to commit due to a quota error
> >>H) When a transaction fails to commit due to a IO error
> >>
> >>My fundamental argument is that these are two different types of error
> cases, request and fatal errors.  I believe that developers want to handle
> request errors because
> >>they can do something about them.  These request errors are reflections
> of problems related to individual requests (i.e. add, put, delete record
> issues or schema related >>issues).  Preventing their default behavior will
> allow devs to add 99 records into the db but ignore the last 1 record that

[Bug 12510] Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12510

Glenn Adams  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |

--- Comment #12 from Glenn Adams  2011-11-09 02:12:32 UTC ---
(In reply to comment #11)
> I have no intention of adding cross-spec cross-references to the WebSocket
> spec. If someone is interested in providing patches to the spec splitter to do
> this, please contact me directly.

How you create your spec products for use in the W3C is your business, not
mine. I am asking that each reference or use of a "fundamental concept" as
described in 2.1:

"Many fundamental concepts from HTML are used by this specification. [HTML]"

be made explicit by using a link (anchor) to the relevant defining
clause/section in [HTML].

For example, the following phrases should link to the defining sections of
[HTML]:

1. "queue a task" => http://dev.w3.org/html5/spec/Overview.html#queue-a-task
2. "dispatch [an] event" =>
http://dev.w3.org/html5/spec/Overview.html#concept-event-dispatch
3. "task source" => http://dev.w3.org/html5/spec/Overview.html#task-source
4. "event loop" => http://dev.w3.org/html5/spec/Overview.html#event-loop
5. "task" (otherwise unqualified) =>
http://dev.w3.org/html5/spec/Overview.html#concept-task

If these (and any other "concepts from HTML" I don't list above) are used
normatively, then it should be made clear that the HTML definition applies (and
not some other random implied definition). I don't care if it is done by links
at each usage, or by listing the concepts in one place (e.g., under
dependencies) and placing the links there.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

RE: [indexeddb] Implicit Transaction Request associated with failed transactions

[Israel Hilerio]

Yes! By "surface" I meant "bubble", in other words the request errors will 
continue to bubble up to the onerror handler of the transaction but the fatal 
errors won't ever be accessible via the onerror handler of the transaction.
Israel

On Tuesday, November 08, 2011 5:35 PM, David Grogan wrote:
On Tue, Nov 8, 2011 at 4:54 PM, Israel Hilerio 
mailto:isra...@microsoft.com>> wrote:
On Tuesday, November 08, 2011 2:09 PM, David Grogan wrote:
>On Wed, Oct 26, 2011 at 4:36 PM, Israel Hilerio 
>mailto:isra...@microsoft.com>> wrote:
>>On Friday, October 14, 2011 2:33 PM, Jonas Sicking wrote:
>>> > The firing of error events on the transaction should only be of two types:
>>> propagation error events or transaction error events.
>>> >
>>> > This should allow devs the ability to handle data error objects inside 
>>> > their
>>> IDBRequest.onerror handler and transaction commit error on their
>>> IDBTransaction.onerror handler.  The only difference is that QuotaError and
>>> TimeoutError would wouldn't be cancellable and will always bubble.
>>>
>>> Not quite sure what you mean by "propagation error events". Do you mean
>>> events that are fired on a request, but where the transaction.onerror 
>>> handler
>>> is called during the event's bubble phase?
>>>
>>> If so I think this sounds good. However there's still the matter of defining
>>> when a "transaction error event" should be fired.
>>> Transactions currently fail to commit in at least the following
>>> circumstances:

>>Yes, by "propagation error events" I meant events that are fired on a 
>>request, but where the transaction.onerror handler is called during the 
>>event's bubble phase.

>>> A) When transaction.abort() is explicitly called
>>> B) When a .put or .add request fails due to a 'unique' constraint violation 
>>> in an
>>> index, and the result "error" event *isn't* canceled using
>>> event.preventDefault()
>>> C) When an exception is thrown during a event handler for a "error" event
>>> D) When an exception is thrown during a event handler for a "success" event
>>> E) When a index is created with a 'unique' constraint on an objectStore 
>>> which
>>> already has data which violates the constraint.
>>> F) When a request fails due to database error (for example IO error) and the
>>> resulting "error" event *isn't* canceled using
>>> event.preventDefault()
>>> G) When a transaction fails to commit due to a quota error
>>> H) When a transaction fails to commit due to a IO error
>>> I) When a transaction fails to commit due to a timeout error
>>
>>Great list :-)
>>
>>>
>>> I've probably missed some places too.
>>>
>>> In which of these occasions do you think we should fire an "error"
>>> event on the transaction before firing the "abort" event? And note that in
>>> *all* of the above cases we will fire a "abort" event on the transaction.
>>>
>>> >From the discussion so far, it sounds like you *don't* want to fire an
>>> "error" event for at least for situation A, which makes sense to me.
>>>
>>> Whatever situations we decide to fire an "error" event in, I'd like there 
>>> to be
>>> some sort of consistency. I'd also like to start by looking at use cases 
>>> rather
>>> than just at random pick situations that seem good.
>>>
>>> So, if anyone think we should fire error events targeted at the transaction 
>>> in
>>> any of the above situations, please state use cases, and which of the above
>>> situations you think should generate an error event.
>>>
>>> Additionally, I'm not sure that we need to worry about I) above. I) only
>>> happens when there are timeouts specified, which only is possible in the
>>> synchronous API. But in the synchronous API we never fire any events, but
>>> simply let IDBDatabaseSync.transaction throw an exception.
>>>
>>> / Jonas
>>
>>I believe that error events on the transaction should be fired for individual 
>>request related issues:
>>B) When a .put or .add request fails due to a 'unique' constraint violation 
>>in an index, and the result "error" event *isn't* canceled using 
>>event.preventDefault()
>>C) When an exception is thrown during an event handler for a "error" event
>>D) When an exception is thrown during an event handler for a "success" event
>>E) When an index is created with a 'unique' constraint on an objectStore 
>>which already has data which violates the constraint.
>>F) When a request fails due to database error (for example IO error) and the 
>>resulting "error" event *isn't* canceled using event.preventDefault()
>>
>>However, I don't believe we should fire error events on the transaction for 
>>transaction related issues:
>>G) When a transaction fails to commit due to a quota error
>>H) When a transaction fails to commit due to a IO error
>>
>>My fundamental argument is that these are two different types of error cases, 
>>request and fatal errors.  I believe that developers want to handle request 
>>errors because
>>they can do something about them.  These request errors are reflections of 
>>problems re

Re: Who is the audience?

[Arthur Barstow]

On 11/8/11 8:50 AM, ext Robin Berjon wrote:

On Nov 7, 2011, at 20:52 , Dimitri Glazkov wrote:

One theme that was easy to observe at the conference was the pondering
around who those mysterious consumers of what we do are, how to reach
them, and how to reason about them. I heard people speak of Web
Authors and Web Developers and making various distinctions about them.

I heard some folks of arguing that this audience of ours prefers
markup over scripts, and when faced with concrete examples of the
opposite, retort that those are just some script library folk, not the
majority.

It made me think that perhaps pure democracy as means of assessing the
needs of such a vast, enormously uneven (in terms of skill and
influence) audience is severely flawed. And moreover, it's likely
responsible for the sad situation we're in today, where markup is a
rare craft, cutting-edge Web apps are nothing but bootstraps for
loading script, and the actual Web influencers (like jQuery engineers)
actually have to send designated ambassadors into our realm to try and
reason with us.


(If you think some specific spec(s) is especially problematic, I'd like 
to know which one(s).)



The problem of getting input from our audience is a long-standing one. There 
are clearly way too many web developers out there for us to ask them all, which 
means getting feedback requires mediation. In turn, mediation has all sorts of 
problems, including the usual clique and confirmation biases that can kick in 
despite the best of intentions.


We could also create a new list (e.g. public-webapps-devs) for Q&A type 
discussions .



During the "jQuery Standards Group" breakout, we agreed to kick off the Script Library 
Community Group (http://www.w3.org/community/scriptlib/) which could serve as a venue for 
developers to come provide their ideas and feedback without having to follow a fire hose mailing 
list such as this one or being crushed to bits by untactful folks. I think it would also make sense 
for spec writers to send "What do you prefer?" questions there.

There aren't many people on the group yet since it's so fresh, but I think that 
we can solve that rather quickly. Spreading the word as to its existence is 
certainly recommended :)


I agree Education & Outreach type groups may be helpful so thanks for 
mentioning this Robin.


We may create tutorial type information (e.g. separate Primer docs) for 
any of our specs . All we need are volunteers ;-).


-AB

Re: Sanatising HTML content through sandboxing

[Jonas Sicking]

Given that this type of sandbox would work very differently from the
iframe sandbox, I think reusing the same attribute name would be
confusing.

Additionally, what's the behavior if you remove the attribute? What if
you do elem.innerHTML += "foo" on the element after having removed the
sandbox? Or on an elements parent?

Or what happens if you do foo.innerHTML = bar.innerHTML where a parent
of bar has sandbox set?

When sanitizing, I strongly feel that we should simply remove all
content that could execute script as to ensure that it doesn't leak
somewhere else when markup is copied. Trying to ensure that it never
executes, while still allowing it to exist, is too high risk IMO.

/ Jonas

On Tue, Nov 8, 2011 at 5:21 PM, Ryan Seddon  wrote:
> Right now there is no simple way to sanitise HTML content by stripping it of
> any potentially malicious HTML such as scripts etc.
>
> In the "innerHTML in DocumentFragment" thread I suggested following the
> sandbox attribute approach that can be applied to iframes. I've moved this
> out into its own thread, as Jonas suggested, so as not to dilute the
> innerHTML discussion.
>
> There was mention of a suggested API called innerStaticHTML as a potential
> solution to this, I personally would prefer to reuse the sandbox approach
> that the iframes use.
>
> e.g.
>
> xhr.responseText = " src='malicious.js'>contentM/h1>";
>
> var div = document.createElement("div");
>
> div.sandbox = ""; // Static content only
> div.innerHTML = xhr.responseText;
>
> document.body.appendChild(div);
>
> This could also apply to a documentFragment and any other applicable DOM
> API's, being able to let the HTML parser do what it does best would make
> sense.
>
> The advantage of this over a new API is that it would also allow the use of
> the space separated tokens to white list certain things within the HTML
> being parsed into the document and open it to future extension.
>
> -Ryan
>

Re: Sanatising HTML content through sandboxing

[Adam Barth]

Also, a div doesn't represent a security boundary.  It's difficult to
sandbox something unless you have a security boundary around it.
IMHO, an easy way to solve this problem is to just exposes an
HTMLParser object, analogous to DOMParser, which folks can use to
safely parse HTML, e.g., from XMLHttpRequest.

Adam


On Tue, Nov 8, 2011 at 11:28 PM, Jonas Sicking  wrote:
> Given that this type of sandbox would work very differently from the
> iframe sandbox, I think reusing the same attribute name would be
> confusing.
>
> Additionally, what's the behavior if you remove the attribute? What if
> you do elem.innerHTML += "foo" on the element after having removed the
> sandbox? Or on an elements parent?
>
> Or what happens if you do foo.innerHTML = bar.innerHTML where a parent
> of bar has sandbox set?
>
> When sanitizing, I strongly feel that we should simply remove all
> content that could execute script as to ensure that it doesn't leak
> somewhere else when markup is copied. Trying to ensure that it never
> executes, while still allowing it to exist, is too high risk IMO.
>
> / Jonas
>
> On Tue, Nov 8, 2011 at 5:21 PM, Ryan Seddon  wrote:
>> Right now there is no simple way to sanitise HTML content by stripping it of
>> any potentially malicious HTML such as scripts etc.
>>
>> In the "innerHTML in DocumentFragment" thread I suggested following the
>> sandbox attribute approach that can be applied to iframes. I've moved this
>> out into its own thread, as Jonas suggested, so as not to dilute the
>> innerHTML discussion.
>>
>> There was mention of a suggested API called innerStaticHTML as a potential
>> solution to this, I personally would prefer to reuse the sandbox approach
>> that the iframes use.
>>
>> e.g.
>>
>> xhr.responseText = "> src='malicious.js'>contentM/h1>";
>>
>> var div = document.createElement("div");
>>
>> div.sandbox = ""; // Static content only
>> div.innerHTML = xhr.responseText;
>>
>> document.body.appendChild(div);
>>
>> This could also apply to a documentFragment and any other applicable DOM
>> API's, being able to let the HTML parser do what it does best would make
>> sense.
>>
>> The advantage of this over a new API is that it would also allow the use of
>> the space separated tokens to white list certain things within the HTML
>> being parsed into the document and open it to future extension.
>>
>> -Ryan
>>
>
>