nobody | 28 Jul 09:32 2015
Picon

[Bug 27674] requestFullscreen should return a promise

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27674
Bug 27674 depends on bug 26440, which changed state.

Bug 26440 Summary: Allow fullscreenchange events to be synchronized with animation frames
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[clipboard] navigator.registerClipboardFormats( ... )

Hi,
there's an interesting proposal here
https://github.com/w3c/clipboard-apis/issues/9
for solving our "what about clipboard data from various native applications?" conundrum. The proposal is to let a page indicate what native clipboard identifiers it is interested in handling:

registerClipboardFormats({
   "application/vnd.mathsoft.equation+xml":[
        "XMCD Format", //Windows handle
        "MCD Format", //old Windows handle with the same format
        "XMCD_FORMAT", //Linux handle
        "com.mathsoft.xml"], // OSX handle
   "application/vnd.mathsoft.equation.meta+xml":[
        "Provenance Data", //windows handle
        "PROVENANCE_DATA", //Linux handle
        "com.mathsoft.pd"] // OSX handle
});
//returns:
//{
//   "application/vnd.mathsoft.equation+xml":true,
//   "application/vnd.mathsoft.equation.meta+xml":true
//}

And my current understanding of how this work work is https://github.com/w3c/clipboard-apis/issues/9#issuecomment-123829662 :

What happens "under the hood" here is basically:

The UA has a registry mapping the supported native clipboard types to the MIME types used for the clipboard API. For example, on Windows one of the entries is probably 'text/html' -> 'CF_HTML'
When registerClipboardFormat() is called, for each MIME type (key) in the dictionary, it will check with the OS if the native clipboard knows about each format description on the list.
The first matching format description the OS has registered (if any) will be added to the mapping table

On reading from the clipboard, all data with the descriptions given in our mapping table will be exposed to JS with the corresponding MIME type.

On writing to the clipboard, all data with a MIME type listed in the mapping table will be placed on the clipboard with the corresponding native description.

Right?

I'm not sure if implementors are happy about this. There's some pushback against allowing web contents to write binary data to the clipboard for security reasons - if you have vulnerabilities in local software (which is of course a when, not an if) an attacker can trick you into pasting some exploit payload into the vulnerable software.

Also, I know that on Windows applications "register" their clipboard formats - how does this work on other platforms? Will the OSX clipboard be able to confirm that "com.mathsoft.xml" is a "known" type when the relevant software is installed?

Comments welcome here or in the Github issue.
-Hallvord R.
editor of https://w3c.github.io/clipboard-apis/
Picon

WebApps-ACTION-757: Collect the various minutes and make them as coherent as the reality of the meeting.

WebApps-ACTION-757: Collect the various minutes and make them as coherent as the reality of the meeting.

http://www.w3.org/2008/webapps/track/actions/757

Assigned to: Charles McCathie Nevile

Michael[tm] Smith | 21 Jul 07:10 2015
Picon

RE-SENDING [Apple's updated feedback on Custom Elements and Shadow DOM]

I’m re-sending the following message from Maciej because I received a
report that some members of the list didn’t receive it when he sent it

However, note that it did reach the list, because it’s already archived at
https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0204.html

----- Forwarded message from Maciej Stachowiak <mjs@...> -----

From: Maciej Stachowiak <mjs@...>
Date: Mon, 20 Jul 2015 18:17:24 -0700
To: public-webapps <public-webapps@...>
Archived-At: <http://www.w3.org/mid/E9841AA1-9255-4324-946E-E785B15DAE93 <at> apple.com>
Subject: Apple's updated feedback on Custom Elements and Shadow DOM

A while back we sent a consolidated pile of feedback on the Web Components family of specs. In preparation
for tomorrow's F2F, here is an update on our positions. We've also changed the bugzilla links to point to
relevant github issues instead.

We're only covering Custom Elements (the main expected topic), and also Shadow DOM (in case that gets
discussed too).

I. ==== Custom Elements ====

	A. ES6 classes / Upgrade / Synchronous Constructors
		1. In general, we support the "synchronous constructors" approach to the "prototype swizzling"
approach, as the lesser evil. While tricky to implement correctly, it makes a lot more sense and fits more
naturally into the language. We are willing to do the work to make it feasible.
		2. Custom elements should support initialization using an ES6 class constructo instead of a separate
callback. <https://github.com/w3c/webcomponents/issues/139 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=28541>>
		3. We don’t think upgrading should be supported. The tradeoffs of different options have been
much-discussed. <https://github.com/w3c/webcomponents/issues/134 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544>>
		4. Specifically, we don't really like the "Optional Upgrades, Optional Constructors" proposal (seems
like it's the worst of both worlds in terms of complexity and weirdness) or the "Parser-Created Classes"
proposal (not clear how this even solves the problem).

	B. Insertion/Removal Callbacks
		1. We think the current attached/detached callbacks should be removed. They don’t match core DOM
concepts and insert/remove is a more natural bracket. The primitives should be insertedIntoDocument /
removedFromDocument and inserted / removed. If you care about whether your document is rendered, look at
its defaultView property. <https://github.com/w3c/webcomponents/issues/286>
		2. We think inserted/removed callbacks should be added, for alignment with DOM. <https://github.com/w3c/webcomponents/issues/222>

	C. Inheritance for Built-ins
		1. We think support for inheritance from built-in elements (other than HTMLElement/SVGElement)
should be omitted from a cross-browser v1. It raises complex implementation issues.
<https://github.com/w3c/webcomponents/issues/133 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=28547>>

	D. Syntactic Sugar / Developer Ergonomics
		1. We think it would be useful (perhaps post-v1) to make it simpler to create a custom element that is
always instantiated with a shadow DOM from a template. Right now, this common use case requires script and
a template in separate places, and a few lines of confusing boilerplate code.
<https://github.com/w3c/webcomponents/issues/135 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546>>
		2. We think at some point (perhaps post-V1), there should be a convenient declarative syntax that
combines script and a template to define a custom element. JavaScript frameworks on top of web components
provide something like this. Perhaps with field experience we can make a standardized common syntax. <https://github.com/w3c/webcomponents/issues/136>

	E. Renaming the API
		1. We’re still not wholly sold on document.registerElement as a name. We like document.define or
document.defineElement. At minimum, we’d like the WG to decide on the name instead of just leaving it at
the editor’s initial decision. We can probably live with this not changing though.
<https://github.com/w3c/webcomponents/issues/140 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24087>>
		2. If anything about Custom Elements is changed incompatibly, we suggest renaming
document.registerElement (whether to one of our suggestions or another). This is to avoid compat
problems with content written for Chrome’s shipping implementation. This will almost certainly be
true if we switch from createdCallback to constructors as the initializers.

II. ==== Shadow DOM ====

	A. Closed vs. Open.
		1. A closed/open flag has been added to createShadowRoot(). It seems this has been done. We are ok with the
syntax. <https://github.com/w3c/webcomponents/issues/100>
		2. The behavior of closed mode should be actually defined. We hope this does not need much justification.
We think this is critical for v1. <https://github.com/w3c/webcomponents/issues/100>
		3. We wanted closed mode to be the default but we are ok with having no default, as was decided at the last F2F.

	B. Multiple Generations of Shadow DOM
		1. We are glad to see that multiple generations of Shadow DOM has been removed per F2F agreement.
		2. After further consideration, we are even more convinced that the "named slot" proposal is the way to go
for distribution for v1. Original proposal here:
<https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
<https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution>>
Some detailed algorithms written out here:
<https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md> Github
issue here: <https://github.com/w3c/webcomponents/issues/138>

	C. Imperative Distribution API
		1. We think the imperative distribution API may be worth doing, but we're no longer confident that it is
important for v1. <https://github.com/w3c/webcomponents/issues/60 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429>>

	D. Event Retargeting
		1. We agree with making it optional (opt-in or opt-out). We don’t feel that strongly, but many web
developers have asked for this. The default should likely match the default for open vs. closed (no
retargeting by default if open by default). It seems like the issue is marked for v2, but we thought we'd all
agreed to do something here for v1? <https://github.com/w3c/webcomponents/issues/89>

	E. Renaming the API
		1. If any strongly incompatible changes are made, we suggest renaming createShadowRoot. This is to
avoid compat problems with content written for Chrome’s shipping implementation. We are not sure if
this will be required, but named slots may force it if adopted.

----- End forwarded message -----

--

-- 
Michael[tm] Smith https://people.w3.org/mike
Maciej Stachowiak | 21 Jul 03:17 2015
Picon

Apple's updated feedback on Custom Elements and Shadow DOM



A while back we sent a consolidated pile of feedback on the Web Components family of specs. In preparation for tomorrow's F2F, here is an update on our positions. We've also changed the bugzilla links to point to relevant github issues instead.

We're only covering Custom Elements (the main expected topic), and also Shadow DOM (in case that gets discussed too).


I. ==== Custom Elements ====

A. ES6 classes / Upgrade / Synchronous Constructors
1. In general, we support the "synchronous constructors" approach to the "prototype swizzling" approach, as the lesser evil. While tricky to implement correctly, it makes a lot more sense and fits more naturally into the language. We are willing to do the work to make it feasible.
2. Custom elements should support initialization using an ES6 class constructo instead of a separate callback. <https://github.com/w3c/webcomponents/issues/139>
3. We don’t think upgrading should be supported. The tradeoffs of different options have been much-discussed. <https://github.com/w3c/webcomponents/issues/134>
4. Specifically, we don't really like the "Optional Upgrades, Optional Constructors" proposal (seems like it's the worst of both worlds in terms of complexity and weirdness) or the "Parser-Created Classes" proposal (not clear how this even solves the problem).

B. Insertion/Removal Callbacks
1. We think the current attached/detached callbacks should be removed. They don’t match core DOM concepts and insert/remove is a more natural bracket. The primitives should be insertedIntoDocument / removedFromDocument and inserted / removed. If you care about whether your document is rendered, look at its defaultView property. <https://github.com/w3c/webcomponents/issues/286>
2. We think inserted/removed callbacks should be added, for alignment with DOM. <https://github.com/w3c/webcomponents/issues/222>

C. Inheritance for Built-ins
1. We think support for inheritance from built-in elements (other than HTMLElement/SVGElement) should be omitted from a cross-browser v1. It raises complex implementation issues. <https://github.com/w3c/webcomponents/issues/133>

D. Syntactic Sugar / Developer Ergonomics
1. We think it would be useful (perhaps post-v1) to make it simpler to create a custom element that is always instantiated with a shadow DOM from a template. Right now, this common use case requires script and a template in separate places, and a few lines of confusing boilerplate code. <https://github.com/w3c/webcomponents/issues/135>
2. We think at some point (perhaps post-V1), there should be a convenient declarative syntax that combines script and a template to define a custom element. JavaScript frameworks on top of web components provide something like this. Perhaps with field experience we can make a standardized common syntax. <https://github.com/w3c/webcomponents/issues/136>

E. Renaming the API
1. We’re still not wholly sold on document.registerElement as a name. We like document.define or document.defineElement. At minimum, we’d like the WG to decide on the name instead of just leaving it at the editor’s initial decision. We can probably live with this not changing though. <https://github.com/w3c/webcomponents/issues/140>
2. If anything about Custom Elements is changed incompatibly, we suggest renaming document.registerElement (whether to one of our suggestions or another). This is to avoid compat problems with content written for Chrome’s shipping implementation. This will almost certainly be true if we switch from createdCallback to constructors as the initializers.


II. ==== Shadow DOM ====

A. Closed vs. Open.
1. A closed/open flag has been added to createShadowRoot(). It seems this has been done. We are ok with the syntax. <https://github.com/w3c/webcomponents/issues/100>
2. The behavior of closed mode should be actually defined. We hope this does not need much justification. We think this is critical for v1. <https://github.com/w3c/webcomponents/issues/100>
3. We wanted closed mode to be the default but we are ok with having no default, as was decided at the last F2F.

B. Multiple Generations of Shadow DOM
1. We are glad to see that multiple generations of Shadow DOM has been removed per F2F agreement.
2. After further consideration, we are even more convinced that the "named slot" proposal is the way to go for distribution for v1. Original proposal here: <https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution> Some detailed algorithms written out here: <https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md> Github issue here: <https://github.com/w3c/webcomponents/issues/138>

C. Imperative Distribution API
1. We think the imperative distribution API may be worth doing, but we're no longer confident that it is important for v1. <https://github.com/w3c/webcomponents/issues/60>

D. Event Retargeting
1. We agree with making it optional (opt-in or opt-out). We don’t feel that strongly, but many web developers have asked for this. The default should likely match the default for open vs. closed (no retargeting by default if open by default). It seems like the issue is marked for v2, but we thought we'd all agreed to do something here for v1? <https://github.com/w3c/webcomponents/issues/89>

E. Renaming the API
1. If any strongly incompatible changes are made, we suggest renaming createShadowRoot. This is to avoid compat problems with content written for Chrome’s shipping implementation. We are not sure if this will be required, but named slots may force it if adopted.




bugzilla | 20 Jul 09:46 2015
Picon

[Bug 28967] New: "Legacy" appendices should be normative

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28967

            Bug ID: 28967
           Summary: "Legacy" appendices should be normative
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: UI Events
          Assignee: garykac@...
          Reporter: Ms2ger@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...

Browsers need to implement them, so there's no reason to make them informative.

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.

bugzilla | 18 Jul 09:43 2015
Picon

[Bug 27674] requestFullscreen should return a promise

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27674

Anne <annevk@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #33 from Anne <annevk@...> ---
https://github.com/whatwg/fullscreen/commit/fd19ec7a0f35e09b0cc4de0f676d37f6bd480560
https://github.com/whatwg/fullscreen/commit/d316cce76a5a5dad073425b973dd529dfa0d2a1a

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Domenic Denicola | 17 Jul 20:35 2015

Two new custom elements ideas

Hi all,

Over the last few days I’ve worked on two new potential ideas for custom elements, hoping to shake things
up with new possibilities. These are both largely geared around how we react to the key custom elements
question
[1].

https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Optional-Upgrades-Optional-Constructors.md
: this proposal assumes we come out in favor of running author code during parsing/cloning/editing/etc.
It allows component authors to choose between using constructors, thus disallowing their components to
be used with server-side rendering/progressive enhancement, and using a createdCallback-style
two-stage initialization, which will then allow progressive enhancement. It is meant explicitly as a
compromise proposal, similar in spirit to the { mode: "open"/"closed" } proposal, since we know
different parties have different values and the way forward may be to simply accommodate both value
systems and let developers light a
path.

https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Parser-Created-Constructors.md
: this proposal assumes we do not achieve consensus to run author code during
parsing/cloning/editing/etc. It recognizes that, if we disallow this, we cannot allow custom
constructors, and then tries to make the best of that world. In particular, it is an alternative to the
“Dmitry” proposal, designed to entirely avoid the dreaded proto-swizzling, while still having
many of the same benefits. If you scroll to the bottom, you note how it also leaves the door open for future
custom constructors, if we decide that it's something that we want in the future, but simply cannot afford
to specify or implement right now due to how hard that is. In this sense it's meant somewhat as a bridging
proposal, similar in spirit to the slots proposal, which falls short of the ideal imperative
distribution API but will probably work for most developers anyway.

These are largely meant to get ideas moving, and to avoid polarizing the discussion into two camps. As I
noted in [2], there are several degrees of freedom here; the key custom elements question is distinct from
upgrades, which is distinct from ES2015 class syntax, which is distinct from constructor vs. created
lifecycle hook, etc. The possibility space is pretty varied, and we have multiple tools in our toolbox to
help arrive at a resolution that everyone finds agreeable.

Comments are of course welcome, and if you have time to read these before the F2F that would be really appreciated.

Thanks,
-Domenic

[1]: https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0159.html

[2]: https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0162.html


Travis Leithead | 17 Jul 20:03 2015
Picon

alternate view on constructors for custom elements

OK, after reading Dominic’s proposal [1], I’m a little confused. I thought that I understood how constructors should work, but there’s some magic going on that I can’t follow… I’m sure you folks can help.

 

```

class CustomElement extends HTMLElement {

   constructor() {

      super();

   }

}

 

Something magical happens here. The use of super() is supposed to call the constructor of the HTMLElement class—but that’s not a normal JS class. It doesn’t have a defined constructor() method [yet?]. Also, as has been pointed out, running the CustomElement constructor code _before_ instantiating the actual element (at parse-time for example) opens up a world of potential problems as have been explored:

·        Javascript classes are mutable—what if CustomElement’s proto chain is mutated later?

·        What if the constructor throws?

…just to name a few.

 

I’m trying to rationalize the custom elements previous design with the use of constructors. Basically, I think it should still be a two-stage creation model:

1.      Native [internal] element is created with appropriate tag name, attributes, etc.

2.      JS constructor is called and provided the instance (as ‘this’)

 

#1 is triggered by the parser, or by a native constructor function. That constructor function could either be provided separately like it is returned from registerElement today, or in some other way (replacing the original constructor?). Since replacing the original constructor sounds weird and probably violates a bunch of JS invariants, I’ll assume sticking with the original model.

 

This makes it much safer for implementations, since the native custom element can always be safely created first, before running JS code. It also means there’s no magic super() at work—which seems to leave too much control up to author code to get right.

 

Basic example of what I’m thinking:

 

class XFooStartup extends HTMLElement {

   constructor(val1, val2) {

      this.prop = val1;

      this.prop2 = val2;

   }

}

window.XFoo = document.registerElement(‘x-foo’, XFooStartup);

 

// (1)

var x1 = new XFooStartup(“first”, “second”);

// (2)

var x2 = new XFoo(“first”, “second”);

 

Calling (1) does not create a custom element. Extending from HTMLElement is not magical, it’s just a prototype inheritance, as can be done today. super() would do whatever super() does when the super class has no defined method to invoke. x1 is a regular JS object with a .prop and .prop2.

 

Calling (2) runs the platform-provided constructor function which internally inits a new HTMLElement in the C++ (or could be Element if in XML document?). Then the platform immediately (synchronously) invokes the provided constructor function as if:

XFooStartup.apply(newHTMLElementInstance, argsPassedThroughFromCall);

so that XFooStartup’s constructor operates on the ‘this’ being the instance created by the platform.

 

 

[1] https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Optional-Upgrades-Optional-Constructors.md

Travis Leithead | 16 Jul 17:45 2015
Picon

[WebIDL] T[] migration

Hey folks,

 

Now that WebIDL has added FrozenArray<> and dropped T[], it’s time to switch over! On the other hand, there are a number of specs that have already gone to Rec that used the old syntax.

 

Recommendations:

·        HTML5

·        Web Messaging

 

Other references:

·        CSS OM

·        Web Sockets

·        WebRTC

 

Legacy/Deprecated references:

·        TypedArrays (replaced by ES2015)

·        Web Intents

 

Thoughts on what to do about this? Should we consider keeping T[] in WebIDL, but having it map to FrozenArray<>? Should we issue errata to those Recs?

Arthur Barstow | 16 Jul 13:55 2015
Picon

RfC: LCWD of Tracking Compliance and Scope; deadline October 7

WebApps has been asked to review the Tracking Protection group's July 14 
Last Call Working Draft of T/racking Compliance and Scope/:

   <http://www.w3.org/TR/2015/WD-tracking-compliance-20150714/>

If anyone in WebApps wants to propose an official group response, please 
do so ASAP, in reply to this e-mail so the group can discuss it.

Comments should be sent to public-tracking-comments  <at>  w3.org (archive 
[1]) by October 7. Presumably, the group also welcomes "silent review" 
feedback such as "I reviewed section N.N and have no comments".

-Thanks, ArtB

[1] <https://lists.w3.org/Archives/Public/public-tracking-comments/>

On 7/14/15 9:01 PM, Justin Brookman wrote:
> The Tracking Protection Working Group published today (14 July 2015) a 
> Last Call Working Draft of the Tracking Compliance and Scope 
> specification, and we would like to ask for review comments from the 
> following groups: Privacy Interest Group, WAI Protocols and Formats 
> Working Group, Web Applications WG, Internationalization Working 
> Group, and Device APIs WG. Of course, we welcome and encourage other 
> reviews.
>
> The draft is available here:
> http://www.w3.org/TR/2015/WD-tracking-compliance-20150714/
>
> Abstract:
> This specification defines a set of practices for compliance with a 
> user's Do Not Track (DNT) tracking preference to which a server may 
> claim adherence.
> Comments will be most useful in identifying particular problems with 
> the specification that might inhibit adoption, where this 
> specification fails to further goals of user privacy and user control, 
> and whether this specification creates or does not otherwise resolve 
> dependencies with other technical standards, practices, or processes.
>
> The Last Call period ends 7 October 2015. Please send comments to the 
> publicly-archived public-tracking-comments@... 
> <mailto:public-tracking-comments@...> mailing list.
>
> Thanks,
> Carl Cargill, Justin Brookman, Matthias Schunter
> Co-Chairs of the Tracking Protection WG
>
> * Announcement of Last Call publication decision: 
> https://lists.w3.org/Archives/Public/public-tracking/2015Jul/0000.html
> * Last Call comment issues will be listed in a specific Tracker 
> product: https://www.w3.org/2011/tracking-protection/track/products/8
> * Patent disclosure information is available: 
> http://www.w3.org/2004/01/pp-impl/49311/status


Gmane