Re: Starting work on Indexed DB v2 spec - feedback wanted

[Kyle Huey]

On Thu, Apr 17, 2014 at 5:16 PM, Ben Kelly  wrote:
> On 4/17/2014 5:41 PM, Kyle Huey wrote:
>>
>> On Thu, Apr 17, 2014 at 2:10 PM, Dale Harvey  wrote:
>>>
>>> No features that slow it down, as with Tim I also implemented the same
>>> thing
>>> in node.js and see much better perfomance against straight leveldb, with
>>> websql still being ~5x faster than idb
>>
>>
>> Do you have benchmarks for this?  When we've profiled IndexedDB
>> performance for Gaia apps in the past the issue is invariably that the
>> main thread event loop is busy and IndexedDB's responses have to go to
>> the end of a long line.
>
>
> I would hazard a guess that some of SQL's more feature rich constructs allow
> you to do more in a single API call.  This could mean you need to hit the
> event loop less often to accomplish the same amount of work in many cases.
>
> Just a theory.
>
> Ben

Yes, that's entirely possible.  Which is why I would like to see a testcase ;-)

- Kyle

Re: Starting work on Indexed DB v2 spec - feedback wanted

[James Halliday]

Things I think are important:
* asynchronous get/put
* iterators on sorted keys (so we can implement efficient indexes and
nice streaming abstractions)
* batch put/del - not sure if it already has this, but these are super
necessary for implementing custom indexing schemes
* binary keys - combined with sorted key iterators, with binary keys
you can do some really interesting things in userspace with sorting
like typewise: https://www.npmjs.org/package/typewise
* binary values - store bulk data without the overhead of string conversion
* mutation observers - a simple event-based API that emits objects
with { type: 'put|del|batch', key: '...', value: '...' } would do fine
here, like leveldb. This might be a good place for modules to provide
hooks for indexing similar to `ev.preventDefault()` for dom elements.
After preventing the default mutation, the indexing modules could do
batch put/del into the database on their own and then have another
function to indicate back to the caller that triggered the mutation in
the first place that the operation failed or succeeded. Here is a
related module to look at for API inspiration:
https://github.com/dominictarr/level-hooks

Things I don't particularly care about:
* promises
* batched gets
* existence checks
* transactions - these seem like complications

These things should NOT be implemented:
* full text search - This is a very specific kind of index. Just give
us the primitives to implement general-purpose indexes instead.
* IDBKeyRange boolean operators - give userspace enough primitives to
implement indexing ourselves instead of baking in a DSL

A good starting point as Raynos has already mentioned is the leveldown
api, which has proved sufficient to sustain a huge ecosystem of
packages that implement features of traditional databases in a highly
modular way: https://github.com/rvagg/node-leveldown

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Ben Kelly]

On 4/17/2014 5:41 PM, Kyle Huey wrote:

On Thu, Apr 17, 2014 at 2:10 PM, Dale Harvey  wrote:

No features that slow it down, as with Tim I also implemented the same thing
in node.js and see much better perfomance against straight leveldb, with
websql still being ~5x faster than idb


Do you have benchmarks for this?  When we've profiled IndexedDB
performance for Gaia apps in the past the issue is invariably that the
main thread event loop is busy and IndexedDB's responses have to go to
the end of a long line.


I would hazard a guess that some of SQL's more feature rich constructs 
allow you to do more in a single API call.  This could mean you need to 
hit the event loop less often to accomplish the same amount of work in 
many cases.


Just a theory.

Ben

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Jake Verbaten]

The level / node.js community already build a prototype on top of IDB (
https://github.com/maxogden/level.js )

It supports:

 open(name)
 get(key) => Uint8Array
 del(key)
 put(key, Uint8Array)
 batch(Array<{ type: 'put' or 'del', key: String, value: Uint8Array>})
 iterator({ start: String, key: String, order: 'asc' or 'desc' }) => {
   next() => Uint8Array or null,
   end()
 }
 close()
 destroy() // cleans up the databases

So it supports async get / del / put + write btaches + iterators.

I dont think it supports snapshots or custom comparators.

It does support multiple instances, i.e. you can open multiple named
databases backed by a file location (which gets mapped to a unique idb db
name).

The values can just be String or Uint8Array and the same for the keys.

The level.js prototype is callback flavored but converting it to promises
would be trivial.

There is value in supporting batch & iterators as those are the primitives
that allow people to build their own transactions and indexes.


On Thu, Apr 17, 2014 at 1:56 PM, Joshua Bell  wrote:

> On Thu, Apr 17, 2014 at 1:22 PM, Tim Caswell  wrote:
>
>> Personally, the main thing I want to see is expose simpler and lower
>> level APIs.  For my uses (backend to git server), the leveldb API is plenty
>> powerful.  Most of the time I'm using IndexedDB, I'm getting frustrated
>> because it's way more complex than I need and gets in the way and slows
>> things down.
>>
>> Would it make sense to standardize on a simpler set of APIs similar to
>> what levelDB offers and expose that in addition to what indexedDB currently
>> exposes?  Or would this make sense as a new API apart from IDB?
>>
>
> That sounds like a separate storage system to me, although you could
> imagine it shares some primitives with Indexed DB (e.g. keys/ordering).
>
> How much of leveldb's API you consider part of the minimum set - write
> batches? iterators? snapshots? custom comparators? multiple instances per
> application? And are IDB-style keys / serialized script values appropriate,
> or is that extra overhead over e.g. just strings?
>
> You may want to try prototyping this on top of Indexed DB as a library,
> and see what others think. It'd basically just be hiding most of the IDB
> API (versions, transactions, stores, indexes) behind functions that return
> Promises.
>
>
>> As a JS developer, I'd much rather see fast, simple, yet powerful
>> primitives over application-level databases with indexes and transactions
>> baked in.  Chrome implements IDB on top of LevelDB, so it has just enough
>> primitives to make more complex systems.
>>
>> But for applications like mine that use immutable storage and hashes for
>> all lookups don't need or want the advanced features added on top.  IDB is
>> a serious performance bottleneck in my apps and when using LevelDB in
>> node.js, my same logic runs a *lot* faster and using a lot less code.
>>
>> -Tim Caswell
>>
>>
>> On Wed, Apr 16, 2014 at 1:49 PM, Joshua Bell  wrote:
>>
>>> At the April 2014 WebApps WG F2F [1] there was general agreement that
>>> moving forward with an Indexed Database "v2" spec was a good idea. Ali
>>> Alabbas (Microsoft) has volunteered to co-edit the spec with me.
>>> Maintaining compatibility is the highest priority; this will not break the
>>> existing API.
>>>
>>> We've been tracking additional features for quite some time now, both on
>>> the wiki [2] and bug tracker [3]. Several are very straightforward
>>> (continuePrimaryKey, batch gets, binary keys, ...) and have already been
>>> implemented in some user agents, and it will be helpful to document these.
>>> Others proposals (URLs, Promises, full text search, ...) are much more
>>> complex and will require additional implementation feedback; we plan to add
>>> features to the v2 spec based on implementer acceptance.
>>>
>>> This is an informal call for feedback to implementers on what is missing
>>> from v1:
>>>
>>> * What features and functionality do you see as important to include?
>>> * How would you prioritize the features?
>>>
>>> If there's anything you think is missing from the wiki [2], or want to
>>> comment on the importance of a particular feature, please call it out -
>>> replying here is great. This will help implementers decide what work to
>>> prioritize, which will drive the spec work. We'd also like to keep the v2
>>> cycle shorter than the v1 cycle was, so timely feedback is appreciated -
>>> there's always room for a "v3".
>>>
>>> [1] http://www.w3.org/2014/04/10-webapps-minutes.html
>>> [2] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
>>> [3]
>>> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=RESOLVED&component=Indexed%20Database%20API&list_id=34841&product=WebAppsWG&query_format=advanced&resolution=LATER
>>>
>>> PS: Big thanks to Zhiqiang Zhang for his Indexed DB implementation
>>> report, also presented at the F2F.
>>>
>>
>>
>

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Erik Bryn]

In my mind, promisifying the IndexedDB API would be the highest value thing
to end users.

After using a very early version of localForage (
https://github.com/mozilla/localForage), I started toying with a lower
level, promise-based, API wrapper with my EasyIndexedDB library. Here's
some example usage:
https://github.com/ebryn/EasyIndexedDB/blob/master/test/basics_test.js#L42

I'd be happy to help provide continual feedback from a framework developer
(Ember.js) & end users perspective.

- Erik


On Wed, Apr 16, 2014 at 11:49 AM, Joshua Bell  wrote:

> At the April 2014 WebApps WG F2F [1] there was general agreement that
> moving forward with an Indexed Database "v2" spec was a good idea. Ali
> Alabbas (Microsoft) has volunteered to co-edit the spec with me.
> Maintaining compatibility is the highest priority; this will not break the
> existing API.
>
> We've been tracking additional features for quite some time now, both on
> the wiki [2] and bug tracker [3]. Several are very straightforward
> (continuePrimaryKey, batch gets, binary keys, ...) and have already been
> implemented in some user agents, and it will be helpful to document these.
> Others proposals (URLs, Promises, full text search, ...) are much more
> complex and will require additional implementation feedback; we plan to add
> features to the v2 spec based on implementer acceptance.
>
> This is an informal call for feedback to implementers on what is missing
> from v1:
>
> * What features and functionality do you see as important to include?
> * How would you prioritize the features?
>
> If there's anything you think is missing from the wiki [2], or want to
> comment on the importance of a particular feature, please call it out -
> replying here is great. This will help implementers decide what work to
> prioritize, which will drive the spec work. We'd also like to keep the v2
> cycle shorter than the v1 cycle was, so timely feedback is appreciated -
> there's always room for a "v3".
>
> [1] http://www.w3.org/2014/04/10-webapps-minutes.html
> [2] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
> [3]
> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=RESOLVED&component=Indexed%20Database%20API&list_id=34841&product=WebAppsWG&query_format=advanced&resolution=LATER
>
> PS: Big thanks to Zhiqiang Zhang for his Indexed DB implementation report,
> also presented at the F2F.
>

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Tim Caswell]

For my personal use case, I don't need much at all.  I need the ability to
store binary data by key and retrieve binary data by key.  It would be nice
if there was a quick existence check to see if a hash is already in the db
since I'm using content-addressable structures.  But again, only for
performance reasons.  If that wasn't there, I would just do a read and
ignore the body.

For the mutable half of a git db, I need basic string key with string value
and some iterating on subsets.  For example, I want to find all refs that
start with "refs/heads/" to get the list of branches on a repo.  But this
metadata is tiny in comparison to everything else.  A large git db may have
hundreds of megabytes of git objects and less than 1000 refs for all the
branches, tags, pull-requests, etc.  The value of these refs is a string
usually 41 bytes long.

If the db didn't provide sorted and iteratable keys, I would just store all
the metadata in a single object and replace it whenever I needed to change
any part of it.  Updates to this data is infrequent  in my case.

Ideally I'd have two databases.  One for immutable binary values with
fixed-length 20-byte binary (or 40 byte string) keys.  This wouldn't need
to be atomic at all.
It would have:

  get(hash) => binary
  set(hash, binary)
  has(hash) => boolean
  del(hash)

And one for the mutable metadata where the keys are strings and the values
are strings.

  get(key) => string
  set(key, string)
  getRange(prefix) => object of key/value pairs that match the prefix
  del(key)

This would all be async using ES6 promises or node-style callbacks or
whatever.

The reason I suggested LevelDB is because it's a nice medium between my
minimal needs and what's needed to implement a more complex database in
pure JS.


On Thu, Apr 17, 2014 at 4:04 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

>  *From:* Joshua Bell 
>
>> How much of leveldb's API you consider part of the minimum set -
> write batches? iterators? snapshots? custom comparators? multiple instances
> per application? And are IDB-style keys / serialized script values
> appropriate, or is that extra overhead over e.g. just strings?
>
> This is my question for Tim as well. My personal hope has always been for
> something along the lines of async local storage [1], but that omits a lot
> of LevelDB's API and complexity, so presumably it goes too far for LevelDB
> proponents.
>
> [1]: https://github.com/slightlyoff/async-local-storage
>

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Kyle Huey]

On Thu, Apr 17, 2014 at 2:10 PM, Dale Harvey  wrote:
> No features that slow it down, as with Tim I also implemented the same thing
> in node.js and see much better perfomance against straight leveldb, with
> websql still being ~5x faster than idb

Do you have benchmarks for this?  When we've profiled IndexedDB
performance for Gaia apps in the past the issue is invariably that the
main thread event loop is busy and IndexedDB's responses have to go to
the end of a long line.

- Kyle

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Dale Harvey]

My IndexedDB wishlist:

Ability to enumerate databases, I dont particularly want or care about the
transactional integrity of the api, if someone deletes a database while I
am in a callback in which I think it exists, meh

Change events / Observers, right now I have to fake it via localstorage

A transactional model that isnt tied to the event loop, sometimes I want to
do async things inside the transaction like converting to an ArrayBuffer
etc, I would like to open with an option to have the transaction stay open
till its explicitly closed

No features that slow it down, as with Tim I also implemented the same
thing in node.js and see much better perfomance against straight leveldb,
with websql still being ~5x faster than idb

I dont have any concrete suggestions, but making the transactional states
more visible would help, I have seen pretty much everyone errantly use
.put().onsuccess(function() { yay do stuff, to either lose data by assuming
the write is completed or get in a confusing state trying to open new
transactions. (see step 3 -
http://www.html5rocks.com/en/tutorials/indexeddb/todo/)

I think its also worth (and fairly trivial) to implement sugar syntax for a
key value storage like https://github.com/mozilla/localForage, as a large
amount of usage I have seen just wants to store some simple data and not
deal with transactions, object stores and schema migrations

Cheers
Dale



On 17 April 2014 21:22, Tim Caswell  wrote:

> Personally, the main thing I want to see is expose simpler and lower level
> APIs.  For my uses (backend to git server), the leveldb API is plenty
> powerful.  Most of the time I'm using IndexedDB, I'm getting frustrated
> because it's way more complex than I need and gets in the way and slows
> things down.
>
> Would it make sense to standardize on a simpler set of APIs similar to
> what levelDB offers and expose that in addition to what indexedDB currently
> exposes?  Or would this make sense as a new API apart from IDB?
>
> As a JS developer, I'd much rather see fast, simple, yet powerful
> primitives over application-level databases with indexes and transactions
> baked in.  Chrome implements IDB on top of LevelDB, so it has just enough
> primitives to make more complex systems.
>
> But for applications like mine that use immutable storage and hashes for
> all lookups don't need or want the advanced features added on top.  IDB is
> a serious performance bottleneck in my apps and when using LevelDB in
> node.js, my same logic runs a *lot* faster and using a lot less code.
>
> -Tim Caswell
>
>
> On Wed, Apr 16, 2014 at 1:49 PM, Joshua Bell  wrote:
>
>> At the April 2014 WebApps WG F2F [1] there was general agreement that
>> moving forward with an Indexed Database "v2" spec was a good idea. Ali
>> Alabbas (Microsoft) has volunteered to co-edit the spec with me.
>> Maintaining compatibility is the highest priority; this will not break the
>> existing API.
>>
>> We've been tracking additional features for quite some time now, both on
>> the wiki [2] and bug tracker [3]. Several are very straightforward
>> (continuePrimaryKey, batch gets, binary keys, ...) and have already been
>> implemented in some user agents, and it will be helpful to document these.
>> Others proposals (URLs, Promises, full text search, ...) are much more
>> complex and will require additional implementation feedback; we plan to add
>> features to the v2 spec based on implementer acceptance.
>>
>> This is an informal call for feedback to implementers on what is missing
>> from v1:
>>
>> * What features and functionality do you see as important to include?
>> * How would you prioritize the features?
>>
>> If there's anything you think is missing from the wiki [2], or want to
>> comment on the importance of a particular feature, please call it out -
>> replying here is great. This will help implementers decide what work to
>> prioritize, which will drive the spec work. We'd also like to keep the v2
>> cycle shorter than the v1 cycle was, so timely feedback is appreciated -
>> there's always room for a "v3".
>>
>> [1] http://www.w3.org/2014/04/10-webapps-minutes.html
>> [2] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
>> [3]
>> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=RESOLVED&component=Indexed%20Database%20API&list_id=34841&product=WebAppsWG&query_format=advanced&resolution=LATER
>>
>> PS: Big thanks to Zhiqiang Zhang for his Indexed DB implementation
>> report, also presented at the F2F.
>>
>
>

RE: Starting work on Indexed DB v2 spec - feedback wanted

[Domenic Denicola]

From: Joshua Bell 

> How much of leveldb's API you consider part of the minimum set - write 
> batches? iterators? snapshots? custom comparators? multiple instances per 
> application? And are IDB-style keys / serialized script values appropriate, 
> or is that extra overhead over e.g. just strings?

This is my question for Tim as well. My personal hope has always been for 
something along the lines of async local storage [1], but that omits a lot of 
LevelDB's API and complexity, so presumably it goes too far for LevelDB 
proponents.

[1]: https://github.com/slightlyoff/async-local-storage

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Joshua Bell]

On Thu, Apr 17, 2014 at 1:22 PM, Tim Caswell  wrote:

> Personally, the main thing I want to see is expose simpler and lower level
> APIs.  For my uses (backend to git server), the leveldb API is plenty
> powerful.  Most of the time I'm using IndexedDB, I'm getting frustrated
> because it's way more complex than I need and gets in the way and slows
> things down.
>
> Would it make sense to standardize on a simpler set of APIs similar to
> what levelDB offers and expose that in addition to what indexedDB currently
> exposes?  Or would this make sense as a new API apart from IDB?
>

That sounds like a separate storage system to me, although you could
imagine it shares some primitives with Indexed DB (e.g. keys/ordering).

How much of leveldb's API you consider part of the minimum set - write
batches? iterators? snapshots? custom comparators? multiple instances per
application? And are IDB-style keys / serialized script values appropriate,
or is that extra overhead over e.g. just strings?

You may want to try prototyping this on top of Indexed DB as a library, and
see what others think. It'd basically just be hiding most of the IDB API
(versions, transactions, stores, indexes) behind functions that return
Promises.


> As a JS developer, I'd much rather see fast, simple, yet powerful
> primitives over application-level databases with indexes and transactions
> baked in.  Chrome implements IDB on top of LevelDB, so it has just enough
> primitives to make more complex systems.
>
> But for applications like mine that use immutable storage and hashes for
> all lookups don't need or want the advanced features added on top.  IDB is
> a serious performance bottleneck in my apps and when using LevelDB in
> node.js, my same logic runs a *lot* faster and using a lot less code.
>
> -Tim Caswell
>
>
> On Wed, Apr 16, 2014 at 1:49 PM, Joshua Bell  wrote:
>
>> At the April 2014 WebApps WG F2F [1] there was general agreement that
>> moving forward with an Indexed Database "v2" spec was a good idea. Ali
>> Alabbas (Microsoft) has volunteered to co-edit the spec with me.
>> Maintaining compatibility is the highest priority; this will not break the
>> existing API.
>>
>> We've been tracking additional features for quite some time now, both on
>> the wiki [2] and bug tracker [3]. Several are very straightforward
>> (continuePrimaryKey, batch gets, binary keys, ...) and have already been
>> implemented in some user agents, and it will be helpful to document these.
>> Others proposals (URLs, Promises, full text search, ...) are much more
>> complex and will require additional implementation feedback; we plan to add
>> features to the v2 spec based on implementer acceptance.
>>
>> This is an informal call for feedback to implementers on what is missing
>> from v1:
>>
>> * What features and functionality do you see as important to include?
>> * How would you prioritize the features?
>>
>> If there's anything you think is missing from the wiki [2], or want to
>> comment on the importance of a particular feature, please call it out -
>> replying here is great. This will help implementers decide what work to
>> prioritize, which will drive the spec work. We'd also like to keep the v2
>> cycle shorter than the v1 cycle was, so timely feedback is appreciated -
>> there's always room for a "v3".
>>
>> [1] http://www.w3.org/2014/04/10-webapps-minutes.html
>> [2] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
>> [3]
>> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=RESOLVED&component=Indexed%20Database%20API&list_id=34841&product=WebAppsWG&query_format=advanced&resolution=LATER
>>
>> PS: Big thanks to Zhiqiang Zhang for his Indexed DB implementation
>> report, also presented at the F2F.
>>
>
>

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Tim Caswell]

Personally, the main thing I want to see is expose simpler and lower level
APIs.  For my uses (backend to git server), the leveldb API is plenty
powerful.  Most of the time I'm using IndexedDB, I'm getting frustrated
because it's way more complex than I need and gets in the way and slows
things down.

Would it make sense to standardize on a simpler set of APIs similar to what
levelDB offers and expose that in addition to what indexedDB currently
exposes?  Or would this make sense as a new API apart from IDB?

As a JS developer, I'd much rather see fast, simple, yet powerful
primitives over application-level databases with indexes and transactions
baked in.  Chrome implements IDB on top of LevelDB, so it has just enough
primitives to make more complex systems.

But for applications like mine that use immutable storage and hashes for
all lookups don't need or want the advanced features added on top.  IDB is
a serious performance bottleneck in my apps and when using LevelDB in
node.js, my same logic runs a *lot* faster and using a lot less code.

-Tim Caswell


On Wed, Apr 16, 2014 at 1:49 PM, Joshua Bell  wrote:

> At the April 2014 WebApps WG F2F [1] there was general agreement that
> moving forward with an Indexed Database "v2" spec was a good idea. Ali
> Alabbas (Microsoft) has volunteered to co-edit the spec with me.
> Maintaining compatibility is the highest priority; this will not break the
> existing API.
>
> We've been tracking additional features for quite some time now, both on
> the wiki [2] and bug tracker [3]. Several are very straightforward
> (continuePrimaryKey, batch gets, binary keys, ...) and have already been
> implemented in some user agents, and it will be helpful to document these.
> Others proposals (URLs, Promises, full text search, ...) are much more
> complex and will require additional implementation feedback; we plan to add
> features to the v2 spec based on implementer acceptance.
>
> This is an informal call for feedback to implementers on what is missing
> from v1:
>
> * What features and functionality do you see as important to include?
> * How would you prioritize the features?
>
> If there's anything you think is missing from the wiki [2], or want to
> comment on the importance of a particular feature, please call it out -
> replying here is great. This will help implementers decide what work to
> prioritize, which will drive the spec work. We'd also like to keep the v2
> cycle shorter than the v1 cycle was, so timely feedback is appreciated -
> there's always room for a "v3".
>
> [1] http://www.w3.org/2014/04/10-webapps-minutes.html
> [2] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
> [3]
> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=RESOLVED&component=Indexed%20Database%20API&list_id=34841&product=WebAppsWG&query_format=advanced&resolution=LATER
>
> PS: Big thanks to Zhiqiang Zhang for his Indexed DB implementation report,
> also presented at the F2F.
>

Re: An error in document "http://www.w3.org/TR/widgets/"

[Marcos Caceres]

On April 17, 2014 at 12:21:06 PM, Arthur Barstow (art.bars...@nokia.com) wrote:
> On 4/17/14 12:09 PM, ext Marcos Caceres wrote:
> >
> > On April 17, 2014 at 5:46:17 AM, Wang, Peter H (peter.h.w...@intel.com) 
> > wrote:
> >> Hi all,
> >>
> >> I’ve found a small error in document http://www.w3.org/TR/widgets/. In 
> >> “7.12.4  
> Example
> >> of Usage”:
> >> 古老瓷地图
> >> Ancient Chinese Maps
> >> should be
> >> 古老中国地图
> >> Ancient Chinese Maps
> >>
> >> Thank you very much.
> > Thanks! Fixed:
> > https://github.com/w3c/packaged-webapps/commit/ae4a1d349e0550dbaad0dbac1bd05c62e942086f
> >   
>  
> Thanks to Peter for reporting this and to Marcos for updating the spec.
>  
> > It's in the living standard version:
> > http://w3c.github.io/packaged-webapps/packaging/
>  
> Marcos - it seems like this correction should be added to the errata doc
> .

I don't have CVS access anymore (hell, I don't even thing I have cvs installed 
on my computer!:)). The least painful thing would be to point the errata form 
the REC to the document on GH:

http://w3c.github.io/packaged-webapps/packaging/errata.html

I've already updated that document to reflect the recent chance. 

> I also noticed: the REC
> has a link to an ED
> that now 404s and the
> errata doc has a link to a "differences document" that now returns an error.
>  
> Cindy, Yves - would one of you please update the TR with a new link to
> the ED (that Marcos provides, perhaps the URL he gives above)?


Please point to this:
http://w3c.github.io/packaged-webapps/packaging/errata.html

[Bug 24349] [imports]: Import documents should always be in no-quirks mode

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24349

Morrita Hajime  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #27 from Morrita Hajime  ---
OK, let's do always standard path.
https://github.com/w3c/webcomponents/commit/e5c1417f687843eafd38a894d9378f2287a9f793

As Anne mentioned, there are two case to use the mode, and even in Blink, these
two are distinguished relatively clearly: The resolution is done by main
document's StyleResolver, the parsing is par-document CSSParser.

I am still a bit concerning that there could be hacks to break this design
discipline, but they are hacks and I'm convinced that paying another complexity
for existing complexity is not good idea.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: An error in document "http://www.w3.org/TR/widgets/"

[Arthur Barstow]

On 4/17/14 12:09 PM, ext Marcos Caceres wrote:


On April 17, 2014 at 5:46:17 AM, Wang, Peter H (peter.h.w...@intel.com) wrote:

Hi all,
  
I’ve found a small error in document http://www.w3.org/TR/widgets/. In “7.12.4 Example

of Usage”:
古老瓷地图
Ancient Chinese Maps
should be
古老中国地图
Ancient Chinese Maps
  
Thank you very much.

Thanks! Fixed:
https://github.com/w3c/packaged-webapps/commit/ae4a1d349e0550dbaad0dbac1bd05c62e942086f


Thanks to Peter for reporting this and to Marcos for updating the spec.


It's in the living standard version:
http://w3c.github.io/packaged-webapps/packaging/


Marcos - it seems like this correction should be added to the errata doc 
.


I also noticed: the REC 
 has a link to an ED 
that now 404s  and the 
errata doc has a link to a "differences document" that now returns an error.


Cindy, Yves - would one of you please update the TR with a new link to 
the ED (that Marcos provides, perhaps the URL he gives above)?


-Thanks, Art

Re: An error in document "http://www.w3.org/TR/widgets/"

[Marcos Caceres]

On April 17, 2014 at 5:46:17 AM, Wang, Peter H (peter.h.w...@intel.com) wrote:
> Hi all,
>  
> I’ve found a small error in document http://www.w3.org/TR/widgets/. In 
> “7.12.4 Example  
> of Usage”:
> 古老瓷地图
> Ancient Chinese Maps
> should be
> 古老中国地图
> Ancient Chinese Maps
>  
> Thank you very much.

Thanks! Fixed:
https://github.com/w3c/packaged-webapps/commit/ae4a1d349e0550dbaad0dbac1bd05c62e942086f

It's in the living standard version:
http://w3c.github.io/packaged-webapps/packaging/

An error in document "http://www.w3.org/TR/widgets/"

[Wang, Peter H]

Hi all,

I’ve found a small error in document http://www.w3.org/TR/widgets/. In “7.12.4 
Example of Usage”:
古老瓷地图
Ancient Chinese Maps
should be
古老中国地图
Ancient Chinese Maps

Thank you very much.

Regards,
Peter Wang