An error in document http://www.w3.org/TR/widgets/
Hi all, I’ve found a small error in document http://www.w3.org/TR/widgets/. In “7.12.4 Example of Usage”: name xml:lang=zh-cn古老瓷地图/name nameAncient Chinese Maps/name should be name xml:lang=zh-cn古老中国地图/name nameAncient Chinese Maps/name Thank you very much. Regards, Peter Wang
Re: An error in document http://www.w3.org/TR/widgets/
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/
Re: An error in document http://www.w3.org/TR/widgets/
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 http://dev.w3.org/2006/waf/widgets/errata.html. I also noticed: the REC http://www.w3.org/TR/2012/REC-widgets-20121127/ has a link to an ED that now 404s http://w3c.github.io/packed-webapps/packaging/ 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
[Bug 24349] [imports]: Import documents should always be in no-quirks mode
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24349 Morrita Hajime morr...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Morrita Hajime morr...@google.com --- 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/
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
Re: Starting work on Indexed DB v2 spec - feedback wanted
On Thu, Apr 17, 2014 at 1:22 PM, Tim Caswell t...@creationix.com 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 jsb...@google.com 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=RESOLVEDcomponent=Indexed%20Database%20APIlist_id=34841product=WebAppsWGquery_format=advancedresolution=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
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 t...@creationix.com 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 jsb...@google.com 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=RESOLVEDcomponent=Indexed%20Database%20APIlist_id=34841product=WebAppsWGquery_format=advancedresolution=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
On Thu, Apr 17, 2014 at 2:10 PM, Dale Harvey d...@arandomurl.com 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
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 jsb...@google.com wrote:
On Thu, Apr 17, 2014 at 1:22 PM, Tim Caswell t...@creationix.com 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 jsb...@google.com 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=RESOLVEDcomponent=Indexed%20Database%20APIlist_id=34841product=WebAppsWGquery_format=advancedresolution=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
On 4/17/2014 5:41 PM, Kyle Huey wrote: On Thu, Apr 17, 2014 at 2:10 PM, Dale Harvey d...@arandomurl.com 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
