Re: Making template play nice with XML and tags-and-text
On Sun, Aug 5, 2012 at 7:00 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, Jul 18, 2012 at 11:35 PM, Adam Barth w...@adambarth.com wrote: On Wed, Jul 18, 2012 at 11:29 AM, Adam Klein ad...@chromium.org wrote: On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth w...@adambarth.com wrote: Inspired by a conversation with hsivonen in #whatwg, I spend some time thinking about how we would design template for an XML world. One idea I had was to put the elements inside the template into a namespace other than http://www.w3.org/1999/xhtml. On the face of things, this seems a lot less scary than the wormhole model. I think this merits further exploration! Thank you! This proposal seems worse than wormhole parsing because the interface of the template nodes is not HTMLElement, unless we're assuming it's a different but identical namespace? For instance it's super weird if img src=x is missing the .src property because it's not in the HTML namespace, but suddenly when it's cloned for instantiation it's back in the HTML namespace and has the src property. - E
[WEBIDL] nullable dictionary
Hi Cameron, While reading about dictionary from your Web IDL (Second Edition) draft, I found a part that needs clarification: -8- 3.3 Dictionaries If the Type is an identifier or an identifier followed by ?, then the identifier must identify an interface, *dictionary*, enumeration, callback function or typedef. -8- The spec allows dictionary type to go nullable here. -8- 3.10.22 Nullable types The inner type must not be any, a *dictionary* type, another nullable type, or a union type that itself has includes a nullable type or has a dictionary type as one of its flattened member types. -8- It does not allow nullable here. From the mail history I looked up, the intention is to not allow nullable dictionary type any more. It that right? Regards, Jungkee Jungkee Song Samsung Electronics
Re: [WEBIDL] nullable dictionary
Hi Jungkee, Jungkee Song: While reading about dictionary from your Web IDL (Second Edition) draft, I found a part that needs clarification: -8- 3.3 Dictionaries If the Type is an identifier or an identifier followed by ?, then the identifier must identify an interface, *dictionary*, enumeration, callback function or typedef. -8- The spec allows dictionary type to go nullable here. -8- 3.10.22 Nullable types The inner type must not be any, a *dictionary* type, another nullable type, or a union type that itself has includes a nullable type or has a dictionary type as one of its flattened member types. -8- It does not allow nullable here. From the mail history I looked up, the intention is to not allow nullable dictionary type any more. It that right? That's right. I've corrected that description of allowable dictionary member types, as well as for operation return types and arguments. Thanks, Cameron
Re: IndexedDB and RegEx search
On Tue, Aug 7, 2012 at 8:36 PM, Alec Flett alecfl...@google.com wrote:
FWIW it's fairly hard to for a database to index arbitrary content for
regexes, to the point where it's going to be hard to do MUCH better than
simply filtering based on regex.
Perhaps it shouldn't be a full-text *index* but simply a search feature.
Though I'm unfamiliar with specific implementations, I gather that
filtering records in native code would save (possibly lots of) redundant JS
object construction (time and memory = money :)), and doing so with a
pre-compiled regex might improve over certain JS implementation or
non-optimizable practices, e.g.
function search(field, s) {
someCallToIndexedDb(function filter(record) {
var re = new RegExp(s);
return !re.test(record[field]);
}
}
Plus it saves some code jumbling for a rather common practice.
[Bug 18502] New: [IndexedDB] Editorial: Wording around IDBFactory.open() with no version misleading
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18502 Summary: [IndexedDB] Editorial: Wording around IDBFactory.open() with no version misleading Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jsb...@chromium.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org The second paragraph reads: If no version is specified and a database exists, use the current database version and follow the steps for opening a database. If no version is specified and no database exists, set database version to 1, follow the steps for opening a database, and return a database without object stores. The most glaring issue is the final phrase, return a database without object stores - the function returns an IDBRequest, not a database. The intent is also redundant with step 4 of the Steps for opening a database. The phrase set database version to 1 may also be misleading. More correctly it should follow the phrasing used in the first paragraph which define the inputs to the steps, e.g. If no version is specified and no database exists, let /origin/ be the origin of the IDBEnvironment used to access this IDBFactory, let /name/ be the name parameter passed to this function, and let /version/ be 1. (There also seems to be some ambiguity about what happens if open() is called without a version but is delayed by a deleteDatabase(); the delete should happen first, but does the open() use the version the database had prior to the delete? If so, that's a little odd. If not, then the version can't logically be determined at this point in the spec, and must be deferred to the Steps for opening e.g. by having the /version/ be null with special cases. I may just be missing something in the spec, though.) -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
introduce myself, takano from ACCESS
Dear all webapps,
Thank you Art, to guide me.
This is Takano, AC Rep of ACCESS CO., LTD.
ACCESS is software vendor in Japan, we provides middlewares including
HTML browser for embedded market.
My interest is around TV.
As you know, HTML5 and web technology influence TV.
Web Applications on TV must be more important.
I want to discuss about how we control web applications on TV.
Sincerely,
--
takano.
--
※2012年3月に所属が変更になりました。
--
Kazuki Takano / 高野一樹
kazuki.tak...@access-company.com
+81-43-212-{3378(desk/直通),2129(office/部代表)}
+81-90-5392-9622(mobile/会社ケータイ)
ソフトウェアソリューション本部TVソリューションビジネスグループ開発部
ACCESS CO., LTD.
--
..
The contents of this e-mail message and any attachments are confidential and
are intended solely for the addressee. The information may also be legally
privileged.
This transmission is sent in trust, and the sole purpose of delivery to the
intended recipient. If you have received this transmission in error, any use,
reproduction or dissemination of this transmission is strictly prohibited.
If you are not the intended recipient, please immediately notify the sender by
reply e-mailer and delete this message and its attachments, if any.
Thank you for your cooperation.
Re: IndexedDB and RegEx search
On Wed, Aug 8, 2012 at 1:33 AM, Yuval Sadan sadan.yu...@gmail.com wrote:
On Tue, Aug 7, 2012 at 8:36 PM, Alec Flett alecfl...@google.com wrote:
FWIW it's fairly hard to for a database to index arbitrary content for
regexes, to the point where it's going to be hard to do MUCH better than
simply filtering based on regex.
Perhaps it shouldn't be a full-text *index* but simply a search feature.
Though I'm unfamiliar with specific implementations, I gather that filtering
records in native code would save (possibly lots of) redundant JS object
construction (time and memory = money :)), and doing so with a pre-compiled
regex might improve over certain JS implementation or non-optimizable
practices, e.g.
function search(field, s) {
someCallToIndexedDb(function filter(record) {
var re = new RegExp(s);
return !re.test(record[field]);
}
}
Plus it saves some code jumbling for a rather common practice.
The main thing you'd save is having to round-trip between threads for
each record. I think a more general feature that would be more
interesting would be to be able to iterate an index or objectStore
using a cursor, but at the time of constructing the cursor be able to
provide a javascript function which can be used to filter the data.
Unfortunately javascript doesn't have a good way of executing a
function in such a way that it doesn't pull in a lot of context, but
it's possible to hack this, for example by passing a string which
contains the javascript code.
This is somewhat similar to [1] and something we decided was
out-of-scope for v1. But for v2 I definitely think we should look at
mechanisms for using JS code to filter/sort/index data in such a way
that the JS code is run on the IO thread.
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=1
/ Jonas
[IndexedDB] Problems unprefixing IndexedDB
Hello all, Jonas mentioned earlier on this list that we unprefixed IndexedDB in Firefox nightlies some time ago. We ran into a bit of a problem.[0] Most of the IndexedDB tutorials (including ours and HTML5 Rocks[1] :-/) tell authors to deal with prefixing with: var indexedDB = window.indexedDB || window.webkitIndexedDB || window.mozIndexedDB || window.msIndexedDB || ... This code has a bug when executed at global scope. Because the properties are on the prototype chain of the global object, 'var indexedDB' creates a new property on the global. Then window.indexedDB finds the new property (which has the value undefined) instead of the IDBFactory on the prototype chain. The result is that all of the pages that do this no longer work after we unprefix IndexedDB. Mozilla is the only vendor affected by this at the moment. In our testing on IE 10.0.8400.0, both a prefixed and unprefixed version of IndexedDB are available, so the code above shadows the unprefixed version with the prefixed version (which has no real effect). In Chrome, attributes are on the object itself instead of the prototype, so 'var indexedDB' at global scope is a no-op. Our options, as we see them now, are: 1. Make no code changes, and evangelize. 2. Move indexedDB to the global object itself (copy Chrome). 3. Put the prefixed version back temporarily (copy IE). We'd prefer option 1 of course, if we can make that work. Any thoughts are welcome. We'd especially like to know if IE has plans to drop the prefixed version, and if Chrome is planning to move attributes to the prototype anytime soon. Thoughts? - Kyle PS. We're also going to run into this in the future with any other prefixed DOM APIs we add to the global, probably even if we don't tell people to do it wrong in our tutorials. This behavior is a pretty massive footgun. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=770844 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=770844#c5
Re: [IndexedDB] Problems unprefixing IndexedDB
On Wed, Aug 8, 2012 at 5:06 PM, Kyle Huey m...@kylehuey.com wrote: Hello all, Jonas mentioned earlier on this list that we unprefixed IndexedDB in Firefox nightlies some time ago. We ran into a bit of a problem.[0] Most of the IndexedDB tutorials (including ours and HTML5 Rocks[1] :-/) tell authors to deal with prefixing with: var indexedDB = window.indexedDB || window.webkitIndexedDB || window.mozIndexedDB || window.msIndexedDB || ... This code has a bug when executed at global scope. Because the properties are on the prototype chain of the global object, 'var indexedDB' creates a new property on the global. Then window.indexedDB finds the new property (which has the value undefined) instead of the IDBFactory on the prototype chain. The result is that all of the pages that do this no longer work after we unprefix IndexedDB. Just for reference, the correct way to do this is: window.indexedDB = window.indexedDB || window.webkitIndexedDB || window.mozIndexedDB || window.msIndexedDB || ... This avoids the var hoisting that's causing the problems. ~TJ
Re: [IndexedDB] Problems unprefixing IndexedDB
On 8/8/12 8:12 PM, Tab Atkins Jr. wrote: Just for reference, the correct way to do this is: window.indexedDB = window.indexedDB || window.webkitIndexedDB || window.mozIndexedDB || window.msIndexedDB || ... This avoids the var hoisting that's causing the problems. As long as you're not in strict-mode code. If you are, you have to be a bit smarter and actually condition things on |if (!(indexedDB in window))| of course... -Boris
Re: [IndexedDB] Problems unprefixing IndexedDB
On Wed, Aug 8, 2012 at 5:12 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Aug 8, 2012 at 5:06 PM, Kyle Huey m...@kylehuey.com wrote: Hello all, Jonas mentioned earlier on this list that we unprefixed IndexedDB in Firefox nightlies some time ago. We ran into a bit of a problem.[0] Most of the IndexedDB tutorials (including ours and HTML5 Rocks[1] :-/) tell authors to deal with prefixing with: var indexedDB = window.indexedDB || window.webkitIndexedDB || window.mozIndexedDB || window.msIndexedDB || ... This code has a bug when executed at global scope. Because the properties are on the prototype chain of the global object, 'var indexedDB' creates a new property on the global. Then window.indexedDB finds the new property (which has the value undefined) instead of the IDBFactory on the prototype chain. The result is that all of the pages that do this no longer work after we unprefix IndexedDB. Just for reference, the correct way to do this is: window.indexedDB = window.indexedDB || window.webkitIndexedDB || window.mozIndexedDB || window.msIndexedDB || ... This avoids the var hoisting that's causing the problems. If we're telling people to use that pattern, we might as well just not prefix the API in the first place because that pattern just tells the web developers to unilaterally unprefix the API themselves. Adam
Re: [IndexedDB] Problems unprefixing IndexedDB
On Wed, 8 Aug 2012, Kyle Huey wrote: PS. We're also going to run into this in the future with any other prefixed DOM APIs we add to the global, probably even if we don't tell people to do it wrong in our tutorials. This behavior is a pretty massive footgun. Not prefixing, and instead having spec authors make sure that what they spec is compatible with what has shipped (at the very least by changing names when they change semantics), is of course the right solution here. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [IndexedDB] Problems unprefixing IndexedDB
On 8/8/12 8:23 PM, Adam Barth wrote: If we're telling people to use that pattern, we might as well just not prefix the API in the first place because that pattern just tells the web developers to unilaterally unprefix the API themselves. Yep. The only benefit of the prefixing at that point is to maybe mark the API as experimental, if any web developers pay attention. Which I doubt. There's been a lot of discussion about prefixing CSS properties (or rather not doing that anymore, preferring other solutions like shipping things preffed off by default) that also applies to prefixing DOM APIs. -Boris
Re: [IndexedDB] Problems unprefixing IndexedDB
On Wed, Aug 8, 2012 at 7:23 PM, Adam Barth w...@adambarth.com wrote: window.indexedDB = window.indexedDB || window.webkitIndexedDB || window.mozIndexedDB || window.msIndexedDB || ... This avoids the var hoisting that's causing the problems. If we're telling people to use that pattern, we might as well just not prefix the API in the first place because that pattern just tells the web developers to unilaterally unprefix the API themselves. If browsers are going to unprefix APIs without leaving the prefixed API in place for a while, then this is what people are going to do anyway. Otherwise, their sites will break (or lose functionality) until they scramble to add the unprefixed name. APIs should always be shipped prefixed and unprefixed for a reasonable period, so people have an opportunity to add the unprefixed name to their site before the unprefixed name goes away. On Wed, Aug 8, 2012 at 7:28 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yep. The only benefit of the prefixing at that point is to maybe mark the API as experimental, if any web developers pay attention. Which I doubt. At the very least, *vendor* prefixing seems pointless; a single prefix for experimental, non-vendor-specific APIs would convey the same thing, without having to special case every browser. (People might need to work around implementation differences, but we do that just fine without vendor prefixes.) -- Glenn Maynard
