[pointerlock] Various comments
Hi Vincent, I have by no means reviewed the entire spec, but while reviewing the test cases, I noticed some room for improvement. Comments below. In the 4. pointerlockchange and pointerlockerror Events section [1]: … with its |bubble| attribute set … should be |bubbles|. Probably best to link to the definition in DOM, too. If you add attributes to MouseEvent, you should also add them to the MouseEventInit dictionary, so they can be initialized. Defaults should be defined for those attributes in prose too, for the createEvent case. Text could be: # When an event is created, the attribute must be initialized to […]. In the definition of requestPointerLock [2], a reference to DOM 3 Core is made; it looks like it should be to DOM 3 Events or UI Events instead. In section 6.1 Attributes, the writable attributes have two consecutive commas in their definition: onpointerlockchange of type EventHandler, , nullable Possibly a ReSpec bug; if so, please report to whereever such issues should be reported. In general, the prose could be made less ambiguous. For example, the definition of exitPointerLock: # Initiates an exit from pointer lock state if currently locked to a # target in this document, and sends a pointerlockchange event when the # lock state has been exited. # # The system mouse cursor must be displayed again and positioned at the # same location that it was when pointer lock was entered (the same # location that is reported in screenX/Y when the pointer is locked). could be rewritten as: | 1. If the pointer is not currently locked to a target in the |context object, terminate these steps. | 2. Exit the lock state. [Or should this be queued too? An |unambiguous specification would have answered this |question.] | 3. Display the system mouse cursor again, positioned at the |same location that it was when pointer lock was entered. | 4. Deliver [link to section 4. pointerlockchange and |pointerlockerror Events] a |pointerlockchange| event to the |context object. |Note: this is the same location that is reported in |screenX/Y when the pointer is locked. The dfn-exitpointerlock id is on an empty dfn element, which seems pretty silly. HTH Ms2ger [1] https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#pointerlockchange-and-pointerlockerror-events [2] https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#widl-Element-requestPointerLock-void
[HTML imports]: Imports and Content Security Policy
Hi,
I have subscribed to this list because my colleague Gabor (CC) and I
found a few issues with Content Security Policies applied to HTML imports.
The current draft
(http://w3c.github.io/webcomponents/spec/imports/#imports-and-csp, Jan
9) suggests that import loading is restricted through a script-src
attribute, which is probably fine.
Our issue, however is with the next layer: Each import is restricted by
its own Content Security Policy.
Let's discuss how this could work: The document subtree of the imported
document has its own CSP, just like the parent document. Hence, there
are two CSPs guarding one browsing context (i.e. the window object).
This brings the issue that a restricted imported document can ask the
non-restricted parent document to do its dirty work:
Imagine a CSP on the parent document (example.com) that only allows
example.com and imported.com. The CSP on imported.com allows only
imported.com ('self'). The imported document could easily contain a
script that attaches a script node to the parent document's body (other
subtree) which loads further resources from example.com. The restriction
against imported.com has been subverted, hasn't it?
If we interpreted this more freely, we could also consider combining the
two CSPs somehow, let's see how this could work:
Scenario A) The CSP of the main and the imported document are loosely
combined, i.e. the union set is built. The whole document that formerly
had a policy of default-src: example.com gets a new policy of
default-src: imported.com, because the import has this policy specified.
This case brings multiple issues: Allowing resource loads
depends on whether the web server at imported.com serves its http
response quickly. This issue is only getting worse with nested imports
in which imported documents A and B both import another document C -
which chain up to the parent is the correct one? Via A or B?
Scenario B) The CSP of the main and the imported document are forming a
strict combination (intersection): The CSP on the imported document
(imported.com) would then have to explicitly allow example.com,
otherwise including it would break the importing site. This is unlikely
to be intended. The previous example with imported documents A and B
that both import C applies makes it impossible to solve.
Now, what seems to make sense instead is that the CSP of the imported
website is completely *disregarded*. This would lead to the sad fact
that the importer (example.com) cannot treat imported.com entirely as a
black box, as it has to inspect which resources it intends to load and
selectively allow them in their own CSP. On the other hand, this
wouldn't bring any of the previously mentioned side-effects. The actual
owner of the document is fully in charge.
What do you think?
Frederik
Re: [webcomponents] PubStatus reorg; Plans and Expectations
On Thu, Jan 9, 2014 at 5:17 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi Dimitri All, FYI, yesterday I moved all of the Web Components specs in PubStatus to its own table [PubStatus-WC] to help address the so, what is the status of Web Components standardization in WebApps use case (as well as to be consistent with the way PubStatus organizes the Widgets spec suite). Although PubStatus provides current data about the state of WebApps' specs, other than the Plans data (which is typically quite terse or empty), PubStatus doesn't facilitate Editors documenting more forward looking information such as roadmaps, longer term expectations, etc. Given this, and the broad interest in Web Components, I think it would be useful if there was some type of state of Web Components standardization that included things like: * Expectations for the specs by EoY 2014 * Status and plans of Web Component native implementations (f.ex. information beyond what is available in CanIUse.com and ChromeStatus.com/features) * Status and plans of Web Component polyfills * Key open issues, dependencies * Testing status and plans * Deployment status Thus, when someone asks so, what do we expect for the state of Web Components standardization by the end of 2014?, we have a document/thread we can point to (and that document could be a reply to this email, a blog, etc.). WDYT? I think it's reasonable. I've been away from the keyboard for a little bit and am still digging out from the email backlog, so please be patient with me :) (BTW, I'm not picking on Dimitri here (who has done exemplary work, especially regarding professional community engagement). I wold be *delighted* if other Editors would provide similar information for their specs.) Yay, I love being delightful! -Thanks, ArtB [PubStatus-WC] http://www.w3.org/2008/webapps/wiki/PubStatus#Web_ Components_Specifications
Re: [webcomponents] Feedback for web components spec from a GWT experiment
On Wed, Jan 8, 2014 at 8:17 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/6/14 8:52 PM, Goktug Gokdogan wrote:
function MyCustomElement() {};
MyCustomElement.prototype = Object.create(HTMLElement.prototype);
document.appendChild(new MyCustomElement());
If this were actually using ES6 classes (and if HTMLElement were
constructible), this would in fact work. The issue is that simply setting
your proto is not actually the same thing as subclassing when objects need
to have private state and hence are branded.
Yes, I'm not exactly extending but I would not call it as implementing an
interface as well :)
Is it really part of the plans (i.e. making HTMLElement constructible)? If
it is, is it going to work with some native support from browser? That's
what I'm trying to emulate right now. I suggested document.initElement
because provides me a way to emulate this.
I guess the reason I was thinking that way was mostly historical
reasons. In OO platforms, defining your own widget has been just a
matter of extending a base class.
In this case it's more like you implemented an interface but the
appendChild method expects a particular implementation of that interface
All this may sound specific to GWT but actually I think it is more about
object orientation and I can imagine similar issues will be hit with
classes in ES6, Dart and others.
ES6 classes will actually end up working correctly here, in that you will
be able to define an ES6 class extending a constructible DOM class, then
call its constructor, and that will work correctly.
function MyCustomElement {
document.initElement(this); // let's the browser do whatever needed
}
This actually isn't very feasible, because the this is already the wrong
sort of object here and can't be mutated in-place (e.g. the right sort of
object needs to be in a different arena in some implementations).
Again, ES6 classes, once implemented, solve this problem by delegating
@@construct to the superclass correctly.
-Boris
Re: [webcomponents] Feedback for web components spec from a GWT experiment
On 1/9/14 8:39 PM, Goktug Gokdogan wrote: Is it really part of the plans (i.e. making HTMLElement constructible)? Ideally, yes. The main problem with making HTMLElement constructible is this: What tag name should it use when it constructs? If it were not for that, it would already be constructible, I suspect. If it is, is it going to work with some native support from browser? It would have to, yes. -Boris
Re: [webcomponents] Feedback for web components spec from a GWT experiment
On Thu, Jan 9, 2014 at 5:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/14 8:39 PM, Goktug Gokdogan wrote: Is it really part of the plans (i.e. making HTMLElement constructible)? Ideally, yes. The main problem with making HTMLElement constructible is this: What tag name should it use when it constructs? If it were not for that, it would already be constructible, I suspect. Can't it be passed by constructor call? If it is, is it going to work with some native support from browser? It would have to, yes. -Boris
Re: [webcomponents] Feedback for web components spec from a GWT experiment
On 1/9/14 8:50 PM, Goktug Gokdogan wrote: Can't it be passed by constructor call? Possibly, yes. The spec was in flux for a while, but looks like @@create does in fact get passed the constructor arguments, so it can create different objects based on those. -Boris
Re: [HTML imports]: Imports and Content Security Policy
Hi Frederik,
Thanks for bringing it up!
As you pointed out, CSP of imported documents essentially extends the
set of allowed domains. I thought I was useful for component authors to
specify their own domains, like one of their own CDN.
I'm not sure how it is threatening because components won't have any
sensitive state in it
because HTML Imports doesn't have any isolation mechanism after all. It
however might be an optimistic view.
Being conservative, it could be better to apply master document's CSP to
whole import tree
and ignore CSPs on imports. It is less flexible and page authors need to
list all domains for
possibly imported resources, but this flat model looks what Web is relying
today.
I'd appreciate any feedback and/or suggestions here. It seems there is some
progress on CSP side.
It would be great if there is some new mechanism to handle CSP of
subresources.
Things like ES6 modules might get benefit from it as well.
On Fri, Jan 10, 2014 at 12:19 AM, Frederik Braun fbr...@mozilla.com wrote:
Hi,
I have subscribed to this list because my colleague Gabor (CC) and I
found a few issues with Content Security Policies applied to HTML imports.
The current draft
(http://w3c.github.io/webcomponents/spec/imports/#imports-and-csp, Jan
9) suggests that import loading is restricted through a script-src
attribute, which is probably fine.
Our issue, however is with the next layer: Each import is restricted by
its own Content Security Policy.
Let's discuss how this could work: The document subtree of the imported
document has its own CSP, just like the parent document. Hence, there
are two CSPs guarding one browsing context (i.e. the window object).
This brings the issue that a restricted imported document can ask the
non-restricted parent document to do its dirty work:
Imagine a CSP on the parent document (example.com) that only allows
example.com and imported.com. The CSP on imported.com allows only
imported.com ('self'). The imported document could easily contain a
script that attaches a script node to the parent document's body (other
subtree) which loads further resources from example.com. The restriction
against imported.com has been subverted, hasn't it?
If we interpreted this more freely, we could also consider combining the
two CSPs somehow, let's see how this could work:
Scenario A) The CSP of the main and the imported document are loosely
combined, i.e. the union set is built. The whole document that formerly
had a policy of default-src: example.com gets a new policy of
default-src: imported.com, because the import has this policy specified.
This case brings multiple issues: Allowing resource loads
depends on whether the web server at imported.com serves its http
response quickly. This issue is only getting worse with nested imports
in which imported documents A and B both import another document C -
which chain up to the parent is the correct one? Via A or B?
Scenario B) The CSP of the main and the imported document are forming a
strict combination (intersection): The CSP on the imported document
(imported.com) would then have to explicitly allow example.com,
otherwise including it would break the importing site. This is unlikely
to be intended. The previous example with imported documents A and B
that both import C applies makes it impossible to solve.
Now, what seems to make sense instead is that the CSP of the imported
website is completely *disregarded*. This would lead to the sad fact
that the importer (example.com) cannot treat imported.com entirely as a
black box, as it has to inspect which resources it intends to load and
selectively allow them in their own CSP. On the other hand, this
wouldn't bring any of the previously mentioned side-effects. The actual
owner of the document is fully in charge.
What do you think?
Frederik
--
morrita
Re: Why can't we just use constructor instead of createdCallback?
Jonas, William, Ted, and I had some discussion about this last month. (Sorry
for the delayed response).
On Dec 5, 2013, at 10:58 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/6/13 1:49 AM, Ryosuke Niwa wrote:
Then how do we define a custom element using ES6 classes? Are we going to
not call the constructor?
An excellent question, indeed. I don't have a good answer for you.
If we do make elements subclassable (which it seems like we should), we would
presumably need to make the actual default constructor of the built-in
element classes a no-op, since we can't actually rely on the subclass calling
it. All the relevant setup would need to be done by @@create.
Given that, we could maybe cheat and in fact do some sort of delayed calling
of the constructor of ES6 subclasses of elements. You'd still be able to
observe these objects in an unconstructed state from the subclass pov, but
at least it wouldn't be a security issue in terms of operating on a DOM
that's in an inconsistent state from the point of view of privileged code.
Calling constructors after the tree had been constructed will be an issue
because then you could access “unconstructed” nodes via nextSibling,
parentNode, etc...
It's not clear to me how OK such an unconstructed state is. I suppose it's
no worse than someone extending the ES6 subclass in question and then never
calling its constructor... But that's a programming error on the someone's
part, typically, while here we would be effectively forcing this sort of
thing on all Element subclasses.
All that still seems more palatable than trying to completely revise HTML
parsing to be robust to constructors running when the element is created….
One idea that came out of our discussion is was to add an additional step in
the parser to call constructors on all “pending” elements before they’re being
constructed into the DOM tree.
On Dec 6, 2013, at 7:05 AM, Erik Arvidsson a...@chromium.org wrote:
The custom element draft does add a new synchronization point. After setting
innerHTML (for example), before returning to the script the callbacks for the
custom elements created by innerHTML are called in tree order.
This does lead to the possibility to observer objects that have not yet had
their created callback been called yet. I think this trade off is inevitable,
no matter whether we use @@create, constructor or created. I just don't see
us being able to call user code every time a node is created.
I do understand your concern.
On Dec 6, 2013, at 7:37 AM, Erik Arvidsson a...@chromium.org wrote:
The things that fail here are:
1. The parser does not know that it needs to use MyElement.@@create to create
the JS objects when it sees a my-element.
On the other hand, solving this seems to require running some author scripts at
the element creation time, at some later time but before the node is inserted
into the document.
2. No callbacks for enteredView, leftView and attributeChanged.
3. It depend on the magic of document.createElement which is circular. A
better way would be to do `super('my-element')` or something like that.
- R. Niwa
Re: Why can't we just use constructor instead of createdCallback?
On 1/9/14 10:57 PM, Ryosuke Niwa wrote: Given that, we could maybe cheat and in fact do some sort of delayed calling of the constructor of ES6 subclasses of elements. You'd still be able to observe these objects in an unconstructed state from the subclass pov, but at least it wouldn't be a security issue in terms of operating on a DOM that's in an inconsistent state from the point of view of privileged code. Calling constructors after the tree had been constructed will be an issue because then you could access “unconstructed” nodes via nextSibling, parentNode, etc... Right, I did say that above. Is that really a problem in practice, though? One idea that came out of our discussion is was to add an additional step in the parser to call constructors on all “pending” elements before they’re being constructed into the DOM tree. Isn't that the bad thing we _don't_ want to do? That is, invoke arbitrary page JS from the middle of the parsing algorithm? On the other hand, solving this seems to require running some author scripts at the element creation time, at some later time but before the node is inserted into the document. The parser is expected to insert the nodes into the document pretty much immediately after creating them, no? -Boris
Re: Why can't we just use constructor instead of createdCallback?
On Thu, Jan 9, 2014 at 9:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/9/14 10:57 PM, Ryosuke Niwa wrote:
Given that, we could maybe cheat and in fact do some sort of delayed
calling of the constructor of ES6 subclasses of elements. You'd still be
able to observe these objects in an unconstructed state from the subclass
pov, but at least it wouldn't be a security issue in terms of operating on a
DOM that's in an inconsistent state from the point of view of privileged
code.
Calling constructors after the tree had been constructed will be an issue
because then you could access “unconstructed” nodes via nextSibling,
parentNode, etc...
Right, I did say that above. Is that really a problem in practice, though?
One idea that came out of our discussion is was to add an additional step
in the parser to call constructors on all “pending” elements before they’re
being constructed into the DOM tree.
Isn't that the bad thing we _don't_ want to do? That is, invoke arbitrary
page JS from the middle of the parsing algorithm?
On the other hand, solving this seems to require running some author
scripts at the element creation time, at some later time but before the node
is inserted into the document.
The parser is expected to insert the nodes into the document pretty much
immediately after creating them, no?
-Boris
Calling of constructors (in JS/ES sense) instead of callbacks is not
semantically correct I would say.
Consider this declaration:
class MyElement inherits HTMLElement {
public prop = 1;
constructor( text ) {
super(my-element);
this.textContent = text;
}
}
UA simply cannot call such constructor as it requires parameter.
UA can call only implicit default constructor, : ({ prop:1
}).__proto__ = MyElement; in this case.
And call some designated method of the class ('callback' in this
discussion) when element gets
attached to the DOM tree.
Constructors are used for 'external' element creation:
var myel = new MyElement(woo-hoo!);
About callbacks:
It should be two callbacks actually:
attached() - called when element *gets attached to the DOM*, it is not
a constructor, sic!
detached() - when it gets detached from the DOM.
so here:
var myel = new MyElement(woo-hoo!);
someParent.append(myel);
call of myel.attached() will happen inside the append() above.
detached() is called when parent.removeChild() for the element is called.
Just in case: this is how it is implemented and works in my Sciter [1]
and I didn't find any problems with element/script life cycles.
And yet. I also have dynamic element class assignment
by CSS with custom 'prototype' property, e.g.:
input[type=masked] { prototype: MaskedInput url(code/widgets.tis); }
In that case attached/detached are also called when the element
gets/looses that style. But that's probably another story.
[1] http://terrainformatica.com/sciter
--
Andrew Fedoniouk.
http://terrainformatica.com
