[admin] Need a list for Extract Widget patent [Was: Re: PSA: Web Components vs Extract Widget patent]

2015-05-28 Thread Arthur Barstow
Rigo, Wendy, Jeff - I don't think it is appropriate to use WebApps' 
public-webapps list regarding Web Components vs Extract Widget patent 
[1]. What list should be used?

(FYI, Aymeric Vitte's original disclosure was forwarded to the list [1], 
and Aymeric's followups are [2] and [3]).

-Thanks, AB

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0692.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0697.html
[3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0782.html

RE: [ime-api] [blink-dev] Removing IME API code from Blink

2015-05-28 Thread Travis Leithead
That sounds good to me (working the UI challenges for IME together with 
grammar/spell checking). Is this a direction the current IME spec could 
take--possibly with a big refactor to consider dropping the ClientRect 
exposure--or would it be better to publish as Note the current approach and 
start a new spec?

Perhaps it doesn't really matter as the above is a process question, and what 
is really needed is someone to start suggesting some concrete proposals 
here--I've been pretty much ignoring this spec for the past year, and I don't 
see that changing in the near future. It's still something I'd like to see 
moved forward, I just don't believe I have the time to move it substantially 
forward at the present moment :)

-Original Message-
From: Ryosuke Niwa [mailto:rn...@apple.com] 
Sent: Wednesday, May 27, 2015 7:00 PM
To: Travis Leithead
Cc: Arthur Barstow; public-webapps
Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink

 On May 27, 2015, at 11:46 AM, Travis Leithead travis.leith...@microsoft.com 
 I believed the use-cases for avoiding UI clashes between site-driven 
 auto-complete lists and IME auto-complete boxes is still a valid use case, 
 and I think the spec is still valid to try to push to recommendation. 
 However, I'd also like to follow up on usage of the ms- prefixed API so that 
 I can get an idea of what its real usage is.

I agree avoiding UI clashes between auto-completions of IME and web page is a 
great use case but I'm not convinced that exposing ClientRect for IME is the 
right API as many Web developers aren't even aware of UI challenges IME 
imposes. For example, a similar UI challenge emerges when dealing with 
auto-corrections in grammar/spell checking features as well.  It would be ideal 
if IME and spell/grammar corrections are handled in a similar manner so that 
Web apps supporting either feature will just work with both features.

- R. Niwa

Re: PSA: Web Components vs Extract Widget patent

2015-05-28 Thread Aymeric Vitte
Please see https://gist.github.com/Ayms/64dfd60ddae05aeaff4e

This is a brief code comparison between the extract widget projects from
the patent and the Polymer project.

Since we knew exactly what we had to look for, we found it, the
conclusion is:

Not seeing obvious similitudes between the Polymer and the EW code,
therefore between the Web Components and the patent, or arguing that
these are standard practices while we see that today it's still
difficult to accomplish and that we still need to hack the entire DOM
all possible ways to do it, as well as performing very strange and not
usual manipulations, could only be the result of very bad faith.

Hopefully the DOM hacking will stop when the specs will be implemented
inside browsers.

Probably the next step is to link to how we have set in 2007 a
template-like element associated with a framework implementing some
HTML5 features, before HTML5.

There is a logic between all our projects and their history, same as the
Web Components logic.

Instead of trying to refute the creativity and innovation of the patent,
maybe we should make it happen the way it was intended to, please see
the Note in the gist.

Maybe it should become obvious too that if we can import and construct a
shadow domed web component, we can extract it the same way, that's the
same thing.



Le 22/05/2015 00:01, Aymeric Vitte a écrit :
 Since this is public now for everybody, please let me give some
 additional information.
 We think that the extraction mechanisms described in the patent and not
 covered by any spec will happen one day too, and could be integrated in
 the Web Components spec, the purpose being to extract a customized
 custom element from any site, not only from the constructor site, it's
 probably very simple to specify now, if there is some interest we could
 participate to this.
 From a technical standpoint, please see below everything we have written
 about the obvious similitudes between the patent (2010) and the Web
 Components (2012), as well as the widget-like projects (2013/2014).
 If someone finds some anteriority, then please advise, this is what we
 have been asking for since 6 months, but please read what follows before.
 The enormous difference between what describes the patent and all
 existing technologies when we issued it is that all existing
 technologies were producing gadgets:
 - that were sandboxed (iframes for example) and could not interact with
 the other elements of the web page where they were injected
 - that were displayed alone
 - that needed some specific format, development skills or tools (like
 browsers, frameworks, apis) to be created and displayed
 - that could not necessarily render or adapt on any devices, like mobiles
 To my knowledge, at that time no project never envisioned at any moment
 any gadgets that could be integrated into a web page as normal browser
 elements (ie DOM elements) on any device possibly interacting with the
 other browser elements of the page while keeping their own properties
 not interfering between each others, which is very exactly what the
 patent describes and what the Web Components are about.
 One of the reason probably is that this was extraordinarly complicate to
 perform at that time, like for our past projects which were difficult to
 implement, and still is today, except if we use the Web Components or
 widget-like concepts of today helped by the improvements brought by
 ES6/7 and HTML.
 The patent describes an universal method to accomplish the above and the
 definition of a gadget in the patent is very clear regarding its
 ability to interact with the rest of the page.
 I have tried to detail all this and performed a detailed comparison with
 the Web Components and widget-like projects here:
 - Main claim, scope and applications
 Which shows that not only Web Components are impacted, but all
 widget-like projects, thousands of projects, and soon or later all projects.
 and here:
 -Extract Widget Patent FR2962237 - Process to create an application of
 gadget type incorporated into a container of widget type -
 The second gist is a bit long and the translation of the patent probably
 not perfect, beside the detailed comparison for each claim of the patent
 with the Web Components, the most interesting section is probably: The
 patent vs the traditional approach = Web Components
 Regarding a possible solution, to make it short, since now 6 months
 (realizing at last that all the components projects were infringing the
 patent) we have stated that we would like to find an agreement so we
 transfer the rights of the patent to the W3C members and they sublicense
 it royalty free for everybody via the W3C.
 This agreement should cover at least 

Re: CfC: Moving webstorage to REC 2nd Edition; deadline May 21

2015-05-28 Thread Xiaoqian Wu
Hi Art, and all,

I believe we have enough review on the current editor's draft to publish 
directly a CR. We don't need to do the extra WD step. If implementors or others 
have additional comments, they can do so during the CR phase. So I propose that 
we publish a CR directly.



 On 2015-5-14, at 7:30pm, Arthur Barstow art.bars...@gmail.com wrote:
 Hi All,
 Based on Xiaoqian's analysis [1] of Web Storage changes since the REC was 
 published in 2013, this is a Call for Consensus to:
 1. Publish a new WD of the spec and to seek wide review of the spec, per 
 process 2014. The new WD will be placed in w3.org/TR/webstorage/. The draft 
 WD is [2] and the review period will be three weeks. The draft includes a 
 summary of the changes since the REC was published [3].
 2. Update the REC errata doc [4] to include a reference to the new WD and its 
 changes since REC section, and the github commit history.
 If you have any comments or concerns about this CfC, please reply by May 21 
 at the latest. Silence will be considered as agreeing with the proposal and 
 explicit responses are preferred. If no non-resolvable blocking issues are 
 raised, this CfC will be considered as passing and we will proceed with this 
 -Thanks, ArtB
 [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0607.html
 [2] https://w3c.github.io/webstorage/
 [3] https://w3c.github.io/webstorage/#status-of-this-document
 [4] http://dev.w3.org/html5/webstorage/publish/errata-v1.html