Re: Defining a constructor for Element and friends
On 1/9/15 8:01 PM, Domenic Denicola wrote:
I was writing up my ideas in an email but it kind of snowballed into something
bigger so now it's a repo: https://github.com/domenic/element-constructors
Domenic, thanks for putting this together.
Caveat: I won't get a chance to read through this carefully until
Monday. Responses below are based on just what's in the mail.
That said, I do have one question already: what does the term
own-instances mean in that document?
whether it is acceptable to have an element whose name is a, namespace is the
HTML namespace, and interface is Element
I'd like to understand what you mean by interface is Element here,
exactly.
One ugly point of my design is that the constructor signature is `new
Element(localName, document, namespace, prefix)`, i.e. I require the document
to be passed in. I am not sure this is necessary
It's necessary, but I think the document should be allowed, but not
required. As in, the signature should be:
new Element(localName, namespace, prefix, document).
(though maybe prefix should come after document; hard to say). If the
document is undefined, then we get a document as follows: Element is a
function, so has an associated Realm. This Realm's [[globalThis]] is a
Window. This Window has a .document; use that.
The only reason we need the ability to specify a document at all is that
there are documents around that are not inside a browsing context (XHR
responseXML, for example) and we need to be able to create elements that
have those documents as an ownerDocument. But those document's don't
have their own global/Realm and hence don't have separate instances of
the Element constructor.
I commented on the github issue in a bit less detail.
what is the use case for producing something that extends HTMLImageElement (and
presumably has its internal slots?) but doesn't have img as the tag name and
hence will not have anything ever look at those internal slots?
Elsehwere on this thread or some related one IIRC he pointed out code that looks at the local name, finds
img, and casts to the C++ backing representation of HTMLImageElement. So from what I am
gathering in his view the parts of the platform that treat img elements specially currently work
by checking explicitly that something has local name img (and HTML namespace).
Yes. And that's true of not just implementations but also
specifications. The entire HTML specification is written in terms of
local name tests, for example.
From a naïve authoring point of view that seems suboptimal. I'd rather be able to do
`class MyImg extends HTMLImageElement { constructor(document) { super(document); } }` and
have MyImg instances treated specially by the platform in all the ways img
currently is.
I don't quite see the issue here. Presumably the HTMLImageElement
constructor passes img as the localName to the HTMLElement
constructor, so your MyImg would get img as the localName, right?
Can you explain what the concern is here?
Now I do think there's an authoring problem where if you want to do a
fancyimage that's treated like img by the platform you have a
problem. But that doesn't seem to be what you're talking about... or
are you?
Or, for an easier example, I'd like to be able to do `class MyQ extends HTMLQuoteElement
{ constructor(document) { super(document); } }` and have `(new MyQ()).cite` actually
work, instead of throw a cite getter incompatible with MyQ error because I
didn't get the HTMLQuoteElement internal slots.
This should totally work, of course. Why wouldn't it, exactly? Given
the subclassing proposal on the table in ES6 right now, it would work
splendidly, since the HTMLQuoteElement constructor is what would perform
the object allocation and it would pass along q as the localName.
(Though actually, HTMLQuoteElement is excitingly complicated, because
both q and blockquote would use that constructor, so it would need
to either require one of those two strings be passed in, or default to
q unless blockquote is passed in or something.)
The logical extension of this, then, is that if after that `document.registerElement` call I do
`document.body.innerHTML = my-q cite=fooblah/my-q`
Ah, here we go. This is the part where the trouble starts, indeed.
This is why custom elements currently uses q is=my-q for creating
custom element subclasses of things that are more specific than
HTMLElement. Yes, it's ugly. But the alternative is at least major
rewrite of the HTML spec and at least large parts of Gecko/WebKit/Blink.
:( I can't speak to whether Trident is doing a bunch of localName
checks internally.
However this idea that we'd like custom elements which inherit from existing
elements to have their internal slots ties in to the whole upgrading mess
Right, which you get for free with the q is=my-q setup, since you
just get the slots for q and then the upgrade just has to worry about
your proto
RE: Defining a constructor for Element and friends
OK, so I've thought about this a lot, and there was some discussion on an
unfortunately-TC39-private thread that I want to put out in the open. In [1] I
outlined some initial thoughts, but that was actually a thread on a different
topic, and my thinking has evolved.
[1]: http://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0035.html
I was writing up my ideas in an email but it kind of snowballed into something
bigger so now it's a repo: https://github.com/domenic/element-constructors
One primary concern of mine is the one you mention:
whether it is acceptable to have an element whose name is a, namespace is
the HTML namespace, and interface is Element
I do not really think this is acceptable, and furthermore I think it is
avoidable.
In the private thread Boris suggested a design where you can do `new
Element(localName, namespace, prefix)`. This seems necessary to explain how
`createElementNS` works, so we do want that. He also suggested the following
invariants:
1. The localName and namespace of an element determine its set of internal
slots.
2. The return value of `new Foo` has `Foo.prototype` as the prototype.
I agree we should preserve these invariants, but added a few more to do with
keeping the existing (localName, namespace) - constructor links solid.
I've outlined the added invariants in the readme of the above repo. Other
points of interest:
- Explainer for a very-recently-agreed-upon ES6 feature that helps support the
design:
https://github.com/domenic/element-constructors/blob/master/new-target-explainer.md
- Jump straight to the code:
https://github.com/domenic/element-constructors/blob/master/element-constructors.js
- Jump straight to the examples of what works and what doesn't:
https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L194
One ugly point of my design is that the constructor signature is `new
Element(localName, document, namespace, prefix)`, i.e. I require the document
to be passed in. I am not sure this is necessary but am playing it safe until
someone with better understanding tells me one way or the other. See
https://github.com/domenic/element-constructors/issues/1 for that discussion.
---
As for how this applies to custom elements, in the private thread Boris asked:
what is the use case for producing something that extends HTMLImageElement
(and presumably has its internal slots?) but doesn't have img as the tag
name and hence will not have anything ever look at those internal slots?
Elsehwere on this thread or some related one IIRC he pointed out code that
looks at the local name, finds img, and casts to the C++ backing
representation of HTMLImageElement. So from what I am gathering in his view the
parts of the platform that treat img elements specially currently work by
checking explicitly that something has local name img (and HTML namespace).
From a naïve authoring point of view that seems suboptimal. I'd rather be able
to do `class MyImg extends HTMLImageElement { constructor(document) {
super(document); } }` and have MyImg instances treated specially by the
platform in all the ways img currently is.
Or, for an easier example, I'd like to be able to do `class MyQ extends
HTMLQuoteElement { constructor(document) { super(document); } }` and have `(new
MyQ()).cite` actually work, instead of throw a cite getter incompatible with
MyQ error because I didn't get the HTMLQuoteElement internal slots.
The logical extension of this, then, is that if after that
`document.registerElement` call I do `document.body.innerHTML = my-q
cite=fooblah/my-q` I'd really like to see
`document.querySelector(my-q).cite` return `foo`.
However this idea that we'd like custom elements which inherit from existing
elements to have their internal slots ties in to the whole upgrading mess,
which seems quite hard to work around. So maybe it is not a good idea? On the
other hand upgrading might be borked no matter what, i.e. it might not be
possible at all to make upgraded elements behave anything like
parsed-from-scratch elements. (I am planning to think harder about the
upgrading problem but I am not hopeful.)
Re: [Pointer Lock] Comments
Thank you again:
https://dvcs.w3.org/hg/pointerlock/rev/25ad122a8000
On Tue, Dec 2, 2014 at 6:43 PM, timeless timel...@gmail.com wrote:
1. w3c is en-us
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#abstract
modelling - modeling
Done.
2. Xlib
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#h3_why-bundle-all-functionality-hiding-cursor-providing-mouse-deltas-instead-of-using-css-to-hide-the-cursor-always-providing-delta-values-and-offering-an-api-to-restrict-the-cursor-movement-to-a-portion-of-the-web-page
Direct APIs do not exist on all platforms (Win, Mac, Linux) to bound the
cursor to a specific rectangle, and prototypes have not yet been developed
to demonstrate building that behavior by e.g. invisible windows with xlib
or manual cursor movement on Mac.
Xlib - Wikipedia, the free encyclopedia --
http://en.wikipedia.org/wiki/Xlib
Done. Linked to definition.
Also note that Mac is not a proper term, it could be Mac OS (X),
Macintosh ... or macs.
Done. Expanded to more formal names.
3. Mouse capture
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#introduction
Pointer Lock is related to Mouse Capture [MDN-SETCAPTURE].
should https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 be noted?
Done.
MS should probably be referenced:
http://msdn.microsoft.com/en-us/library/ie/ms536742%28v=vs.85%29.aspx
since it's their fault...
Done.
4. a11y/i18n
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#dfn-engagement-gesture
An event generated by the user agent as a result of user interaction
intended to interact with the page. e.g. click, but not mousemove.
Engagement gestures are any events included in the definition of being
allowed to show a popup with the addition of keypress and keyup.
shift, or control+shift and similar things are often used to trigger
an assistive technology, or an IME / language switch.
https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/access_stickykeys_settings.mspx?mfr=true
turn StickyKeys on or off by by pressing the SHIFT key five times
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/langbar_keystroke_shortcuts.mspx?mfr=true
Switch between languages or keyboard layouts CTRL+SHIFT or left ALT+SHIFT
http://support.microsoft.com/kb/97738
When you press the APOSTROPHE (') key, QUOTATION MARK () key, ACCENT
GRAVE (`) key, TILDE (~) key, ACCENT CIRCUMFLEX key, or CARET (^) key,
nothing appears on the screen until you press the a second key. If you
press one of the letters designated as eligible to receive an accent mark,
the accented version of the letter appears. If you press an ineligible key,
two separate characters appear. In other words, the US-International
keyboard layout dynamic-link library (DLL) automatically accents letters
that customarily receive an accent but does not automatically accent
letters that do not customarily receive an accent.
While it's nice to allow for keys to trigger a lock, keys that may
eventually be handled by something outside the UA should probably not be
eligible for this.
Done.
user interaction intended to interact - user interaction processed by
the user agent
Added: Note that operating system level accessibility and
internationalization features may intercept gestures before the user agent
processes them for interaction with a page. E.g. multiple key press codes
used to enter an extended international character.
5. must
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#pointerlockchange-and-pointerlockerror-events
Two events are used to communicate pointer lock state change or an error
in changing state. They are named pointerlockchange and pointerlockerror.
If pointer lock is entered or exited for any reason a pointerlockchange
event must be sent.
If I press ctrl-w/cmd-w (close window/tab), is the UA required to send
these events?
If an iframe has pointerlock, and its parent removes the iframe from the
dom, is the UA required to send these events?
If an iframe has pointerlock, and its parent changes the iframe's document
url to another page, is the UA required to send these events?
Help me pin down language. For each case above: Yes, If the document exists
the events should be dispatched. Is more language needed to avoid the
alternative implied assumption that a document must live until the events
are dispatched?
6. and
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void
(for example: mousemove, mousedown, mouseup, click, wheel)
(for example: mouseover, mouseout, drag, drop).
Done.
Please use and -- you do elsewhere:
clientX, clientY, screenX, and screenY
7. movement/focus
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void
Movement and button presses of
Re: Shadow tree style isolation primitive
On Jan 9, 2015 8:43 AM, Anne van Kesteren ann...@annevk.nl wrote: I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not necessarily user and user agent stylesheets) and requiring a special selector, such as , to pierce through the boundary. This is a bit different from the `all` property as that just changes the values of all properties, it does not make a selector such as div no longer match. So to be clear, the idea is that if you have a tree such as section class=example h1Example/h1 div ... /div /section Then a simple div selector would not match the innermost div if we isolated the section. Instead you would have to use section div or some such. Or perhaps associate a set of selectors and style declarations with that subtree in some manner. -- https://annevankesteren.nl/ For clarity, are you suggesting you'd control the matching boundary via CSS somehow or you'd need an indicator in the tree? A new element/attribute or something like a fragment root (sort of a shadowroot-lite)?
RE: Custom element lifecycle callbacks
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Fri, Jan 9, 2015 at 3:30 AM, Adam Klein ad...@chromium.org wrote: Do you have a proposal for where these symbols would be vended? My idea was to put them on Node or Element as statics, similar to the Symbol object design. The discussion on public-script-coord is this bug: In an alternate reality where modules were specced and implemented before symbols, they should go there. (Both for Symbol and for Node/Element; the placement of them on Symbol was a somewhat-last-minute hack when we realized modules were lagging symbols substantially.) But yes, in this reality somewhere in the Element/Node/HTMLElement hierarchy makes sense. (I'd guess Element?) We might not want to take it as precedent though. Or maybe we do, for consistency.
Re: Shadow tree style isolation primitive
On Fri, Jan 9, 2015 at 10:49 AM, Anne van Kesteren ann...@annevk.nl wrote: I wasn't suggesting anything since I'm not sure what the best way would be. It has to be some flag that eventually ends up on an element so when you do selector matching you know what subtrees to ignore. If you set that flag through a CSS property you'd get circular dependencies, but perhaps that can be avoided somehow. Setting it through an element or attribute would violate separation of style and markup. Yeah, these are the reasons I ask - shadowRoot IMO kind of solves these parts of the problem in really the only sensible way I can imagine, but I think what you're saying is it's too much - and - is there a lesser thing, something maybe underneath that proposal which just offers this part. That's why I say, kind of a fragment root of which maybe if we get to shadow dom it could be a special type of? I guess you're not proposing that but I am saying what about a proposal like that would it answer your concerns? -- https://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Custom element lifecycle callbacks
On 1/9/15 9:33 AM, Anne van Kesteren wrote: On Fri, Jan 9, 2015 at 3:09 PM, Boris Zbarsky bzbar...@mit.edu wrote: In any case, the fact that we're even _having_ this discussion and that it needs careful reading of the HTML spec is my point. It does seem however we could define this in a way that is safe. If by this you mean cloning of file inputs, then obviously yes. I never implied otherwise, as far as I can tell. If by this you mean a change from the current behavior to delayed cloning steps, without auditing all the cloning steps to make sure we don't end up in weird inconsistent states, then I don't think so. You really do have to carefully audit all the cloning steps in the spec, as well as any future cloning steps. -Boris
Re: Shadow tree style isolation primitive
On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell bkard...@gmail.com wrote: For clarity, are you suggesting you'd control the matching boundary via CSS somehow or you'd need an indicator in the tree? A new element/attribute or something like a fragment root (sort of a shadowroot-lite)? I wasn't suggesting anything since I'm not sure what the best way would be. It has to be some flag that eventually ends up on an element so when you do selector matching you know what subtrees to ignore. If you set that flag through a CSS property you'd get circular dependencies, but perhaps that can be avoided somehow. Setting it through an element or attribute would violate separation of style and markup. -- https://annevankesteren.nl/
Re: Shadow tree style isolation primitive
For the record, I am a huge fan of exploring this. I tried a couple of times, but was unable to extract this primitive from Shadow DOM in a clean way. I talked with Tab late last year about restarting this effort, so this is timely. :DG On Fri, Jan 9, 2015 at 7:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell bkard...@gmail.com wrote: For clarity, are you suggesting you'd control the matching boundary via CSS somehow or you'd need an indicator in the tree? A new element/attribute or something like a fragment root (sort of a shadowroot-lite)? I wasn't suggesting anything since I'm not sure what the best way would be. It has to be some flag that eventually ends up on an element so when you do selector matching you know what subtrees to ignore. If you set that flag through a CSS property you'd get circular dependencies, but perhaps that can be avoided somehow. Setting it through an element or attribute would violate separation of style and markup. -- https://annevankesteren.nl/
Re: Custom element lifecycle callbacks
On Thu, Jan 8, 2015 at 5:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/8/15 10:56 AM, Anne van Kesteren wrote: 2) For normal elements we act directly when they are cloned or adopted. How much interest is there in delaying what happens for normal elements to align them with custom elements? Which things are we talking about delaying? As much as possible. I'm pretty sure the prototype change that happens in Gecko on adopt right now is part of our security model and can't easily be delayed. I think we did actually discuss delaying this as part of how we wanted to solve this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 The idea was that for normal elements the callback would change the prototype, but for custom elements the custom element would have to write that implementation themselves. Thinking of this now however makes me think that such a solution would not exactly be ideal for a proper subclassing story (you would expect to inherit the callback behavior of normal elements). The other main thing that happens sync on clone is state propagation (e.g. copying of values for inputs, right)? There are some security considerations there too that would need to be considered for every bit of state that's propagated; consider: var input = document.createElement(input); input.value = file:///etc/passwd; var newInput = input.cloneNode(); newInput.type = file; I would like to see an actual list of the things we're considering delaying so we can think about the implications of doing that. Note that in the above example cloning callbacks would happen after the cloneNode() call but still before type is being set. So that might be okay? Custom elements have callbacks for these things (speculate ones marked with *): * created * attached * detached * attribute changed * adopted* * cloned* So far I've only been looking at the implications for aligning the last three. The first three seem a lot harder (and it's not entirely clear to me the created design even works that well, see the upgrading thread). -- https://annevankesteren.nl/
Re: Custom element lifecycle callbacks
On Fri, Jan 9, 2015 at 3:30 AM, Adam Klein ad...@chromium.org wrote: Do you have a proposal for where these symbols would be vended? In ES, builtin symbols are available as properties on the Symbol object, but clearly WebIDL shouldn't be adding things there. This might be a good question for public-script-coord. My idea was to put them on Node or Element as statics, similar to the Symbol object design. The discussion on public-script-coord is this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27553 -- https://annevankesteren.nl/
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On 01/07/2015 10:08 AM, Koji Ishii wrote: While I agree that it's nice, I have mild preference to return a clone. As Olii said, changing from clone to live would involve quite a bit of code. I don't think he said that. He said implementing the live-ness properly can be somewhat annoying, which I think refers to implementing updates on Ranges in general. As I wrote much of this code in Gecko I agree with what he is saying: 1. updating Ranges in response to DOM mutations is somewhat complex, 2. updating the selection though is simple - if you implement it as a set of Ranges you get it for free I don't think supporting live Ranges here is hard or would involve quite a bit of code (1 does, but not 2). But UAs must implement 1. for arbitrary Ranges anyway (per the DOM spec). /Mats
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
Thank you Aryeh for the explanation to this newbie, I understand that better now. That was a bit different from what I had in mind, but glad to see you agree to return a value. So, sounds like we're in consensus to change it to return a value? /koji On Fri, Jan 9, 2015 at 9:40 PM, Aryeh Gregor a...@aryeh.name wrote: On Wed, Jan 7, 2015 at 12:32 AM, Ryosuke Niwa rn...@apple.com wrote: Trident (since IE10) and Gecko both return a live Range, which can be modified to update selection. WebKit and Blink both return a clone Range so that any changes to the Range doesn't update the selection. It appears that there is a moderate interest at Mozilla to change Gecko's behavior. Does anyone have a strong opinion about this? The advantage of the IE/Gecko behavior is you can alter the selection using Range methods. The advantage of the WebKit/Blink behavior is you can restrict the ranges in the selection in some sane fashion, e.g., not letting them be in detached nodes. WebKit/Blink cannot change to return a reference unless they allow arbitrary ranges in selections, which last I checked they don't, and I'm guessing they would have trouble supporting it. Whereas IE/Gecko could easily change, and authors who already supported WebKit/Blink wouldn't lose any features. So I guess returning a value makes the most sense. (If you return a reference, you must allow arbitrary ranges, because the author could call setStart() on the returned range with any value you want, and they will expect that the range's new start will be exactly what they set it to.) On Wed, Jan 7, 2015 at 12:08 PM, Koji Ishii kojii...@gmail.com wrote: I also guess that we need to ask more work to the spec editor to support the liveness, such as: My old spec had no trouble answering these questions. I don't think it's particularly complicated, except it requires allowing arbitrary ranges to be in selections, and I suspect WebKit/Blink would have trouble dealing with that. - What will happen to the live-object on removeAllRanges()? The range is detached from the selection, so further changes have no effect. - Would the live-object keeps the same reference for removeAllRanges() + addRanges()? No. If you use addRange(), a reference to your existing range is put in the selection. - It may never happen, but when multiple ranges are supported, are they bound to index? Everyone wants to kill this feature, so it's moot. Specing them in detail and writing tests for all these cases would be quite a bit of work. I already wrote the spec and the tests, although I'm sure there are still some gaps. I think WebKit/Blink are the bigger obstacle.
Re: Shadow tree style isolation primitive
Here's an attempt from 2012. This approach doesn't work (the trivial plumbing mentioned in the doc is actually highly non-trivial), but maybe it will give some insights to find the right a proper solution: https://docs.google.com/document/d/1x2CBgvlXOtCde-Ui-A7K63X1v1rPPuIcN2tCZcipBzk/edit?usp=sharing :DG On Fri, Jan 9, 2015 at 7:54 AM, Dimitri Glazkov dglaz...@google.com wrote: For the record, I am a huge fan of exploring this. I tried a couple of times, but was unable to extract this primitive from Shadow DOM in a clean way. I talked with Tab late last year about restarting this effort, so this is timely. :DG On Fri, Jan 9, 2015 at 7:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell bkard...@gmail.com wrote: For clarity, are you suggesting you'd control the matching boundary via CSS somehow or you'd need an indicator in the tree? A new element/attribute or something like a fragment root (sort of a shadowroot-lite)? I wasn't suggesting anything since I'm not sure what the best way would be. It has to be some flag that eventually ends up on an element so when you do selector matching you know what subtrees to ignore. If you set that flag through a CSS property you'd get circular dependencies, but perhaps that can be avoided somehow. Setting it through an element or attribute would violate separation of style and markup. -- https://annevankesteren.nl/
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor a...@aryeh.name wrote: - It may never happen, but when multiple ranges are supported, are they bound to index? Everyone wants to kill this feature, so it's moot. Could you please point me to the discussion where this conclusion was reached? I searched the mailing list but I only found a few ambivalent threads, none indicating that everyone wants to kill this. Thanks.
Re: Shadow tree style isolation primitive
On Fri, Jan 9, 2015 at 8:08 AM, Dimitri Glazkov dglaz...@google.com wrote: Here's an attempt from 2012. This approach doesn't work (the trivial plumbing mentioned in the doc is actually highly non-trivial), but maybe it will give some insights to find the right a proper solution: https://docs.google.com/document/d/1x2CBgvlXOtCde-Ui-A7K63X1v1rPPuIcN2tCZcipBzk/edit?usp=sharing tl;dr: Cramming a subtree into a TreeScope container and then hanging that off the DOM would do the job for free (because it bakes all that functionality in).
[Bug 26904] Introduce typedef for IDBKeyPath, use it
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26904 Joshua Bell jsb...@google.com changed: What|Removed |Added Resolution|LATER |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug.
Re: Custom element lifecycle callbacks
On Fri, Jan 9, 2015 at 12:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: Ok, what about this testcase: var parent = document.createElement(x-my-element); var input = document.createElement(input); parent.appendChild(input); input.value = file:///etc/passwd; parent.cloneNode(true); and then in the cloning callback for x-my-element, assuming newNode is the clone: newNode.firstChild.type = file; That seems to me like it would do the type set before the cloning callback for the input runs, right? Both parent and input need to be cloned in this case. While parent's callback runs it changes the type of input, at which point input's callback runs. So, yes. It's a bit unclear to me why When an input element's type attribute changes state does not sanitize this value in any way though or how cloning it makes it a security concern. -- https://annevankesteren.nl/
Re: Custom element lifecycle callbacks
On 1/9/15 8:46 AM, Anne van Kesteren wrote: As far as I can tell from the specification, when the value IDL attribute is in the filename mode, any values that might be stored in internal slots are ignored. Hmm... That was not obvious to me, but OK. I guess it uses the list of selected files instead? And then the claim is that the only sanitization that's needed is step 2 of When an input element's type attribute changes state, to lose the old value, which was being stored all this time, when changing out of the file upload state? That's pretty bizarre, since it requires storing information that will never get used, but ok. As far as I can tell from the specification you cannot influence the value returned by input type=file.value in any way. UAs do not seem to be interoperable here. In particular, in some UAs cloning a file input copies the list of selected files, and in some it does not, with the spec seeming to side with the latter. It's a bit weird that cloning would normally copy the value, but not for file inputs. In any case, the fact that we're even _having_ this discussion and that it needs careful reading of the HTML spec is my point. -Boris
Re: Custom element lifecycle callbacks
On Fri, Jan 9, 2015 at 3:09 PM, Boris Zbarsky bzbar...@mit.edu wrote: In any case, the fact that we're even _having_ this discussion and that it needs careful reading of the HTML spec is my point. It does seem however we could define this in a way that is safe. -- https://annevankesteren.nl/
Shadow tree style isolation primitive
I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not necessarily user and user agent stylesheets) and requiring a special selector, such as , to pierce through the boundary. This is a bit different from the `all` property as that just changes the values of all properties, it does not make a selector such as div no longer match. So to be clear, the idea is that if you have a tree such as section class=example h1Example/h1 div ... /div /section Then a simple div selector would not match the innermost div if we isolated the section. Instead you would have to use section div or some such. Or perhaps associate a set of selectors and style declarations with that subtree in some manner. -- https://annevankesteren.nl/
Re: Custom element lifecycle callbacks
On Fri, Jan 9, 2015 at 2:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/15 7:14 AM, Anne van Kesteren wrote: OK. So just to be clear, the type will be set before the input's cloning callback runs, yes? Yes. It's a bit unclear to me why When an input element's type attribute changes state does not sanitize this value When the type changes it sanitizes the value of the input. Though I see nothing in the spec to indicate this; I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27791 As far as I can tell from the specification, when the value IDL attribute is in the filename mode, any values that might be stored in internal slots are ignored. Because if the cloning steps in HTML are left as-is but run after script can change the type, then you can create a file input with an arbitrary value filled in. Which is a security concern. As far as I can tell from the specification you cannot influence the value returned by input type=file.value in any way. -- https://annevankesteren.nl/
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On Wed, Jan 7, 2015 at 12:32 AM, Ryosuke Niwa rn...@apple.com wrote: Trident (since IE10) and Gecko both return a live Range, which can be modified to update selection. WebKit and Blink both return a clone Range so that any changes to the Range doesn't update the selection. It appears that there is a moderate interest at Mozilla to change Gecko's behavior. Does anyone have a strong opinion about this? The advantage of the IE/Gecko behavior is you can alter the selection using Range methods. The advantage of the WebKit/Blink behavior is you can restrict the ranges in the selection in some sane fashion, e.g., not letting them be in detached nodes. WebKit/Blink cannot change to return a reference unless they allow arbitrary ranges in selections, which last I checked they don't, and I'm guessing they would have trouble supporting it. Whereas IE/Gecko could easily change, and authors who already supported WebKit/Blink wouldn't lose any features. So I guess returning a value makes the most sense. (If you return a reference, you must allow arbitrary ranges, because the author could call setStart() on the returned range with any value you want, and they will expect that the range's new start will be exactly what they set it to.) On Wed, Jan 7, 2015 at 12:08 PM, Koji Ishii kojii...@gmail.com wrote: I also guess that we need to ask more work to the spec editor to support the liveness, such as: My old spec had no trouble answering these questions. I don't think it's particularly complicated, except it requires allowing arbitrary ranges to be in selections, and I suspect WebKit/Blink would have trouble dealing with that. - What will happen to the live-object on removeAllRanges()? The range is detached from the selection, so further changes have no effect. - Would the live-object keeps the same reference for removeAllRanges() + addRanges()? No. If you use addRange(), a reference to your existing range is put in the selection. - It may never happen, but when multiple ranges are supported, are they bound to index? Everyone wants to kill this feature, so it's moot. Specing them in detail and writing tests for all these cases would be quite a bit of work. I already wrote the spec and the tests, although I'm sure there are still some gaps. I think WebKit/Blink are the bigger obstacle.
Re: Custom element lifecycle callbacks
On 1/9/15 7:14 AM, Anne van Kesteren wrote: Both parent and input need to be cloned in this case. While parent's callback runs it changes the type of input, at which point input's callback runs. So, yes. OK. So just to be clear, the type will be set before the input's cloning callback runs, yes? It's a bit unclear to me why When an input element's type attribute changes state does not sanitize this value When the type changes it sanitizes the value of the input. Though I see nothing in the spec to indicate this; I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27791 But in this case the value is not set yet when the type changes. Then the cloning callback runs and sets the value on the now-file-type input, no? In particular, the current spec for input says: The cloning steps for input elements must propagate the value, dirty value flag, checkedness, and dirty checkedness flag from the node being cloned to the copy. This is not conditional on the input type in any way, unlike .value sets. So if we allow the type to change before the cloning steps run, the cloning steps need to be adjusted to deal with this situation. And in particular, all cloning steps need to be carefully audited to deal with issues like this. or how cloning it makes it a security concern. Because if the cloning steps in HTML are left as-is but run after script can change the type, then you can create a file input with an arbitrary value filled in. Which is a security concern. -Boris
Re: Custom element lifecycle callbacks
On 1/9/15 4:28 AM, Anne van Kesteren wrote: On Thu, Jan 8, 2015 at 5:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: var input = document.createElement(input); input.value = file:///etc/passwd; var newInput = input.cloneNode(); newInput.type = file; Note that in the above example cloning callbacks would happen after the cloneNode() call but still before type is being set. So that might be okay? Ok, what about this testcase: var parent = document.createElement(x-my-element); var input = document.createElement(input); parent.appendChild(input); input.value = file:///etc/passwd; parent.cloneNode(true); and then in the cloning callback for x-my-element, assuming newNode is the clone: newNode.firstChild.type = file; That seems to me like it would do the type set before the cloning callback for the input runs, right? -Boris
