Canceled: CfC: publish LCWD of DOM Parsing and Serialization; deadline November 25
I'll restart the CfC when Travis is ready. From: ext Travis Leitheadmailto:travis.leith...@microsoft.com Sent: 11/18/2013 2:28 PM To: Webapps WGmailto:public-webapps@w3.org Subject: RE: publish LCWD of DOM Parsing and Serialization; deadline November 25 If possible, I'd like to delay this CfC, for a week--I have some major updates to the ED in-flight, and I want to make sure we base the CfC on the right ED content :-) Hopefully this is workable to the group. Thanks! - From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, November 18, 2013 4:00 AM This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and Serialization, using the following ED as the basis: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Currently, this spec has one Editorial bug [18939] that is open and Travis will fix this before the LCWD is published. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by November 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period for this LC is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, please let me know. -Thanks, AB [18939] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938 Original Message Subject: ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) Date:Mon, 11 Nov 2013 01:59:39 + 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-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/701 On: Arthur Barstow Due: 2013-11-18 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: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax
Dimitri - yes, timeanddate.com agrees: 09:30 Shenzhen = 10:30 Tokyo = 17:30 San
Francisco. The pin will be 9274# and we will use the #webapps channel.
-TTYS, ArtB
Sent from my Windows Phone
From: ext Dimitri Glazkovmailto:dglaz...@chromium.org
Sent: 11/12/2013 8:13 AM
To: Barstow Art (Nokia-CIC/Boston)mailto:art.bars...@nokia.com
Cc: ext Ryosuke Niwamailto:rn...@apple.com; Dominic
Cooneymailto:domin...@chromium.org; public-webapps@w3.org
WGmailto:public-webapps@w3.org; Elliott Sprehnmailto:espr...@gmail.com
Subject: Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative
Syntax
On Sun, Nov 10, 2013 at 6:49 PM, Arthur Barstow
art.bars...@nokia.commailto:art.bars...@nokia.com wrote:
Hi Dimitri, Dominic,
Ryosuke is here in Shezhen at WebApps' f2f meeting. We would like to have one
or both of you join us (via voice conference) on Tuesday morning to talk about
Web Components and his comments below.
Please look at the agenda page and let us know your availability for the one of
the open slots before lunch (all times are local to Shenzhen):
http://www.w3.org/wiki/Webapps/November2013Meeting#Agenda_Tuesday_November_12
I dropped something at 9:30am. I think that's 5:30pm Mountain View and 10:30am
Tokyo, right?
-Thanks, ArtB
On 11/9/13 3:24 AM, ext Ryosuke Niwa wrote:
Hi all,
We have been discussing cross-orign use case and declarative syntax of web
components internally at Apple, and here are our straw man proposal to amend
the existing Web Components specifications to support it.
*1. Modify HTML Imports to run scripts in the imported document itself*
This allows the importee and the importer to not share the same script context,
etc…
This could be an option and shouldn’t be the default. By running scripts in a
different context, we are ejecting the primary use case of enabling
frameworks/libraries to better manage their assets and dependencies (aka the
Bootstrap use case).
Rob Dodson’s article has a nice progression explaining the use case:
http://robdodson.me/blog/2013/08/20/exploring-html-imports/
Also, check out newly minted Eric Bidelman's article on imports (especially the
use cases section at the bottom):
http://www.html5rocks.com/en/tutorials/webcomponents/imports/
Re: Custom Elements LC, this is an issue to handle in HTML Imports
specification, not related to Custom Elements.
*2. Add “importcomponents content attribute on link element*
It defines the list of custom element tag names to be imported from the
imported HTML document.
e.g. link rel=import href=~ importcomponents=tag-1 tag-2 will export
custom elements of tag names tag-1 and tag-2 from ~. Any name that didn't
have a definition in the import document is ignored (i.e. if tag-2 was not
defined in ~, it would be skipped but tag-1 will be still imported).
This mechanism prevents the imported document from defining arbitrary
components in the host document.
Re: Custom Elements LC, this should be handled in HTML Imports specification.
HTML Imports can rely on Custom Elements specification. Any additional hooks
that could be needed to facilitate this feature could be added in Custom
Elements Level 2 specification.
*3. Support static (write-once) binding of a HTML template*
e.g.
template id=cardTemplateName: {{name}}brEmail:{{email}}/template
script
document.body.appendChild(cardTemplate.instantiate({name: Ryosuke Niwa,
email:rn...@webkit.orgmailto:rn...@webkit.org
mailto:rn...@webkit.orgmailto:rn...@webkit.org}));
/script
This seems very similar to the Rafael Weinstein's MDV work. You guys should
collaborate :)
Re: Custom Elements LC, this is unrelated to specification.
*4. Add “interface content attribute to template element*
This content attribute specifies the name of the JavaScript constructor
function to be created in the global scope. The UA creates one and will be used
to instantiate a given custom element. The author can then setup the prototype
chain as needed:
template defines=name-card interface=NameCardElement
Name: {{name}}brEmail:{{email}}
/template
script
NameCardElement.prototype.namehttp://NameCardElement.prototype.name =
function () {...}
NameCardElement.prototype.email = function () {...}
/script
This is similar to doing:
var NameCardElement = document.register(’name-card');
This is another take on the declarative custom elements (a variant of [1]).
This particular approach has four problems that the WG was able to resolve (at
least the first three) in previous iterations:
1) It is not friendly to ES6 classes. In fact, you can't use class syntax and
this syntax together.
2) It couples templates, shadow DOM, and custom elements in a way that's highly
opinionated and inflexible. Throughout this year, we've tried many various ways
to get this right, and failed [2]. I highly recommend that we avoid putting
this into a specification now. Instead, we should let the best practices evolve
and build on the cowpaths.
RE: TAG Comment on
From: ext Glenn Adams [gl...@skynav.com] Could you quantify widely? I think this definition of widely used is useful for this context: http://caniuse.com/#search=storage Personally, I see little to negative value in ignoring the fact the ship has sailed for this spec. -AB On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.commailto:w...@adambarth.com wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility.
FW: TPAC Web App
From: ext Dominique Hazael-Massieux [d...@w3.org] Sent: Monday, October 31, 2011 9:25 AM To: w...@w3.org; cha...@w3.org Subject: TPAC Web App Dear all, For those of you at TPAC, you may want to use the companion Web app to the event available at: http://www.w3.org/2011/11/TPAC/live/ and let others know about it. That Web app lets you access the schedule of the week, pick which meetings you plan on attending to build your own schedule, and let others know in what meetings room you are currently setting via check-in, as well as orient yourself in the meeting facilities. It also features the list of registrants and their organizations to facilitate establishing contacts. This is very much an alpha-release of the tool, but we hope that you'll find useful during the week; learn more about the tool and the team behind it at http://www.w3.org/2011/11/TPAC/live/about Dom
RE: [IndexedDB] Editors
Nikunj, Jonas, All, Chaals, the Team and I all support this proposal. Thanks to you both! -Art Barstow From: public-webapps-requ...@w3.org [public-webapps-requ...@w3.org] On Behalf Of ext Nikunj Mehta [nik...@o-micron.com] Sent: Tuesday, July 06, 2010 12:39 PM To: public-webapps Subject: [IndexedDB] Editors Hi folks, I would like to propose adding Jonas Sicking to the list of editors for the IndexedDB spec. Many of you have seen the tremendous amount of work Jonas has done to assist in finalizing the asynchronous API as well as providing implementation feedback. I hope the WG will support this change. Best, Nikunj
