Does JS bound to need to inherit from HTMLElement?

2013-04-12 Thread John J Barton
While I completely understand the beauty of having any JS object bound to an inherit functions that make that object 'be an element', I'm unsure of the practical value. To me the critical relationship between the JS and the element is JS object access to its corresponding element instance without

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-12 Thread Dimitri Glazkov
On Fri, Apr 12, 2013 at 2:25 PM, Scott Miles wrote: > I realize this doesn't fit any existing conceptual model (that I know of) > but I think it's worth pointing out that all we really want to do is define > a prototype for the element (as opposed to running arbitrary script). > > Invented pseudo-

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-12 Thread Daniel Buchner
On Fri, Apr 12, 2013 at 3:20 PM, Dimitri Glazkov wrote: > 2) since we do have to live with generated constructors -- at least > for a little while, we have two decoupled operations: > > a) create prototype > b) generate constructor. > Is this order required? Can we not generate the constructor, t

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-12 Thread Dimitri Glazkov
On Fri, Apr 12, 2013 at 3:56 PM, Rick Waldron wrote: > > > > On Fri, Apr 12, 2013 at 6:52 PM, Dimitri Glazkov > Can you point me to some concrete example, docs, implementation, code > (anything) that I might gain some insight into these generated constructors > you speak of? Thanks :) Spec: ht

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-12 Thread Rick Waldron
On Fri, Apr 12, 2013 at 7:14 PM, Dimitri Glazkov wrote: > On Fri, Apr 12, 2013 at 3:56 PM, Rick Waldron > wrote: > > > > > > > > On Fri, Apr 12, 2013 at 6:52 PM, Dimitri Glazkov > > > Can you point me to some concrete example, docs, implementation, code > > (anything) that I might gain some insi

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-12 Thread Daniel Buchner
@Scott - interesting, but there are valid reasons for having access to the global scope/document: - Components that benefit from top-level delegation - Components that need to analyze their destination environment before codifying their definition Know what I mean? On Fri, Apr 12, 2013

Re: MathML and "Clipboard API and events"

2013-04-12 Thread Paul Libbrecht
Hey Paul, nice to hear you raise this! I fully agree it should be possible for some JS code such as MathJax to copy MathML to clipboard. The reason it is not listed as a mandatory data type, I believe, is that I, at least, have been unable to demonstrate the zero risk of doing so. I believe I

RE: MathML and "Clipboard API and events"

2013-04-12 Thread Paul Topping
As to the lack of a MathML clipboard data type, I worry that this will make the copy ambiguous. We already see that in some desktop apps where some kind of Paste Special is needed. Speaking of Paste Special, I didn't see that mentioned. It would be really nice to be able to easily implement spe

MathML and "Clipboard API and events"

2013-04-12 Thread Paul Topping
Hi, I was just reading this document (http://www.w3.org/TR/2013/WD-clipboard-apis-20130411/). My company has been heavily involved in MathML since its creation. We are obviously interested in clipboard APIs since we want to be able to copy, cut, and paste mathematics to/from web apps. I have

Re: [dom-futures] Making ProgressFuture use real events

2013-04-12 Thread Tab Atkins Jr.
On Fri, Apr 12, 2013 at 10:02 AM, Anne van Kesteren wrote: > On Fri, Apr 12, 2013 at 11:43 AM, Elliott Sprehn wrote: >> Sure they do, they allow future extensibility. If we had used Futures for >> everything from the start the world would be quite different since we >> couldn't add any new inform

Re: [dom-futures] Making ProgressFuture use real events

2013-04-12 Thread Anne van Kesteren
On Fri, Apr 12, 2013 at 11:43 AM, Elliott Sprehn wrote: > Sure they do, they allow future extensibility. If we had used Futures for > everything from the start the world would be quite different since we > couldn't add any new information to the notifications. I can't think of many APIs we extend

RE: Screen Orientation API: Feedback

2013-04-12 Thread Bin Du
Another question about this spec. 3.3 Lock the orientation The action to lock the orientation consists of forcing the rendering of the current browsing context to be shown as if the screen was oriented in one or many of the current orientation. Says there is a window and an iframe in the window

[Bug 20045] data: URLs, HTTP, and parsing

2013-04-12 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20045 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [dom-futures] Making ProgressFuture use real events

2013-04-12 Thread Elliott Sprehn
On Wed, Apr 3, 2013 at 11:45 AM, Jonas Sicking wrote: > On Wed, Apr 3, 2013 at 10:43 AM, Tab Atkins Jr. > wrote: > > The ProgressFuture strawman at > > > > > augments a future with an analog of progress events. > > > > Wh

Re: [editing] Comments on WebKit addRange implementation

2013-04-12 Thread Elliott Sprehn
On Fri, Apr 5, 2013 at 4:48 PM, Nathan Vander Wilt wrote: > The comments on > https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#dom-selection-addrange > say > "Chrome 15 dev seems to ignore addRange() if there's already a range." > > In case it's helpful, I wanted to note that this isn't

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

2013-04-12 Thread Elliott Sprehn
I'm not sure this makes sense to use futures exclusively. As a library author you want to know when the page transitions into full screen mode even if you didn't invoke the requestFullScreen call. Futures are also not extensible. With an event we could always tack on more information in the future