Re: [IndexedDB] Passing an empty array to IDBDatabase.transaction
On Fri, Oct 7, 2011 at 1:43 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, In both the Firefox and the Chrome implementation you can pass an empty array to IDBDatabase.transaction in order to create a transaction which has a scope that covers all objectStores in the database.; This, however, is not specified behavior. According to the spec as it is now the transaction should be created with an empty scope. I'm personally not a big fan of this syntax. My concern is that it makes it easier to create a widely scoped transaction which has less ability to run in parallel with other transactions, than to create a transaction with as narrow scope as possible. And passing db.objectStoreNames is always possible. What do people think we should do? Should we add this behavior to the spec? Or are implementations willing to remove it? We agree it's a bad behavior, and are willing to remove that behavior from our implementation. Since it's never been in the spec, there shouldn't be too many dependencies on it. It was mentioned in a tutorial that Jeremy wrote though, so some might have picked it up from there. Thanks, Hans
Gave a try to the Component Model
Hi, I’m interested in the component model proposal [1] and tried to imagine what architecture patterns our apps would follow by using it. I wrote my notes here [2] and I’d like you to read and comment them. The most difficult problem to solve seems to be the way components will be bound together since we don’t control how they are instanciated and configured. Regards, Julien [1] http://wiki.whatwg.org/wiki/Component_Model [2] http://substance.io/julienrf/dom-component-model/1
Re: [IndexedDB] Passing an empty array to IDBDatabase.transaction
So it sounds like everyone agrees that accepting an empty array is not desired... Can we just make that case throw an exception rather than generating an empty transaction (which will then throw when it is used)? -Ben Turner
CfC: new WD of File API; deadline Oct 17
This is a Call for Consensus to publish a WD of the File API spec (last published 26-Oct-2010): http://dev.w3.org/2006/webapi/FileAPI/ Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is October 17. Please send all comments to: public-webapps@w3.org -AB
Re: [IndexedDB] Passing an empty array to IDBDatabase.transaction
On Fri, Oct 7, 2011 at 11:51 AM, Israel Hilerio isra...@microsoft.com wrote: On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote: Hi All, In both the Firefox and the Chrome implementation you can pass an empty array to IDBDatabase.transaction in order to create a transaction which has a scope that covers all objectStores in the database. I.e. you can do something like: trans = db.transaction([]); trans.objectStore(any objectstore here); (Note that this is *not* a dynamic scoped transaction, it's still a static scope that covers the whole database). In other words, these implementations treat the following two lines as equivalent: trans = db.transaction([]); trans = db.transaction(db.objectStoreNames); This, however, is not specified behavior. According to the spec as it is now the transaction should be created with an empty scope. I suspect both Mozilla and Google implemented it this way because we had discussions about this syntax on the list. However apparently this syntax never made it into the spec. I don't recall why. I'm personally not a big fan of this syntax. My concern is that it makes it easier to create a widely scoped transaction which has less ability to run in parallel with other transactions, than to create a transaction with as narrow scope as possible. And passing db.objectStoreNames is always possible. What do people think we should do? Should we add this behavior to the spec? Or are implementations willing to remove it? / Jonas Our implementation interprets the empty array as an empty scope. We allow the transaction to be created but we throw a NOT_FOUND_ERR when trying to access any object stores. I vote for not having this behavior :-). Hi Israel, I just realized that I might have misinterpreted your response. Are you saying that you think that passing an empty-array should produce a transaction with an empty scope (like in IEs implementation and as described by the spec currently), or a transaction with every objectStore in scope (like in Firefox and chrome)? / Jonas
Re: [IndexedDB] Passing an empty array to IDBDatabase.transaction
On Mon, Oct 10, 2011 at 7:44 AM, ben turner bent.mozi...@gmail.com wrote: So it sounds like everyone agrees that accepting an empty array is not desired... Can we just make that case throw an exception rather than generating an empty transaction (which will then throw when it is used)? I'm fine either way. / Jonas
RE: [IndexedDB] Passing an empty array to IDBDatabase.transaction
On Monday, October 10, 2011 9:46 AM, Jonas Sicking wrote: On Fri, Oct 7, 2011 at 11:51 AM, Israel Hilerio isra...@microsoft.com wrote: On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote: Hi All, In both the Firefox and the Chrome implementation you can pass an empty array to IDBDatabase.transaction in order to create a transaction which has a scope that covers all objectStores in the database. I.e. you can do something like: trans = db.transaction([]); trans.objectStore(any objectstore here); (Note that this is *not* a dynamic scoped transaction, it's still a static scope that covers the whole database). In other words, these implementations treat the following two lines as equivalent: trans = db.transaction([]); trans = db.transaction(db.objectStoreNames); This, however, is not specified behavior. According to the spec as it is now the transaction should be created with an empty scope. I suspect both Mozilla and Google implemented it this way because we had discussions about this syntax on the list. However apparently this syntax never made it into the spec. I don't recall why. I'm personally not a big fan of this syntax. My concern is that it makes it easier to create a widely scoped transaction which has less ability to run in parallel with other transactions, than to create a transaction with as narrow scope as possible. And passing db.objectStoreNames is always possible. What do people think we should do? Should we add this behavior to the spec? Or are implementations willing to remove it? / Jonas Our implementation interprets the empty array as an empty scope. We allow the transaction to be created but we throw a NOT_FOUND_ERR when trying to access any object stores. I vote for not having this behavior :-). Hi Israel, I just realized that I might have misinterpreted your response. Are you saying that you think that passing an empty-array should produce a transaction with an empty scope (like in IEs implementation and as described by the spec currently), or a transaction with every objectStore in scope (like in Firefox and chrome)? / Jonas We don't do it like FF or chrome. We create the transaction but it has an empty scope transaction. Therefore, whenever you try to access an object store we throw an exception. Based on what Hans said, it seems we're all in agreement. Also, I like Ben's suggestion of not allowing these transactions to be created in the first place and throwing an exception during their creation. Israel
RE: IndexedDB: ordering sense of IDBFactory.cmp?
On Monday, October 03, 2011 10:04 AM, Jonas Sicking wrote: On Mon, Oct 3, 2011 at 9:30 AM, Joshua Bell jsb...@chromium.org wrote: As we're implementing IDBFactory.cmp in WebKit we noticed that the ordering sense is reversed compared to C's strcmp/memcmp, Perl's cmp/= operators, etc. As currently spec'd, IDBFactory.cmp(first, second) returns 1 if first second C's memcmp/strcmp(first, second) return -1 if first second Perl's (first cmp second) and (first = second) operators return -1 if first second Java's first.compareTo(second) returns 0 if first second .NET's String.Compare(first, second) returns 0 if first second We're wondering if this will be a usability issue with the API, if there's a good justification for this seemingly inverted ordering, and if it's not too late to reverse this in the spec. I don't recall any particular reason for the current order. I suspect it was simply a mistake. I'm all for reversing order. / Jonas Good catch! This makes sense to us too. Israel
W3Conf: conference for Web App developers November 15-16
[ Sorry for the cross posting ... ] If you are looking for a conference focused on using Web APIs and HTML5 e.g. to develop Web apps, design Web apps, etc., check out this November 15-16 W3Conf conference in Redmond WA US: [[ http://w3conf.org/ = 2011: HTML5 and the Open Web Platform W3C, the web standards organization, is holding its first conference. If you are a developer or designer wanting to hear the latest news on HTML5 and the open web platform, and your place in it, save the date. A limited number of seats will be available for the live audience in Redmond–just outside of Seattle–and videos of the presentations will be streamed live to the world. ... = Sessions Speakers W3Conf has industry leaders speaking on a wide variety of topics that every developer needs to know: HTML5, APIs and Javascript, graphics, accessibility, CSS, and much more. We have selected speakers on an invitation-only basis to deliver the most educational and entertaining experience for our audience on the topics we felt were the most pressing for Web developers and designers today. ]] The conference costs $199 and the registration site is http://w3conf2011.eventbrite.com/?ref=elink. Doug says the scheduled should be fleshed out in a day or two. -AB
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, 4 Oct 2011, Roland Steiner wrote:
On Tue, Oct 4, 2011 at 12:38 PM, Ian Hickson i...@hixie.ch wrote:
* Any case of taking an element with existing semantics (e.g. a select
showing a list of countries) and replacing its presentation with
something completely different (e.g. a map selector), where the exact
binding could depend based on media queries (e.g. different UIs for
tablets vs TVs) or alternative style sheet selections (e.g. the user
picking a high-contrast view rather than a custom cool one).
Well for one we already have HTML elements that do more or less the same
(select vs. input type=radio, button vs. input type=button), so
it doesn't seem such a stretch to me to allow select vs. select
is=mapselect.
Granted. A more obviously gratuitous case could be buttons that are given
new styles. For example, Google has recently changed many of its sites to
use divs instead of buttons for its buttons because it wants a special
look for them. This means that if you disable CSS, the entire UI
collapses. The same would happen if they all use x-google-fancy-button.
However, if the pages could just use regular semantics and then had the
style loaded in dynamically via CSS, it could look exactly as it does now
but with no loss of semantics.
On a second note, what you essentially seem to demand is swapping out
entire HTML sub-branches based on presentation.
It's not how I would describe it (I wouldn't expect the shadow trees to be
written using HTML), but to a first approximation, sure. This is pretty
normal in terms of what changes to rendering trees look like. Today we
swap in one branch or another using display:none or by direct DOM
manipulation. It's more or less equivalent.
It is IMHO not entirely a given that it's components who have to fulfill
this mechanism.
I'm fine with calling it something else. My point is just that the vast
bulk of the mechanisms you need to create new widgets and the mechanisms
you need to style existing widgets are essentially the same. So reusing
the same solution makes sense.
IOW, components could be seen as a neat, simple wrapping of a complex
DOM structure under a single element name (or binding attribute), and
the task of switching out different HTML trees (whether containing
components or not) could be handled by another, yet-to-be-specified
mechanism.
So long as we don't have to reinvent the wheel twice where the two
mechanisms are the same, that's fine by me.
This incidentally would also solve the security issue you mentioned in
conjunction with CSS bindings.
How so? The security problem isn't specific to any particular solution,
it's a generic issue of invoking script from CSS. The solution to it is
trivial (pre-declare the bindings in the markup).
X-MYWIDGET
- best performance (in instantiation, CSS selector matching)
I don't see why it would be more performant, can you elaborate on
that?
Instantiation: for button is=mywidget I assumed there is a gap during
parsing when a button is instantiated, then later is expanded/replaced
when the is attribute is read.
No, I am proposing it all happens at once.
CSS Selector matching: WebKit at least has a fast path for element
names, but not for attribute matches. So button[is=mywidget] { color:
red; } would be slower than x-mywidget { color: red; }. (The former
also requires up to 2 comparisons - attribute value and element name -
besides.)
There's no reason we couldn't also optimise for is. So [is=mywidget]
could be just as fast as x-mywidget. (No need for the attribute selector
to include the element name.)
button { BINDING: MYWIDGET; }
- shadow DOM dependent on rendering tree (something we explicitly
wanted to avoid)
It's dependent on the style resolution, not the rendering tree.
Right, but the point still stands: We'd have a DOM tree hanging off
(be dependent on) something that isn't the DOM. This was the case
previously in WebKit before we started with the whole shadow DOM
approach, and caused a lot of headaches.
Could you elaborate? I don't see what the problems are here. We already
have plenty of mechanisms that can introduce rendering content without the
DOM tree being involved, e.g. ::before/::after, 'content' on elements,
display: list-item, etc. If this is causing problems in WebKit, it seems
like something that needs to be fixed in WebKit regardless of whether we
explicitly support bindings or not.
- unclear what happens if a HTML element with (intrinsic or explicit)
shadow DOM is assigned a CSS binding as well
It doesn't have to be unclear, it just has to be defined. There are
two obvious options: replace it, or augment it. XBL2 supported both.
TBH, XBL2's answer to multiple bindings felt rather hand-wavey to me -
it assumed that an arbitrary intrinsic order would work in all
circumstances, and that the various bindings wouldn't end up
[IndexedDB] Soliciting feedback from SQL Vendors
Is there interest or presence on this list from major SQL vendor developers such as PostgreSQL and MySQL? WebSQL received a thumbs-down from the postgresql developers mailing list. Now that that issue is over... MySQL and PostgreSQL core developers have specialized knowledge, I want to see their participation in the IDB threads. If they're already here, great. If they're not here, what can we do to attract them? IDB is reasonably far along, it has wide support amongst browser vendors: I'd like to take things further and see if we can get MySQL and PostgreSQL developers onto the group. Those two engines represent the most popular server-side database packages on the net. Review of the IDB specification from these communities would improve consensus and the peer review process. With utmost respect for all contributors to IDB, I'd like to see additional review from database vendors. -Charles
Re: [IndexedDB] Soliciting feedback from SQL Vendors
On Mon, Oct 10, 2011 at 1:40 PM, Charles Pritchard ch...@jumis.com wrote: Is there interest or presence on this list from major SQL vendor developers such as PostgreSQL and MySQL? WebSQL received a thumbs-down from the postgresql developers mailing list. Now that that issue is over... MySQL and PostgreSQL core developers have specialized knowledge, I want to see their participation in the IDB threads. If they're already here, great. If they're not here, what can we do to attract them? IDB is reasonably far along, it has wide support amongst browser vendors: I'd like to take things further and see if we can get MySQL and PostgreSQL developers onto the group. Those two engines represent the most popular server-side database packages on the net. Review of the IDB specification from these communities would improve consensus and the peer review process. With utmost respect for all contributors to IDB, I'd like to see additional review from database vendors. I'd love to get input from SQL database developers! I don't have any particularly great ideas for how to get that input other than simply mailing the various mailing lists directly. / Jonas
Re: Question about implementing DataTransfer.addElement
On Fri, 7 Oct 2011, Daniel Cheng wrote: What's the difference between addElement and setDragImage()? The spec says: The difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added (potentially keeping it updated as the drag continues, e.g. if the elements include an actively playing video), whereas the former uses the exact specified image at the time the method is invoked. For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. However, if we don't implement dynamic drag image updates, doesn't that make it essentially the same as setDragImage()? In that case, what's the point of having addElement(); wouldn't it make more sense to just remove it rather than having two different ways of doing the same thing? The parenthetical isn't the important part (that's why it's parenthetical). The important difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added whereas the former uses the exact specified image. So for example if the user is dragging an element with some complicated CSS styles, that's what gets drawn with addElement(), whereas the author has no sane way of providing an image that contains equivalent pixels. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Spec changes for LCs and later maturity levels [Was: Re: RfC: LCWD of Web Socket API; comment deadline October 21]
On Sun, 9 Oct 2011, Arthur Barstow wrote: On 10/7/11 8:32 AM, ext Julian Reschke wrote: As far as I recall, we agreed in the IETF WG that parsing of web socket URIs should work exactly the same way as for any other URI scheme. It appears that the API spec now tries to override this, and this looks problematic to me. On 10/7/11 9:30 AM, ext Arthur Barstow wrote: In [1], Julian asks about Web Socket API rev 1.247 [2], the change that adds the Parsing WebSocket URLs section (CVS comment Revert the part of r5409 that removed the URL parsing algorithms, since it's no longer defined in the protocol spec. (whatwg r6632)). Would you please elaborate on this change? On 10/7/11 11:28 AM, ext Ian Hickson wrote: Elaborate in what way? Why is the override in 1.247 needed, given what Julian indicates above? There's no override. It's just defining how you do it because nothing else defines it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Question about implementing DataTransfer.addElement
On 10/10/2011 3:26 PM, Ian Hickson wrote: On Fri, 7 Oct 2011, Daniel Cheng wrote: What's the difference between addElement and setDragImage()? The spec says: The difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added (potentially keeping it updated as the drag continues, e.g. if the elements include an actively playing video), whereas the former uses the exact specified image at the time the method is invoked. For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. What are the technical reasons? Is this something to do with OS level handling? Seems that on an OS level, an animated drag image might be something that the OS does not support. But for all intents, the OS does not need to support a drag image either. Should this kind of fallback be specified? I'd imagine that current OS X and Windows systems do support more dynamic dragging. If they don't, well, what about the next round? It does seem to me to be fundamentally different than images that are shown within the browser, where things can be animated by the UA. Once you're outside of the UA, it's really up to the OS capabilities. But, again, show me the proof: What are the technical reasons? There's no magic box here, the major OS APIs are open to all of us. -Charles
Re: Question about implementing DataTransfer.addElement
On Mon, Oct 10, 2011 at 15:26, Ian Hickson i...@hixie.ch wrote: The parenthetical isn't the important part (that's why it's parenthetical). The important difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added whereas the former uses the exact specified image. So for example if the user is dragging an element with some complicated CSS styles, that's what gets drawn with addElement(), whereas the author has no sane way of providing an image that contains equivalent pixels. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' It seems like setDragImage() does that as well: If the element argument is an img element, then set the drag data store bitmap to the element's image (at its intrinsic size); otherwise, set the drag data store bitmap to an image generated from the given element (the exact mechanism for doing so is not currently specified). Doesn't the otherwise clause describe exactly what addElement() does? Daniel
Re: Question about implementing DataTransfer.addElement
On Mon, 10 Oct 2011, Daniel Cheng wrote: On Mon, Oct 10, 2011 at 15:26, Ian Hickson i...@hixie.ch wrote: The parenthetical isn't the important part (that's why it's parenthetical). The important difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added whereas the former uses the exact specified image. So for example if the user is dragging an element with some complicated CSS styles, that's what gets drawn with addElement(), whereas the author has no sane way of providing an image that contains equivalent pixels. It seems like setDragImage() does that as well: If the element argument is an img element, then set the drag data store bitmap to the element's image (at its intrinsic size); otherwise, set the drag data store bitmap to an image generated from the given element (the exact mechanism for doing so is not currently specified). Doesn't the otherwise clause describe exactly what addElement() does? Ah, indeed. I forgot about that. I guess the difference then is just that addElement() lets you add multiple elements, but that's not a particularly great difference. If nobody implements it, or if people who implement it don't mind dropping it, we can drop it from the spec entirely. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Question about implementing DataTransfer.addElement
On 10/10/2011 4:15 PM, Ian Hickson wrote: On Mon, 10 Oct 2011, Daniel Cheng wrote: On Mon, Oct 10, 2011 at 15:26, Ian Hicksoni...@hixie.ch wrote: The parenthetical isn't the important part (that's why it's parenthetical). The important difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added whereas the former uses the exact specified image. So for example if the user is dragging an element with some complicated CSS styles, that's what gets drawn with addElement(), whereas the author has no sane way of providing an image that contains equivalent pixels. It seems like setDragImage() does that as well: If the element argument is an img element, then set the drag data store bitmap to the element's image (at its intrinsic size); otherwise, set the drag data store bitmap to an image generated from the given element (the exact mechanism for doing so is not currently specified). Doesn't the otherwise clause describe exactly what addElement() does? Ah, indeed. I forgot about that. I guess the difference then is just that addElement() lets you add multiple elements, but that's not a particularly great difference. If nobody implements it, or if people who implement it don't mind dropping it, we can drop it from the spec entirely. I'd like to keep it around for a little while, if that's possible. I could envision a UI where the clipboard or dragging interface does show multiple items. Many windowing interfaces now show medium-sized thumbnails of open windows as a user presses Alt+TAB. An interface to show multiple elements seems possible. I do understand that it's a rare case, may not be implemented, and may simply be a lot of work with little reward. -Charles
Re: [IndexedDB] Soliciting feedback from SQL Vendors
On 10/10/2011 1:44 PM, Jonas Sicking wrote: On Mon, Oct 10, 2011 at 1:40 PM, Charles Pritchardch...@jumis.com wrote: Is there interest or presence on this list from major SQL vendor developers such as PostgreSQL and MySQL? I'd love to get input from SQL database developers! I don't have any particularly great ideas for how to get that input other than simply mailing the various mailing lists directly. I'll go ahead with that. The first time around, I was asked about the security / quota model. I'd prefer to just say that it's out of scope, though there are proposals. I see no reason to derail things on that issue. Many vendors are working with low-level languages running in machine code: is there a quick hack/means to describing the event loop model? Should I sheepishly leave that part out? Most of these developers are working with simple sync/async libraries that are called from C and C++. The event loop is fundamental to some behaviors; it's assumed in the specification. But, it's not something I really want to get hung-up on. Ideas for how to avert that? Is it unethical to simply not bring it up? Is it something that they're going to have to figure out on their own? Such as with an endloop private extended function. -Charles
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
Splitting this up into two different things is great. Allowing attaching an alternative shadow tree through CSS but disabling any JS to be run seems like the right thing to do. I'm also in favor of the is attribute. Even though I think that x-foo is more readable than div is=foo it is hard to argue about the issues regarding parsing and fallback behavior. The is attribute also provides a better behavior for common cases such as when you want to extend select and button. erik
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On 10/10/2011 4:55 PM, Erik Arvidsson wrote: Splitting this up into two different things is great. Allowing attaching an alternative shadow tree through CSS but disabling any JS to be run seems like the right thing to do. I'm also in favor of the is attribute. Even though I think that x-foo is more readable thandiv is=foo it is hard to argue about the issues regarding parsing and fallback behavior. The is attribute also provides a better behavior for common cases such as when you want to extendselect andbutton. erik This seems to be the same tact that ARIA 1.0 went with to describe new attributes. I'd like to know what your definition of the word is is. Will I be writing the following: div is=button role=button Will it be shorter: div is=button If it's shorter, it seems my shadow tree should have role=button on the appropriate element. Is that conducive to your definition of is? As far as I can tell, the is operates well with ARIA; if the author has their own roles, they can specify them within the shadow dom, otherwise, the role is borrowed from the element. If is is adopted, it seems relevant to include a specific mapping between is and role for ARIA consumers. I'd like to see is as an attribute that applies to other families supported by HTML5: SVG may benefit. That is, it may be a deserving first-class attribute. It seems to signify that the shadow dom is supported, just as role signifies that ARIA is supported, and id works with the ever-handy DOM getElementById. -Charles
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Mon, 10 Oct 2011, Erik Arvidsson wrote: Splitting this up into two different things is great. Allowing attaching an alternative shadow tree through CSS but disabling any JS to be run seems like the right thing to do. You wouldn't want to disable any JS. Just the API defining aspects. I'm also in favor of the is attribute. Even though I think that x-foo is more readable than div is=foo it is hard to argue about the issues regarding parsing and fallback behavior. The is attribute also provides a better behavior for common cases such as when you want to extend select and button. Agreed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson i...@hixie.ch wrote: If an author invents a new element, it doesn't matter what it inherits from. It won't have fallback behaviour, it won't have semantics that can be interpreted by search engines and accessibility tools, it won't have default renderings, and it won't allow for validation to catch authoring mistakes. I don't see what inheritance has to do with anything here. Ian, apologies if you have answered this before and I haven't seen it, but a (fairly brief) query didn't turn up anything for me: when is it okay to create new elements? Obviously, we created a bunch for HTML 5 that don't have fallback behavior ... It seems like it would be helpful to distinguish between new elements that can be reasonably mapped onto existing elements' semantics and elements that cannot; perhaps we can agree that elements should be reused where possible, but that there should also be mechanism for defining new elements otherwise? -- Dirk
Re: [IndexedDB] Soliciting feedback from SQL Vendors
On Mon, Oct 10, 2011 at 4:47 PM, Charles Pritchard ch...@jumis.com wrote: On 10/10/2011 1:44 PM, Jonas Sicking wrote: On Mon, Oct 10, 2011 at 1:40 PM, Charles Pritchardch...@jumis.com wrote: Is there interest or presence on this list from major SQL vendor developers such as PostgreSQL and MySQL? I'd love to get input from SQL database developers! I don't have any particularly great ideas for how to get that input other than simply mailing the various mailing lists directly. I'll go ahead with that. The first time around, I was asked about the security / quota model. I'd prefer to just say that it's out of scope, though there are proposals. I see no reason to derail things on that issue. I think it's currently somewhat undefined. Firefox currently guarantees that any data written will be written permanently. I.e. it won't be deleted other than through system malfunction (computer being run over by a steam roller) or explicit user action (user choosing to delete all stored data for a given site). Because the data is stored permanently we ask the user before doing so. I *believe* chrome more works like a cache. I.e. if the user ends up with more than X bytes of total data, the least recently used data is removed. I don't know the exact granularity of the data being removed (whole database at a time, or whole origin at a time). Many vendors are working with low-level languages running in machine code: is there a quick hack/means to describing the event loop model? Should I sheepishly leave that part out? The wording in the spec is somewhat inconsistent right now. But it does attempt to explicitly describe what happens in separate asynchronous tasks, and what happens synchronously on the calling thread. If something is unclear in the spec, please file a bug. Most of these developers are working with simple sync/async libraries that are called from C and C++. The event loop is fundamental to some behaviors; it's assumed in the specification. But, it's not something I really want to get hung-up on. Ideas for how to avert that? Is it unethical to simply not bring it up? Please do bring it up. The sync vs. async behavior is very important. A lot of effort has gone into making the API usable by keeping as much as possible synchronous, while still keeping any IO operations async. Is it something that they're going to have to figure out on their own? Such as with an endloop private extended function. I don't know what you mean by this. / Jonas
Re: Mutation Observers: a replacement for DOM Mutation Events
On 24/09/11 7:16 AM, Adam Klein wrote: Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and Mozilla (Olli Pettay, Jonas Sicking) have worked together on a proposal for a replacement for Mutation Events. This proposal represents our best attempt to date at making a set of sensible trade offs which allows for a new mutation observation mechanism that: - Is free of the faults of the existing Mutation Events mechanism (enumerated in detail here: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html) A simpler solution that is free from the faults listed in that email would be to have (at max) one mutation observer for the whole page context. I guess this would be called at the end of the task or immediately before page reflows. If a js lib (or multiple libs) want to provide finer grained mutation handling then let them work out the details. Sean
[cors] Failed sharing check and cookies
Currently if a resource sharing check fails cookies will still be set for a credentialed request similarly to how they would be with form or img. However, it seems that HTML defines for img crossorigin that the UA must act as if there was no response at all. That does not work of course for the normal img case where the server could still opt in to sharing, but would work for XMLHttpRequest. I think I will try to adopt that stricter behavior. Please speak up if you disagree. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] Failed sharing check and cookies
On Tue, 11 Oct 2011 12:53:35 +0900, Anne van Kesteren ann...@opera.com wrote: Currently if a resource sharing check fails cookies will still be set for a credentialed request similarly to how they would be with form or img. However, it seems that HTML defines for img crossorigin that the UA must act as if there was no response at all. That does not work of course for the normal img case where the server could still opt in to sharing, but would work for XMLHttpRequest. I think I will try to adopt that stricter behavior. Please speak up if you disagree. To make it more clear, currently if you XHR from A to B with withCredentials set to true, and B does a Set-Cookie, cookies will be set for B regardless of whether the resource sharing check for B passes or fails. If you do img crossorigin from A to B, and a resource sharing check for B fails, cookies must not be set (per my reading of the HTML specification). The question is whether XHR should align with this behavior. On IRC sicking brought up this might be harder for Gecko because of their HTTP library implementation (they currently do not conform for img crossorigin therefore). Is this an issue for WebKit? For Opera it does not matter, but we prefer the stricter behavior. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] Failed sharing check and cookies
On Mon, Oct 10, 2011 at 9:20 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 11 Oct 2011 12:53:35 +0900, Anne van Kesteren ann...@opera.com wrote: Currently if a resource sharing check fails cookies will still be set for a credentialed request similarly to how they would be with form or img. However, it seems that HTML defines for img crossorigin that the UA must act as if there was no response at all. That does not work of course for the normal img case where the server could still opt in to sharing, but would work for XMLHttpRequest. I think I will try to adopt that stricter behavior. Please speak up if you disagree. To make it more clear, currently if you XHR from A to B with withCredentials set to true, and B does a Set-Cookie, cookies will be set for B regardless of whether the resource sharing check for B passes or fails. If you do img crossorigin from A to B, and a resource sharing check for B fails, cookies must not be set (per my reading of the HTML specification). The question is whether XHR should align with this behavior. On IRC sicking brought up this might be harder for Gecko because of their HTTP library implementation (they currently do not conform for img crossorigin therefore). Is this an issue for WebKit? For Opera it does not matter, but we prefer the stricter behavior. I don't necessarily dislike this idea, though I think we should specify it on a CORS level rather than separately for img crossorigin, XHR etc. This will however be non-trivial to implement in Gecko as our HTTP layer does the cookie handling, but the CORS implementation is built on top of the HTTP layer. It's just software, so it's certainly fixable. But I wanted to make sure that other browsers are able to make this change too. / Jonas
Re: [cors] Failed sharing check and cookies
On Tue, 11 Oct 2011 13:20:40 +0900, Anne van Kesteren ann...@opera.com wrote: If you do img crossorigin from A to B, and a resource sharing check for B fails, cookies must not be set (per my reading of the HTML specification). My reading is wrong. Once HTML discards the resource the cookies have already been set. We could still decide to change this of course, but it does seem like HTML and XMLHttpRequest are consistent here. (Although some clarification in wording could be in order given the apparent confusion.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [indexeddb] Implicit Transaction Request associated with failed transactions
On Thu, Oct 6, 2011 at 3:30 PM, Israel Hilerio isra...@microsoft.com wrote:
On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio
isra...@microsoft.com
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
vartransaction/var to varcode/var.
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 cancel the
transaction. No error will be assigned to the transaction error value. The
error value will be 0 (or empty string/null) when the IDBTransaction.onabort
handler is called.
SCENARIO #4 (to be complete):
Whenever there is an error on a request, the error value associated with the
request will be assigned to the transaction error value. However, if the
event.preventDefault() method is called on the request, the only handler that
will be called will be IDBTransaction.onerror and the error value will be
available in the transaction. This implies that the value of the first
transaction event error that is not cancelled or prevented from executing its
default behavior will be value that will be contained by the error on the
transaction when the IDBTransaction.onabort handler is called. See example
below:
request1 == fires onerror with event.target errorCode == DATA_ERR
//request1 will preventDefault on the error event
transaction == fires onerror with this.errorCode = event.target.errorCode ==
DATA_ERR
request2 == fires onerror with event.target
