Re: [whatwg] High-density canvases
On Tue, Sep 10, 2013 at 10:46 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: High-end laptops have high-dpi screens (the Pixel I'm using right now has one), and they're slowly spreading down the price scale. On Mac there are Retinas of course, and on Windows Firefox defaults to a non-1.0 devicePixelRatio on many systems now (anything where the default Windows font DPI is not 96). Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] High-density canvases
On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier caban...@gmail.com wrote: There's a thread on www-style: http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html It's been in firefox for a while and blink is going to ship it soon: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ devicePixelRatio has reflected page zoom in Firefox ever since we first exposed it (because the thing it maps to internally has always been affected by page zoom). Actually what I really think we should do is also change the window.devicePixelRatio for pinch zoom. Combined with the suggestions for canvas, that would allow (as Rik pointed out on IRC) for high-quality canvas all the way zoomed in, and for cheap canvases when zoomed out I believe pinch zoom should not change devicePixelRatio. It would be nice if there was a standard way to determine pinch zoom though and if the canvas could automatically resize. Pinch-zoom is hard because we don't want to trigger reflows or other expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] Should video controls generate click events?
On Wed, 11 Sep 2013 01:35:00 +0200, Ian Hickson i...@hixie.ch wrote: On Tue, 20 Aug 2013, Rick Waldron wrote: Also, at the time, the surface click to play was non-standard and incredibly annoying because it just showed up as someone's pet feature in Firefox. (I'm still not sure if it's a standard feature, I can't find anything in the spec about it, but I could've just missed it) It's not documented in the spec, but it seems reasonable. On Wed, 21 Aug 2013, Robert O'Callahan wrote: I think you basically have to assume that if you specify controls then the controls may accept clicks anywhere in the video element. There's nothing in the spec to say that the controls must be restricted to a bar of a certain height at the bottom of the element. True, but there _is_ something now that says that if the browser considers it the user interacting with a control, that there shouldn't be events sent to the page. It's either a control (no events), or an activation behaviour (click events, can be canceled by preventDefault()). Saying that Firefox's click anywhere to play isn't a control but rather activation behavior for the element makes sense. If other browsers want to implement that behavior, it would be good if the spec called out this difference. Should we make this an explicit activation behaviour for the video element if it has a controls= attribute? That might be good so that the behavior is consistent between browsers. However, I think it should be conditional on whether the controls are visible rather than whether the controls attribute is present. -- Simon Pieters Opera Software
Re: [whatwg] Should video controls generate click events?
On Wed, Sep 11, 2013 at 10:48 AM, Simon Pieters sim...@opera.com wrote: On Wed, 11 Sep 2013 01:35:00 +0200, Ian Hickson i...@hixie.ch wrote: On Wed, 21 Aug 2013, Robert O'Callahan wrote: I think you basically have to assume that if you specify controls then the controls may accept clicks anywhere in the video element. There's nothing in the spec to say that the controls must be restricted to a bar of a certain height at the bottom of the element. True, but there _is_ something now that says that if the browser considers it the user interacting with a control, that there shouldn't be events sent to the page. It's either a control (no events), or an activation behaviour (click events, can be canceled by preventDefault()). Saying that Firefox's click anywhere to play isn't a control but rather activation behavior for the element makes sense. If other browsers want to implement that behavior, it would be good if the spec called out this difference. Should we make this an explicit activation behaviour for the video element if it has a controls= attribute? That might be good so that the behavior is consistent between browsers. However, I think it should be conditional on whether the controls are visible rather than whether the controls attribute is present. What does visible mean here, is it to handle cases where the UA force-enables the controls without adding the controls attribute to the DOM? Philip
Re: [whatwg] High-density canvases
On Wed, Sep 11, 2013 at 1:20 AM, Robert O'Callahan rob...@ocallahan.org wrote: Actually what I really think we should do is also change the window.devicePixelRatio for pinch zoom. Combined with the suggestions for canvas, that would allow (as Rik pointed out on IRC) for high-quality canvas all the way zoomed in, and for cheap canvases when zoomed out I believe pinch zoom should not change devicePixelRatio. It would be nice if there was a standard way to determine pinch zoom though and if the canvas could automatically resize. Pinch-zoom is hard because we don't want to trigger reflows or other expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Yes. Somewhere (HTML? CSSOM? CSSOM-View?) needs to define layout-affecting zoom and visual zoom, define what goes where, and then we can just hook things to layout-affecting zoom and be done with it. (I think dbaron had some name suggestions, or at least some name *objections*, related to this stuff.) ~TJ
Re: [whatwg] Should video controls generate click events?
On Wed, Sep 11, 2013 at 11:18 AM, Simon Pieters sim...@opera.com wrote: On Wed, 11 Sep 2013 10:51:44 +0200, Philip Jägenstedt phil...@opera.com wrote: That might be good so that the behavior is consistent between browsers. However, I think it should be conditional on whether the controls are visible rather than whether the controls attribute is present. What does visible mean here, is it to handle cases where the UA force-enables the controls without adding the controls attribute to the DOM? Yes. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#expose-a-user-interface-to-the-user Right, connecting it to the expose a user interface to the user concept seems best. Philip
Re: [whatwg] URL resolution of fragment urls in html5 webapps
On Tue, Sep 10, 2013 at 8:34 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 10 Jul 2013, Rafael Weinstein wrote: I'm curious: Is it useful to have fragment URL resolve against anything other than the display url? I.e. when is the current behavior wrt fragments appropriate. It's a good question. I thought the old IETF specs for URLs said you had to do otherwise, but nobody seems to have implemented that. Browsers have been inconsistent on this actually, not sure if they still are. I think if we want to do this differently, then after trimming whitespace to obtain the URL, the a element should have a special case for # and pick a different base URL at that point. https://tools.ietf.org/html/rfc2396#section-4.2 has the vague wording that does not take the base URL into account. In https://tools.ietf.org/html/rfc3986#section-4.4 it does. The problem with the former is that it's not clear when it applies, but we could make that clear by only doing it in certain contexts, as I suggested above. -- http://annevankesteren.nl/
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Tue, Sep 10, 2013 at 8:54 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 12 Jul 2013, Anne van Kesteren wrote: But then we shouldn't garble pathname either and we do because we have to. So I'm not sure that line of reasoning makes sense. I do think we should offer some kind of conversion utility between the two. It is unfortunate that resolving URLs does that, it's true. But just because we're constrained here, why should we mess up domains also? Consistency. It means the entire URL is effectively a byte sequence. And it's very clear what the DNS lookup will be. And given that they keep insisting on changing what certain code points map to over in IETF-land (with limited support from browser vendors :/), it seems safer too. -- http://annevankesteren.nl/
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Wed, 11 Sep 2013, Anne van Kesteren wrote: On Tue, Sep 10, 2013 at 8:54 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 12 Jul 2013, Anne van Kesteren wrote: But then we shouldn't garble pathname either and we do because we have to. So I'm not sure that line of reasoning makes sense. I do think we should offer some kind of conversion utility between the two. It is unfortunate that resolving URLs does that, it's true. But just because we're constrained here, why should we mess up domains also? Consistency. Surely the consistency of the API matching the input is more important than the consistency of the API _not_ matching the input... It means the entire URL is effectively a byte sequence. I don't know what you mean here. And it's very clear what the DNS lookup will be. Why do you think people care more about that than about the URL matching what they wrote in the markup? And given that they keep insisting on changing what certain code points map to over in IETF-land (with limited support from browser vendors :/), it seems safer too. I don't understand what is safer. Surely if the punycoding step keeps changing, it's less safe, since it'll mean that the results will change without the author expecting it. If we don't punycode in the API, then the result will be the same regardless of the punycode step. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] URL resolution of fragment urls in html5 webapps
On Wed, 11 Sep 2013, Anne van Kesteren wrote: On Tue, Sep 10, 2013 at 8:34 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 10 Jul 2013, Rafael Weinstein wrote: I'm curious: Is it useful to have fragment URL resolve against anything other than the display url? I.e. when is the current behavior wrt fragments appropriate. It's a good question. I thought the old IETF specs for URLs said you had to do otherwise, but nobody seems to have implemented that. Browsers have been inconsistent on this actually, not sure if they still are. I think if we want to do this differently, then after trimming whitespace to obtain the URL, the a element should have a special case for # and pick a different base URL at that point. https://tools.ietf.org/html/rfc2396#section-4.2 has the vague wording that does not take the base URL into account. In https://tools.ietf.org/html/rfc3986#section-4.4 it does. The problem with the former is that it's not clear when it applies, but we could make that clear by only doing it in certain contexts, as I suggested above. Well presumably we wouldn't want to only do it for a, since then links would work but SVG wouldn't (the exact opposite of the situation in Chrome now, for what it's worth). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On Wed, 11 Sep 2013, Robert O'Callahan wrote: Pinch-zoom is hard because we don't want to trigger reflows or other expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Unless I'm missing something fundamental, changing the pixel density doesn't cause a layout, it's changing the width that causes a layout. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Sep 2013, Robert O'Callahan wrote: Pinch-zoom is hard because we don't want to trigger reflows or other expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Unless I'm missing something fundamental, changing the pixel density doesn't cause a layout, it's changing the width that causes a layout. It will do a layout if the width is directly or indirectly dependent on the CSS pixelratio. For instance, notice how the text boxes reflow if you change the page zoom: http://jsfiddle.net/BtAK7/1/
Re: [whatwg] High-density canvases
On Wed, 11 Sep 2013, Rik Cabanier wrote: On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Sep 2013, Robert O'Callahan wrote: Pinch-zoom is hard because we don't want to trigger reflows or other expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now. Unless I'm missing something fundamental, changing the pixel density doesn't cause a layout, it's changing the width that causes a layout. It will do a layout if the width is directly or indirectly dependent on the CSS pixelratio. For instance, notice how the text boxes reflow if you change the page zoom: http://jsfiddle.net/BtAK7/1/ Sure. But pinch-zoom doesn't change the width. (Page zoom does.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sortable Tables
On Fri, 19 Jul 2013, Stuart Langridge wrote: On Thu, Jul 18, 2013 at 11:48 PM, Ian Hickson i...@hixie.ch wrote: but time is more of a problem if you have multiple things in one cell. For example, one semi-common pattern is to put some data and an input type=checkbox in a single cell, like tdWed 7th November, 10.00am GMT input type=checkbox name=whatever/td Why can't the checkbox be in a separate cell? I'm not saying that this is the way I do it: I'm saying this is what authors are currently doing. If the checkboxes need to be in a separate cell, then OK, but we'd need to explain that that's the case: that is, the answer to how do I sort a table by a column containing both data and a checkbox is you can't. Put the checkboxes in a separate column. Yeah, fair enough. Hmm. So what should we do? Allow there to be multiple elements in the cell, but if we see a time/meter/progress/data, ignore all the others for sorting? Just look at the first element and if it's one of those, ignore all the others for sorting? I fear situations where people have two time elements and want them sorting by one then the other, or something. We could also have a way to say that certain elements are ignored... ignore all input and img elements? Ignore all elements with a new ignore-me- when-sorting= attribute? I agree we should support the case you give. Indeed, the objection to wrapping the whole cell content in time applies to any cell which contains a time *and something else*: for example, tdWed 7th November, 10.00am GMT img src=morning.png/td where the image displays a nice picture of the sun so you can see that it's morning, but is only debatably part of the actual time itself. I'd feel much more comfortable saying the sun was part of the time than about the checkbox being part of the time. :-) (And if you put it in a separate column, then there'll be a cell border between the time and the icon.) That can be fixed with CSS, of course. Using data to wrap the whole cell is OK, but using time to wrap a bunch of non-time content isn't, really. In this situation would you recommend tddata value=2012-11-07T10:00Ztime datetime=2012-11-07T10:00ZWed 7th November, 10.00am GMT/time/data/td which seems rather redundant to me? I would recommend using two cells, but you could do that too. It would mean the keys were compared as strings, though, rather than as datetimes. Things wouldn't work if you mixed data and time elements with those values (e.g. if some cells didn't have checkboxes and so you used just time in some cases), since strings sort after times. erm. Why is the sort clever about datetimes? Time zones, knowing that 1:01 comes before 01:02, knowing that P1D comes before 25h, knowing that 1000-01-01 comes before 01010-10-10, knowing that -01:00 comes before Z comes before +01:00, knowing that 2013-W37 comes before 2013-10-11 but after 2013-10-09, etc. Specifically, in order to specify a datetime attribute on a time element, you have to specify it as a string, and those strings sort correctly in order with other datetime strings. Not necessarily. Leading zeros are a problem for times, local-dates- and-times, and yearless dates, and all the other time formats have crazy stuff like time zones, multiple valid formats, etc. Also, the spec supports mixing different formats like week dates and years with date-and- time formats. Maybe pass a cloneNode of each TD? Too expensive (what if one of the nodes is a 24 MB image, or a plugin?). But the cloned node isn't inserted into the document, right? Surely no rendering engine is going to fully instantiate a 24MB image that's not even in the document? An img element is instantiated when created, regardless of whether it's in a document or not. That's how you can do preloading of images for rollovers, if you're stuck in the 90s. :-) Or have the sorter work out the sortable *value* of the field (from the content, or the data value wrapper) and then pass the values, not the actual cells? Then the comparator can't destroy anything. It seems to me like that doesn't give you anything that you couldn't do by just setting the keys manually on the table before the sort happens (which you can do easily onsort= in the current model). Big difference: setting the keys manually onsort is indeed something that the author can do. But calculating the sortable value of the cell (either from an explicitly set key, or from the cell content) is something that the *browser* can do: that is, it can be part of the spec. So then you're never in danger from dangerous comparators, because the sort engine algorithm is: (1) for each cell in the column, calculate its sortable value and make a list of [sortable value, reference to cell], (2) sort that list, and for each comparison during sorting pass the two sortable values you want to
Re: [whatwg] img loading events - can load error fire for the same image?
On Mon, 22 Jul 2013, Jake Archibald wrote: Take http://jsbin.com/ifihex/1/edit - the image on this page receives a valid full HTTP request, but the received data isn't valid image data (it's html). Starting from http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data, here's how I see the image loading according to the spec (everything seems fine until step 14) [...] * this is the point where I start to get lost, I'm not sure which else-like statements (as in On the other hand and Otherwise) are linked to which if-like statements Oh, yeah, this is very confusing. My bad. I've tried to fix it. Let me know how it is now. load is fired once the width height can be determined, which suggests that an un-decodable image, but with intact headers (which give the width height) will fire load but not error. I agree with this, as it means the browser can defer decoding to render time, but do we need a way in JS to confirm an image is decodable? What's the use case? (Surely the server should check this on the server.) The use-case would be image loading that happened without a server. Eg, an in-browser Photoshop that operated without user interaction. User selects file on their machine, it has correct headers so fires a load event, but cannot be painted onto the canvas (or paints incorrectly) due to corrupt data. The in-browser app is unable to detect the image is corrupt without building a decoder/validator in JS. Well... there is one way to tell right now. You can try to draw it to a canvas and see if anything got drawn by examining all the pixels; if no pixels got drown, then it has some data integrity issues. But really if you're implementing a Photoshop equivalent, you really _should_ implement your own decoder, so you can do things like EXIF manipulation, handle other image formats, do pngcrush-like work, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, 10 Sep 2013, Dominic Mazzoni wrote: We've finished implementing drawSystemFocusRing and drawCustomFocusRing in Chrome. Try it in Chrome 31 or higher (either canary or dev channel should work today). You'll need to go to chrome://flags and enable *experimental canvas features*, then restart the browser. Here's a demo I built that uses drawSystemFocusRing: http://dmazzoni-google.github.io/canvas-focus-ring-demo/ Looks good. Was your conclusion that the spec was ok as is, or did you deviate from the spec in some way that needs a spec change? (Apologies if you've already reported some feedback that I've lost track of; I didn't see any when I looked just now.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] remove resetClip from the Canvas 2D spec
On Fri, 9 Aug 2013, Simon Sarris wrote:
As an alternative [to resetClip()] I would propose something like
setClip() or setClip(path) (with the former working on the current path,
just like clip()/fill()/stroke() does).
Seems like this would have the same problems as resetClip(), since it's
essentially the same as a call to resetClip() followed by a call to clip().
On Fri, 9 Aug 2013, Justin Novosad wrote:
What if resetClip restored the clip to what it was at the save call that
created the current state stack level? In other words, restore the clip,
but without popping it off the save/restore stack.
Also, resetMatrix could be defined to do the same.
Wouldn't that be the same as just save()/clip()/restore() ?
On Mon, 12 Aug 2013, Rik Cabanier wrote:
It would be good to hear specific use cases for 'resetClip' so we can make
that call.
The main use case would be something like:
c.save();
c.resetTransform();
c.resetClip();
// draw something at the top right...
c.restore();
...deep inside some draw code.
Also, resetMatrix could be defined to do the same.
Is that API defined somewhere?
I think Justin meant resetTransform().
On Mon, 12 Aug 2013, Simon Sarris wrote:
I think most performance-minded use cases will be fine with junov's idea
since they will not want to touch the stack in the first place.
Here's a simple use case: Suppose there are nested objects to be drawn,
Panels, TextBlocks, and other visual elements. Panels are containers that
draw a background and all of their children - and they contain any number
of Panels or TextBlocks or other elements, and TextBlocks set the context
font (to their font) and draw some text.
The drawing structure is hierarchical, and drawn elements may be offset
from their immediate parent. So a drawing hierarchy might look like this:
Panel(A)
Panel(B)
TextBlock
TextBlock
That is, Panel(A) contains Panel(B) and a TextBlock. And Panel(B) contains
another TextBlock. In practice, nesting could be much deeper and more
complicated.
Now suppose also that Panels have some settings, such as a maximum width,
that might cause their visual elements to be clipped. So a panel might need
to save(), clip(), draw all of its children, and then restore(). Nesting
means multiple levels of clipping, for instance with the above hierarchy it
might look like:
Panel(A)
clip (save)
drawChildren:
Panel(B)
clip (save)
drawChildren:
TextBlock
sets font X
fillText
restore
TextBlock
sets font X
fillText
restore
This is problematic, because it means:
1. I must use save() and restore(), which are slow in their own right
I'm pretty sure save() and restore() are the right solution here. If those
don't work, we should fix those, not add more features that might have
their own issues.
2. The usage of save() and restore() means that, even if all (or most) of
my fonts are set to the same value, I have to keep setting them over and
over. Setting the font is slow in practice, even if it is set to the same
value as before, and so it should be cached if at all possible.
Again, if settings fonts is slow, that should be fixed independently of
resetClip().
On Mon, 12 Aug 2013, Justin Novosad wrote:
Good point, I think part of the problem has to do with the fact that save
is non-selective (saves all of the state).
Might be worthwhile to have a selective save that pushes only a
user-specified subset of the current state onto the stack.
There's no reason save() and restore() need be slow just because they save
a lot. It's relatively easy to have a stack that only saves the things
that have changed (e.g. by setting a bit when you change things, so you
know what has changed, and then only pushing onto the stack the
instructions to change the stuff that has changed).
On Mon, 12 Aug 2013, Simon Sarris wrote:
Yes, since save() and restore() save and restore everything, it creates
the side effect of needing to set ctx.font/fillStyle/strokeStyle more
often than otherwise, which are slow to set, probably because of some
CSS parser activity, but I'm not wise enough to know.
save() and restore() should have no reason to go through the CSS parser.
On Mon, 12 Aug 2013, Justin Novosad wrote:
Ok, so here is a simple proposal:
IDL:
enum CanvasSaveMode { all, transform, clip, transform-and-clip };
save(optional CanvasSaveMode mode);
Modes:
all: save the entire rendering context state
transform: save only the current transform
clip: save only the current clip
if mode is not specified, the entire context state is saved (for backward
compatibility)
The restore method's interface does not change. It restores whatever state
was saved by the matching save call.
I don't understand what problem this is solving.
On Tue, 13
Re: [whatwg] [[GetOwnProperty]] for named properties of the Window object
On 9/11/13 6:05 PM, Gavin Barraclough wrote: Interesting, I had just assumed this was okay – is it not spec-compliant for Window.prototype to be a named properties object? No, it's not. The spec defines exactly what the prototype chain looks like here. See the definitions of [[Prototype]] at http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object and http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object (item 1 at the latter). So the chain by default is window - Window.prototype - named properties object - EventTarget.prototype - Object.prototype. This allows specification of the named properties object without having to worry about weird interactions with name collisions on Window.prototype, whether with properties it has by default or properties someone wants to add to it. Note that the named properties object does not allow [[DefineOwnProperty]], so if it were Window.prototype then you wouldn't be able to add any properties to Window.prototype! I believe these properties are implemented as shadowable in the same way as [Replaceable] properties [Replaceable] properties need the magic they have because they're accessor properties, which normally can't be shadowed via assignment. But named properties on the named properties object are value properties, so simply making them writable allows them to be shadowed. In fact, that's the only way to make them shadowable. (and then assume a modified behaviour of ES [Put] for properties with this attribute, to permit overwrite even if readonly). I don't think a special [Put] is needed if the properties aren't readonly. -Boris
