- From: <bugzilla@jessica.w3.org>
- Date: Sun, 17 Jun 2012 10:00:53 +0000
- To: public-css-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17523 Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kennyluck@csail.mit.edu --- Comment #1 from Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu> 2012-06-17 10:00:53 UTC --- (In reply to comment #0) > The CSSOM View spec is unclear on how implementations should react when a > client attempts to set a value for an immutable property. Examples include any > of the properties of the Screen interface in section 4.2. These sort of information is encoded in the WebIDL fragment. In this case, it is # readonly attribute unsigned long height; and WebIDL interprets "readonly"[1] as # The attribute setter is undefined if the attribute is declared readonly # and has neither a [PutForwards] nor a [Replaceable] extended attribute # declared on it. and the attribute setter, when undefined, fails silently: [[ << var o = {get x(){return 1;}} >> undefined << o.x >> 1 << o.x = 0 >> 0 << o.x >> 1 ]] > The following code should throw an exception, but instead fails silently: > > window.screen.height = 0; If this is your main request, I would suggest you change the title as such (ideally, send this along with why you think so to www-style to attract broader discussions, since "readonly" is as far as I can tell a common pattern in various interfaces so you might want to provide stronger rationale.) Also, you might want to provide information about current implementations. (Do some of them throw instead of fail silently?) > This behavior should be specified in the document. I do from time to time think these "keywords" in WebIDL fragments should be linked to corresponding WebIDL parts... [1] http://dev.w3.org/2006/webapi/WebIDL/#dfn-attribute-setter -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Sunday, 17 June 2012 10:00:56 UTC