Re: Beacon API
On Sat, Feb 16, 2013 at 11:36 AM, Reitbauer, Alois alois.reitba...@compuware.com wrote: The conversations this week were very helpful in deciding how to move forward. I second Jatinder's idea that we come up with a specification that describes in details what we need. We should also treat it as a separate specification. If we then see that it has enough commonalities with XHR and does not introduce unnecessary complexity we can still merge it. I also think that this is the most efficient way to move forward here. It's not entirely clear to me how we moved from we need a simple flag on XHR to lets create a whole new API... -- http://annevankesteren.nl/
Re: [webcomponents] Making the shadow root an Element
On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov dglaz...@google.com wrote: We were thinking of adding innerHTML to DocumentFragments anyway... right, Anne? Well I thought so, but that plan didn't work out at the end of the day. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694#c7 So given that consensus still putting it on ShadowRoot strikes me like a bad idea (as I think I've said somewhere in a bug). The same goes for various other members of ShadowRoot. -- http://annevankesteren.nl/
Re: Re: Keyboard events for accessible RIAs and Games
I'll be updating the document this week. I'll send an update to the list after that happens. On Sat, Feb 16, 2013 at 7:40 AM, Florian Bösch pya...@gmail.com wrote: Any progress on the speccing of queryKeyCap? On Fri, Feb 1, 2013 at 9:14 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: On Fri, Feb 1, 2013 at 11:42 AM, Travis Leithead travis.leith...@microsoft.com wrote: I think we should give it another try by including it in our UI Events spec. I like the idea of adding the static queryKeyCap(code) API to Keyboard events. I wonder about the name though. A key capability doesn't sound right. Are we querying for a key's locale name? e.g., queryKeyLocaleName(code)? SGTM. I'll add a section to the spec for this. The KeyCap name refers to the cap placed over the keyswitch of the physical keyboard. It's not a great name since there's no guarantee that the physical keyboard matches the current locale (although they usually do). However, the other (more accurate) names that I was able to come up with at the time were all rather unwieldy. Taking your name as a base, I think we'd need something like queryLocaleChar(locale, code) or queryLocaleKey since we'd be returning the equivalent of the 'char' (or 'key') attribute. Thinking briefly about this now: * If we return 'char' equivalents, we won't return dead keys or other virtual keys. * If we return 'key' values, then we need to address how to handle non-printable keys like Shift and Home that people might expect to be translated. * I think we'll also want the ability to specify modifier keys to apply to the 'code' (to generate shifted or AltGr'ed versions). I'll formalize this a bit more and send something out for comments. -Gary
Re: Beacon API
From my perspective the point is that we should rather have a clear(er) definition of what we need, rather than starting to see how it fits into existing specs. Having this initial spec it will be also easier to decide about the actual fit into XHR or PING // Alois On 2/18/13 10:19 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Feb 16, 2013 at 11:36 AM, Reitbauer, Alois alois.reitba...@compuware.com wrote: The conversations this week were very helpful in deciding how to move forward. I second Jatinder's idea that we come up with a specification that describes in details what we need. We should also treat it as a separate specification. If we then see that it has enough commonalities with XHR and does not introduce unnecessary complexity we can still merge it. I also think that this is the most efficient way to move forward here. It's not entirely clear to me how we moved from we need a simple flag on XHR to lets create a whole new API... -- http://annevankesteren.nl/ The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Gebäude G.
Re: Beacon API
On Mon, Feb 18, 2013 at 4:10 PM, Reitbauer, Alois alois.reitba...@compuware.com wrote: From my perspective the point is that we should rather have a clear(er) definition of what we need, rather than starting to see how it fits into existing specs. Having this initial spec it will be also easier to decide about the actual fit into XHR or PING That sounds like a good idea. -- http://annevankesteren.nl/
[Bug 19470] Event firing sequence on abort() after send()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19470 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Anne ann...@annevk.nl --- Thanks Dominik! https://github.com/whatwg/xhr/commit/ff1071880b14f2d999877ff757c7d49d3f217de1 Filed https://bugzilla.mozilla.org/show_bug.cgi?id=842357 on Gecko. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents] Making the shadow root an Element
On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov dglaz...@google.com wrote: We were thinking of adding innerHTML to DocumentFragments anyway... right, Anne? Well I thought so, but that plan didn't work out at the end of the day. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694#c7 So given that consensus still putting it on ShadowRoot strikes me like a bad idea (as I think I've said somewhere in a bug). The same goes for various other members of ShadowRoot. I don't think there's a consensus really. JS authors were very vocal about needing this ability. Does anyone have a link to the strong case against adding explicit API for DF.innerHTML from Hixie that that comment refers to? / Jonas
Re: [webcomponents] Making the shadow root an Element
On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote: So given that consensus still putting it on ShadowRoot strikes me like a bad idea (as I think I've said somewhere in a bug). The same goes for various other members of ShadowRoot. I don't think there's a consensus really. JS authors were very vocal about needing this ability. Does anyone have a link to the strong case against adding explicit API for DF.innerHTML from Hixie that that comment refers to? I had the same question :) Also, I want to know better which part of _putting it on ShadowRoot_ strikes Anne as bad. I would like striking him at all, especially with something bad :P
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com wrote:
I'm not sure I buy the idea that two ways of doing the same thing does not
seem like a good approach - the web platform's imperative and declarative
duality is, by nature, two-way. Having two methods or an option that takes
multiple input types is not an empirical negative, you may argue it is an
ugly pattern, but that is largely subjective.
For what it's worth, I totally agree with Anne that two-prong API is a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.
Is this an accurate summary of what we're looking at for possible solutions?
If so, can we at least get a decision on whether or not _this_ route is
acceptable?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
created: CALLBACK
}
});
I will spec this first.
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
When we have implementers who can handle it, I'll spec that.
Eventually, we'll work to deprecate the first approach.
One thing that Scott suggested recently is that the second API variant
always returns undefined, to better separate the two APIs and their
usage patterns.
:DG
Re: [webcomponents] Making the shadow root an Element
On Mon, Feb 18, 2013 at 8:42 PM, Dimitri Glazkov dglaz...@google.com wrote: Also, I want to know better which part of _putting it on ShadowRoot_ strikes Anne as bad. I would like striking him at all, especially with something bad :P Mainly, if it's bad for DocumentFragment, it's bad for ShadowRoot too. I think the argument against innerHTML is the old string-based DOM manipulation is a bad idea. I don't really care strongly either way, but I do care that if we make a decision for DocumentFragment we apply it to ShadowRoot too. We should design this platform thingie somewhat coherently. -- http://annevankesteren.nl/
Re: [webcomponents] Making the shadow root an Element
On Mon, Feb 18, 2013 at 12:47 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Feb 18, 2013 at 8:42 PM, Dimitri Glazkov dglaz...@google.com wrote: Also, I want to know better which part of _putting it on ShadowRoot_ strikes Anne as bad. I would like striking him at all, especially with ^^^ would like TO AVOID striking him :) something bad :P Mainly, if it's bad for DocumentFragment, it's bad for ShadowRoot too. I think the argument against innerHTML is the old string-based DOM manipulation is a bad idea. I don't really care strongly either way, but I do care that if we make a decision for DocumentFragment we apply it to ShadowRoot too. We should design this platform thingie somewhat coherently. Still unclear. Are you saying this: if we have API members on ShadowRoot that aren't on DocumentFragment, then ShadowRoot should not be a DocumentFragment? :DG
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
I agree with your approach on staging the two specs for this, but the last
part about returning a constructor in one circumstance and undefined in the
other is something developers would rather not deal with (in my
observation). If I'm a downstream consumer or library author who's going to
wrap this function (or any function for that matter), I'd be a much happier
camper if I didn't have to think about handling different return values. Is
there a clear harm in returning a constructor reliably that would make us
want to diverge from an expected and reliable return value? It seems to me
that the unexpected return value will be far more annoying than a little
less mental separation between the two invocation setups.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com
wrote:
I'm not sure I buy the idea that two ways of doing the same thing does
not
seem like a good approach - the web platform's imperative and
declarative
duality is, by nature, two-way. Having two methods or an option that
takes
multiple input types is not an empirical negative, you may argue it is an
ugly pattern, but that is largely subjective.
For what it's worth, I totally agree with Anne that two-prong API is a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.
Is this an accurate summary of what we're looking at for possible
solutions?
If so, can we at least get a decision on whether or not _this_ route is
acceptable?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
created: CALLBACK
}
});
I will spec this first.
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
When we have implementers who can handle it, I'll spec that.
Eventually, we'll work to deprecate the first approach.
One thing that Scott suggested recently is that the second API variant
always returns undefined, to better separate the two APIs and their
usage patterns.
:DG
Re: [webcomponents] Making the shadow root an Element
On Mon, Feb 18, 2013 at 8:57 PM, Dimitri Glazkov dglaz...@google.com wrote: Still unclear. Are you saying this: if we have API members on ShadowRoot that aren't on DocumentFragment, then ShadowRoot should not be a DocumentFragment? No. all I'm saying that we made a conscious choice not to have innerHTML on DocumentFragment and that therefore we should not introduce it on ShadowRoot either (until we either revisit the DocumentFragment decision or someone shows that decision is not applicable to ShadowRoot somehow). -- http://annevankesteren.nl/
Re: [webcomponents] Making the shadow root an Element
On Mon, Feb 18, 2013 at 1:01 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Feb 18, 2013 at 8:57 PM, Dimitri Glazkov dglaz...@google.com wrote: Still unclear. Are you saying this: if we have API members on ShadowRoot that aren't on DocumentFragment, then ShadowRoot should not be a DocumentFragment? No. all I'm saying that we made a conscious choice not to have innerHTML on DocumentFragment and that therefore we should not introduce it on ShadowRoot either (until we either revisit the DocumentFragment decision or someone shows that decision is not applicable to ShadowRoot somehow). Ah, got it. Well... The innerHTML is necessary for ShadowRoot. It's not a matter of API taste or consistency. If you look at any shadow DOM code today (however experimental), you'll see most of it using innerHTML to populate the shadow tree. Perhaps you had an good analogous API in mind? :DG
Re: [webcomponents] Making the shadow root an Element
On Monday, February 18, 2013 at 10:12 PM, Dimitri Glazkov wrote: On Mon, Feb 18, 2013 at 1:01 PM, Anne van Kesteren ann...@annevk.nl (mailto:ann...@annevk.nl) wrote: On Mon, Feb 18, 2013 at 8:57 PM, Dimitri Glazkov dglaz...@google.com (mailto:dglaz...@google.com) wrote: Still unclear. Are you saying this: if we have API members on ShadowRoot that aren't on DocumentFragment, then ShadowRoot should not be a DocumentFragment? No. all I'm saying that we made a conscious choice not to have innerHTML on DocumentFragment and that therefore we should not introduce it on ShadowRoot either (until we either revisit the DocumentFragment decision or someone shows that decision is not applicable to ShadowRoot somehow). Ah, got it. Well... The innerHTML is necessary for ShadowRoot. It's not a matter of API taste or consistency. If you look at any shadow DOM code today (however experimental), you'll see most of it using innerHTML to populate the shadow tree. FWIW, one of the the most common use of doc fragment implies inserting a div into it to be able to use the div's innerHTML. For example, in jQuery: https://github.com/jquery/jquery/blob/master/src/manipulation.js#L452-L457 --tobie
FYI: JSON mailing list and BoF
* Joe Hildebrand (jhildebr) wrote: We're planning on doing a BoF in Orlando to discuss starting up a JSON working group. The BoF is currently planned for Monday afternoon at 1300 in Carribean 6. A very preliminary version of a charter can be found here: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON But obviously we'll need to build consensus on what it should actually contain. Please discuss on the j...@ietf.org mailing list: https://www.ietf.org/mailman/listinfo/json (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08912.html) -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
[editing] Is this the right list to discuss editing?
It looks like Editing API draft is currently abandoned and there isn't any activity on the topic in this list for a while (as far as I can find in the archives)... I am working on editing in IE, have issues of various scale that could benefit from a discussion in standards environment. Short of creating a new working group (which might be a good idea, but is pretty involved), is this the right forum to carry on a conversation? If not, any other suggestions? Thanks Alex
RE: [editing] Is this the right list to discuss editing?
Alex, work on Editing APIs was ongoing in the Community Group (http://www.w3.org/community/editing/) though their draft is just under a year old. Aryeh may have more current info... From: Alex Mogilevsky [mailto:alex...@microsoft.com] Sent: Monday, February 18, 2013 8:14 PM To: public-webapps@w3.org Subject: [editing] Is this the right list to discuss editing? It looks like Editing API draft is currently abandoned and there isn't any activity on the topic in this list for a while (as far as I can find in the archives)... I am working on editing in IE, have issues of various scale that could benefit from a discussion in standards environment. Short of creating a new working group (which might be a good idea, but is pretty involved), is this the right forum to carry on a conversation? If not, any other suggestions? Thanks Alex
RE: [editing] Is this the right list to discuss editing?
It is my understanding that Aryeh is currently not working on Editing API (https://plus.google.com/100662365103380396132/posts/KyADU8K54uK) and there is currently no successor or plan for further work... I would imagine there is still non-zero interest in the subject, would be good to have a place to discuss... From: Travis Leithead Sent: Monday, February 18, 2013 8:56 PM To: Alex Mogilevsky; Web Applications Working Group WG; Aryeh Gregor Subject: RE: [editing] Is this the right list to discuss editing? Alex, work on Editing APIs was ongoing in the Community Group (http://www.w3.org/community/editing/) though their draft is just under a year old. Aryeh may have more current info... From: Alex Mogilevsky [mailto:alex...@microsoft.com] Sent: Monday, February 18, 2013 8:14 PM To: public-webapps@w3.orgmailto:public-webapps@w3.org Subject: [editing] Is this the right list to discuss editing? It looks like Editing API draft is currently abandoned and there isn't any activity on the topic in this list for a while (as far as I can find in the archives)... I am working on editing in IE, have issues of various scale that could benefit from a discussion in standards environment. Short of creating a new working group (which might be a good idea, but is pretty involved), is this the right forum to carry on a conversation? If not, any other suggestions? Thanks Alex
Re: FYI: JSON mailing list and BoF
On Tue, Feb 19, 2013 at 12:19 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote: (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08912.html) Not sure this matters anymore as JavaScript has its own JSON definition which we use. -- http://annevankesteren.nl/
Re: [editing] Is this the right list to discuss editing?
On Tue, Feb 19, 2013 at 4:14 AM, Alex Mogilevsky alex...@microsoft.com wrote: I am working on editing in IE, have issues of various scale that could benefit from a discussion in standards environment. Short of creating a new working group (which might be a good idea, but is pretty involved), is this the right forum to carry on a conversation? If not, any other suggestions? I believe it still is, yes. (Although the draft does lack an editor and I believe one of the persons actively working on this stuff at Google moved elsewhere within that company.) -- http://annevankesteren.nl/
