Re: CFC: Republish Pointer Lock as CR
I'm fine without Shadow DOM changes, because no one yet implemented the intended change to the spec yet, and so it could be immature to include in a "CR". (Does CR require at least 2 implementors exist?) On Tue, Jun 21, 2016 at 1:09 PM, Vincent Scheib <sch...@google.com> wrote: > I've discussed more with Xiaoqian and Léonie and support a CR now with > this proposal: > > Move to a CR for the v1 Pointer Lock specification without Shadow DOM > changes, and a note on accessibility. Implementations are nearly consistent > for v1 and it can move to a published status sooner. We can follow up with > a v2 requiring more implementation work afterwards. > > -- Takayoshi Kochi
Re: CFC: Republish Pointer Lock as CR
I'm working on updating text to incorporate Shadow DOM in pointer lock spec. https://github.com/w3c/webcomponents/issues/192 On Thu, Jun 16, 2016 at 2:06 PM, Vincent Scheib <sch...@google.com> wrote: > Shadow dom concepts will also be incorporated. > > On Thu, Jun 16, 2016 at 1:43 PM, Chaals McCathie Nevile < > cha...@yandex-team.ru> wrote: > >> On Thu, 16 Jun 2016 12:33:30 +0200, Vincent Scheib <sch...@google.com> >> wrote: >> >> An accessibility review and handling of this [accessibility issue #1] are >>> still needed and will likely cause a CR cycle. To avoid unnecessary work >>> I propose CR to be deferred until that work is complete. >>> >>> [accessibility issue #1] https://github.com/w3c/pointerlock/issues/1 >>> >> >> Agreed, that makes good sense. I'll try to help that get done as fast as >> we can. >> >> cheers >> >> >> On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell <dylan.barr...@deque.com> >>> wrote: >>> >>> abstain >>>> >>>> On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl <mich...@agosto.nl> >>>> wrote: >>>> >>>> Looks good, +1 >>>>> >>>>> —Michiel >>>>> >>>>> On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk> wrote: >>>>> >>>>> Hello WP, >>>>> >>>>> This is a Call For Consensus (CFC) to request that W3C republish >>>>> Pointer >>>>> Lock as a Candidate Recommendation (CR). Extensions to the >>>>> MouseEventInit >>>>> Dictionary [1] constitute substantive changes to the specification that >>>>> were >>>>> made after the current CR was published in 2013 [2]. >>>>> >>>>> Please reply to this CFC no later than 21st June 2016. Positive >>>>> responses >>>>> are preferred and supporting comments (beyond just +1) are encouraged, >>>>> but >>>>> silence will be considered as consent. >>>>> >>>>> Thank you. >>>>> >>>>> Léonie on behalf of the WP chairs and team, and Pointer Lock editor. >>>>> [1] >>>>> >>>>> >>>>> https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona >>>>> ry >>>>> [2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/ >>>>> -- >>>>> @LeonieWatson tink.uk Carpe diem >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Download the aXe browser extension for free: >>>> >>>> Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools >>>> Chrome: >>>> >>>> https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US >>>> >>>> Life is ten percent what happens to you and ninety percent how you >>>> respond >>>> to it. - Lou Holtz >>>> >>>> >>>> >> >> -- >> Charles McCathie Nevile - web standards - CTO Office, Yandex >> cha...@yandex-team.ru - - - Find more at http://yandex.com >> >> > -- Takayoshi Kochi
Re: [Custom Elements] Not requiring hyphens in names.
Just FYI, the idea of allowing non-hyphen elements if they contain
non-ASCII characters
which probably won't collide with future HTML elements was posted in the
discussion:
https://github.com/w3c/webcomponents/issues/239#issuecomment-190603674
On Fri, Apr 15, 2016 at 7:01 AM, /#!/JoePea <trus...@gmail.com> wrote:
> On Wed, Apr 13, 2016 at 1:09 PM, Tab Atkins Jr. <jackalm...@gmail.com>
> wrote:
> > That means we lose the lingua franca that HTML provides; two
> > independent libraries can't ever depend on the core HTML elements,
> > because the other library might have overridden some of them.
>
> Based on my idea of registering elements on a per-shadow-root basis
> (
> https://discourse.wicg.io/t/proposal-register-custom-elements-onto-shadowdom-roots/1440
> ),
> then libraries could use any native or custom elements that they want
> within their shadow roots. Shadow roots would provide encapsulation,
> and element registrations would be scoped to those shadow roots.
>
> There are two possible ways to deal with element registrations on the
> `document`:
>
> 1. Either elements registered on the `document` have effect across
> shadow roots, but shadow roots can override these registrations:
>
> ```js
> document.registerElement('foo-bar', SomeClass)
> // ...
> shadowRoot.registerElement('foo-bar', OtherClass) // takes precedence
> over the document registration.
> ```
>
> 2. Or, document registrations simply wouldn't cross the shadow root
> boundary.
>
> I personally like the second option, leaving maximum control in the
> hands of the developer, regardless of some global script registering
> an element on the document that may encroach the scope of a shadow
> root. If a shadow root author really wants the same element, there's
> slightly more effort to also register that element with the shadow
> root, but the overall control outweighs this extra effort in my
> opinion.
>
> Then, if we add the ability to override native elements, we'll have
> something powerful, IMO.
>
> ```js
> // file1.js
> import BetterImageWithWebGLFilters from 'better-img'
> document.registerElement('img', BetterImageWithWebGLFilters)
>
> // file2.js
> let s = el.createShadowRoot()
> s.appendChild(document.createElement('img')) // uses native
> HTMLImageElement because document registration stops at shadow root
> boundary.
>
> // file3.js
> import BetterImageWithWebGLFilters from 'better-img'
> let s = el.createShadowRoot()
> s.registerElement('img', BetterImageWithWebGLFilters)
> s.appendChild(document.createElement('img')) // this person wants
> BetterImageWithWebGLFilters in their shadow root
>
> // file4.js
> let s = el.createShadowRoot()
> s.registerElement('div', AwesomeClass) // this does not affect other
> shadow roots or the document, it's contained within the shadow root.
> ```
>
> This would be awesome I think. It'd allow for a level of encapsulation
> and modularization on a shadow-root basis (which can paired with
> Custom Elements very nicely).
>
> /#!/JoePea
>
>
--
Takayoshi Kochi
Re: Telecon / meeting on first week of April for Web Components
I will join remotely via webex. On Tue, Mar 15, 2016 at 7:08 PM, Léonie Watson <t...@tink.uk> wrote: > For a telecon, we can create a WebEx instance if that would be useful? Let > me know the date/time (UTC), and we'll get it sorted. > > For an F2F, we'll need to post notice of the date/venue at least eight > weeks > in advance [1]. Let me know the date(s)/venue, and we can do that too. > > Léonie. > [1] > https://lists.w3.org/Archives/Public/public-webapps/2016JanMar/0043.html > > > > -Original Message- > > From: rn...@apple.com [mailto:rn...@apple.com] > > Sent: 14 March 2016 23:56 > > To: t...@tink.uk; Chaals McCathie Nevile <cha...@yandex-team.ru> > > Cc: public-webapps <public-webapps@w3.org> > > Subject: Telecon / meeting on first week of April for Web Components > > > > Hi all, > > > > We've been making a good progress on shadow DOM and custom elements > > API but there seems to be a lot of open questions still. I've asked a > couple of > > people involved in the discussion, and there seems to be an interest for > > having another tele-conference or an in-person meeting. > > > > Can we schedule one in the second week of April (April 4th through 8th)? > > > > - R. Niwa > > > > -- Takayoshi Kochi
