[admin] WebApps' next f2f meeting is Nov 11-12 @ TPAC in Shenzhen China
As discussed during last week's f2f meeting, WebApps will meet on November 11-12 (Monday and Tuesday) at the annual TPAC meeting week, which is in Shenzhen China this year: http://www.w3.org/2013/11/TPAC/ WebApps meeting and agenda page is currently just a skeleton http://www.w3.org/wiki/Webapps/November2013Meeting. Hope to see everyone there. -Regards, Art, Chaals and Yves Original Message Subject: ACTION-692: Announce the WG will meet during TPAC 2013 in November (Web Applications Working Group) Date: Fri, 26 Apr 2013 16:11:33 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-692: Announce the WG will meet during TPAC 2013 in November (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/692 On: Arthur Barstow Due: 2013-05-03 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
RE: publish FPWD of UI Events; deadline May 4
Microsoft supports this. -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Saturday, April 27, 2013 7:31 AM To: public-webapps Subject: CfC: publish FPWD of UI Events; deadline May 4 As discussed during WebApps' April 25 meeting, this is a Call for Consensus to publish a First Public Working Draft of the UI Events spec using the following ED as the basis: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does _not_ necessarily mean there is consensus on the spec's contents. If you have any comments or concerns about this CfC, please reply to this e-mail by May 4 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. -Thanks, AB Original Message Subject:ACTION-682: Start a CfC for FPWD of UI Events (and make sure it has a Bugzilla component) (Web Applications Working Group) Date: Thu, 25 Apr 2013 17:29:27 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-682: Start a CfC for FPWD of UI Events (and make sure it has a Bugzilla component) (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/682 On: Arthur Barstow Due: 2013-05-02 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
Proposal for a DOM L3 Events Telecon
I’d like to propose we start a call to begin to work toward resolving the final bugs in the spec and for other business related to getting DOM L3 Events to CR. On the call we can workout what subsequent meetings we should also arrange. Does next Tuesday (May 7th), at 11 am PST work your you? If not, I’m open to suggestions! -Travis
Multiple Decorators
Hi,
I noticed that there's not any clarification in the Decorations spec about
applying multiple decorators to a single element.
Example:
.headline[access-type=premium] {
decorator: url(#premium-decorator);
}
.headline[content-type=video] {
decorator: url(#video-decorator);
}
h3 class=headline content-type=video access-type=premiumHeadline
Title/h3
What would be expected? Would the #video-decorator be applied, passing its
result to the #premium-decorator in the content tag? Would only one be
applied? If so, which one?
-sam
Re: Multiple Decorators
On Mon, Apr 29, 2013 at 1:07 PM, Sam L'ecuyer s...@cateches.is wrote:
I noticed that there's not any clarification in the Decorations spec about
applying multiple decorators to a single element.
Example:
.headline[access-type=premium] {
decorator: url(#premium-decorator);
}
.headline[content-type=video] {
decorator: url(#video-decorator);
}
h3 class=headline content-type=video access-type=premiumHeadline
Title/h3
What would be expected? Would the #video-decorator be applied, passing its
result to the #premium-decorator in the content tag? Would only one be
applied? If so, which one?
Per standard CSS rules, the latter declaration would win in the
cascade, and so only #video-decorator would be applied. If
'decorator' can apply multiple values, they have to be done in a
single line, not across declarations like this.
(This is a common failure mode for list-valued properties. Fixing it is hard.)
~TJ
Re: Multiple Decorators
Per standard CSS rules, the latter declaration would win in the cascade, and so only #video-decorator would be applied. If 'decorator' can apply multiple values, they have to be done in a single line, not across declarations like this. That's what I assumed. I was mostly trying to clarify for a discussion that was going on in the www-style list about pseudo-elements decorators. -s
Re: Proposal for a DOM L3 Events Telecon
On Mon, Apr 29, 2013 at 12:59 PM, Travis Leithead travis.leith...@microsoft.com wrote: I’d like to propose we start a call to begin to work toward resolving the final bugs in the spec and for other business related to getting DOM L3 Events to CR. On the call we can workout what subsequent meetings we should also arrange. ** ** Does next Tuesday (May 7th), at 11 am PST work your you? sgtm
Re: publish FPWD of UI Events; deadline May 4
Google supports this. On Mon, Apr 29, 2013 at 11:03 AM, Travis Leithead travis.leith...@microsoft.com wrote: Microsoft supports this. -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Saturday, April 27, 2013 7:31 AM To: public-webapps Subject: CfC: publish FPWD of UI Events; deadline May 4 As discussed during WebApps' April 25 meeting, this is a Call for Consensus to publish a First Public Working Draft of the UI Events spec using the following ED as the basis: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does _not_ necessarily mean there is consensus on the spec's contents. If you have any comments or concerns about this CfC, please reply to this e-mail by May 4 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. -Thanks, AB Original Message Subject:ACTION-682: Start a CfC for FPWD of UI Events (and make sure it has a Bugzilla component) (Web Applications Working Group) Date: Thu, 25 Apr 2013 17:29:27 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-682: Start a CfC for FPWD of UI Events (and make sure it has a Bugzilla component) (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/682 On: Arthur Barstow Due: 2013-05-02 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
Hi Ted! Thanks for the kudos. We Shadow DOM elves are hard at work on making the world a better place :) I think you're raising good questions. I am sensitive of the fact that you are just starting the journey into the shadows and volunteer to be your Aragorn. Yes, Shadow DOM is fairly complex, but it is also the minimal set of machinery that is actually useful. We elves had gone through the extensive process of making sure of that. If we take away multiple insertion points, we significantly reduce authors' ability to build useful controls. For example, the control that uses insertion points in WebKit now is the details element, which needs two. So would a properly implemented fieldset (https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#html-elements-and-their-shadow-trees). If you're planning to build an accordion, you need more than one insertion point (https://github.com/dglazkov/Web-Components-Polyfill/blob/master/samples/accordion/accordion-component.html). Same for even the simplest tab view control, let alone the one that manages tab overflow (https://github.com/dglazkov/Web-Components-Polyfill/blob/master/samples/tabs/tabs-component.html) As Scott pointed out in his succinct reply, removing multiple insertion points does not eliminate the need for reprojection. In our elvish experience, it took literally seconds for control authors to write this code: button is=my-funky-button content/content /button At which point, the lack of reprojection bites the author in the rear soft tissue. As far as implementation complexity, content select, distribution APIs, and shadow are trivial, compared to the event handling and representation of the composed tree. Hoping to alleviate this, I wrote all event-related handling as imperatively as I could. One thing where we could definitely help the implementers is in uncondensing the spec. I think today's spec, though technically correct, is way too dense and is in need of good refactoring. I am planning to tackle this very soon and would appreciate any contributions. Thanks again! :DG
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
On Mon, Apr 29, 2013 at 3:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: As far as implementation complexity, content select, distribution APIs, and shadow are trivial, compared to the event handling and representation of the composed tree. Hoping to alleviate this, I wrote all event-related handling as imperatively as I could. While I agree that specifying content select, distribution APIs, and shadow is relatively simpler than some of the other parts of the spec, I'm pretty worried right now about the performance of those features, especially for dynamic changes. I just found out, as well, that Mozilla's XBL implementation of these features worked correctly in the static case, but is completely wrong in the dynamic case, so we don't have any real data on how slow doing that stuff correctly is. -- Blake Kaplan
[Bug 21555] Use of IDL arrays for keyPath values is underdefined
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21555 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Joshua Bell jsb...@google.com --- (In reply to comment #14) IIRC the tone of the F2F http://www.w3.org/wiki/Webapps/April2013Meeting correctly, we agreed to revert the spec's IDL here to any and define the behavior in prose. If that sounds reasonable, I'll make the spec changes: * IDL type of the attributes -- any * Prose defined return type as String or Array of Strings * Prose defines that the same object is returned on each access I've gone ahead and made this change in these revisions: https://dvcs.w3.org/hg/IndexedDB/rev/43e59fb2e864 https://dvcs.w3.org/hg/IndexedDB/rev/6671aff10209 (copy/paste fix) Boris - sanity check please? -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
On Mon, Apr 29, 2013 at 3:14 PM, Blake Kaplan mrb...@gmail.com wrote: On Mon, Apr 29, 2013 at 3:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: As far as implementation complexity, content select, distribution APIs, and shadow are trivial, compared to the event handling and representation of the composed tree. Hoping to alleviate this, I wrote all event-related handling as imperatively as I could. While I agree that specifying content select, distribution APIs, and shadow is relatively simpler than some of the other parts of the spec, I'm pretty worried right now about the performance of those features, especially for dynamic changes. I just found out, as well, that Mozilla's XBL implementation of these features worked correctly in the static case, but is completely wrong in the dynamic case, so we don't have any real data on how slow doing that stuff correctly is. Distribution-as-specified, with its reprojection and such, will definitely incur some performance penalties. However, we've worked through the alternatives, and there aren't any that aren't simple terrible. Literally every thing we tried to find that doesn't involve reprojection instead involves losing the ability to arbitrarily compose, and when you *do* compose, you need to write some truly terrible selectors to make things work right. ~TJ
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
On Mon, Apr 29, 2013 at 3:26 PM, Dimitri Glazkov dglaz...@chromium.org wrote: I wonder if it would be helpful for me to specify exactly where the distribution/composition integrity must be ensured (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20141)? This should help implementers to build a well-performing implementation. While that'd certainly be useful, it won't reduce the amount of work that we need to do on node insertion and appending. I think we're basically going to have to implement it and measure... I wasn't trying to say that it's definitely going to be a problem, just that it's a concern. -- Blake Kaplan
Prefer Error than exception for DataCloneError and DataError
In put and add method of object store and index, DataCloneError and DataError are immediately throw before executing IDBRequest. It seems good that exception are throw immediately, but in practical use case, these exception are in async workflow (inside transaction callback). Exception break the async workflow, depending on usage design pattern. Alternatively, these exception could transform into IDBRequest.onerror event. In this ways, we can gracefully handle such unexpected error.
