[whatwg] Canvas implementors
Hello Whatwg, I am about to submit a request for funding to U.S. to implement a web integrity service to bring a digital spectrometer to the browser market in order to help cohere and decohere device-independent online data assets oft shared among public and private sectors. Such should be simple enough for everyday users to glean helpful info and awareness while providing researchers across disciplines a more robust tool for their efforts. It seems that the canvas element could really help make this a reality. The Editor's Draft I reviewed on the w3c site this week seems to suggest that text and glyphs generated with accessibility-scale functions would not be able to be easily edited (text) nor cut-and-pasted. Am I understanding this correctly? If so, that's a plus for me as the data which would be utilized to populate the digital spectrometer on the front end would be pulled from other sources where editing functionality is authorized. If you are interested in helping me with this, please reply and I will be happy to provide more details. Thank you, M.A. Norton Sent by the hope boat.
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, Oct 8, 2013 at 4:26 PM, Erik Dahlstrom e...@opera.com wrote: On Tue, 08 Oct 2013 15:49:48 +0200, Philip Jägenstedt phil...@opera.com wrote: 1. Do what Gecko does, even though there's no SVG spec requiring it yet. 2. Just say Element implements GlobalEventHandlers. I would prefer option 2, since we already have a unified Document implements GlobalEventHandlers. Either option is probably fine from a web compat standpoint, but I'd prefer option 2 too. Have we had success yet making id= and class= super-global? Not sure we should extend the experiment prematurely. -- http://annevankesteren.nl/
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On 10/8/13 11:26 AM, Anne van Kesteren wrote: Have we had success yet making id= and class= super-global? Not sure we should extend the experiment prematurely. In terms of DOM behavior, in Gecko we have been shipping an id attribute on Element.prototype for a good long while now. We haven't moved className to Element.prototype yet. In terms of the behavior of the content attribute, I don't think we've made id= on random nodes do anything interesting. -Boris
Re: [whatwg] Canvas implementors
On Tue, Oct 8, 2013 at 5:53 AM, Michael Norton no...@me.com wrote: It seems that the canvas element could really help make this a reality. The Editor's Draft I reviewed on the w3c site this week seems to suggest that text and glyphs generated with accessibility-scale functions would not be able to be easily edited (text) nor cut-and-pasted. Am I understanding this correctly? If so, that's a plus for me as the data which would be utilized to populate the digital spectrometer on the front end would be pulled from other sources where editing functionality is authorized. The last sentence seems unrelated to the rest of the paragraph. Editing a data source is a very different thing from editing a local copy of text on a webpage. There is no reason to worry about the latter when it's the former that needs authorization. Using canvas just to make less-accessible text is inappropriate. Similarly, lack of copy/paste functionality is disconnected from anything you might need authorization for at the data source level. If you can copy/paste, you can just type it out yourself, so you aren't preventing anything. Efforts to restrict or disallow copy/paste on websites in the past (stretching back to the early days of JavaScript) have always been that terrible combination of utterly worthless and completely user-hostile. Using canvas to try and restrict copy/paste is a fool's errand, and inappropriate as well. That said, using canvas to easily create cross-platform visualizations of data is a very worthwhile and appropriate thing to do. ~TJ
Re: [whatwg] Canvas implementors
Thank you TJ, i think your last statement is more to the point: That said, using canvas to easily create cross-platform visualizations of data is a very worthwhile and appropriate thing to do. My mention of text's glyphiness within canvass is a mere bonus IMO as the more valuable characteristic is this element's apparent ability to scale and repeat visual effects while incorporating text from data sources, and grow and collapse upon targeted cursor events for accessibility sake without any mess upon related texts. Cheers to canvass creators! I really haven't been this excited about HTML since the a element but it's fair to say that canvass at least in the 2d context is a cohesion of several processing languages, scripts, and protocols. Anyone in the New England area up for a meetup to mesh canvass with a digital spectrometer browser extension? Sent by the hope boat. On Oct 8, 2013, at 12:24 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 8, 2013 at 5:53 AM, Michael Norton no...@me.com wrote: It seems that the canvas element could really help make this a reality. The Editor's Draft I reviewed on the w3c site this week seems to suggest that text and glyphs generated with accessibility-scale functions would not be able to be easily edited (text) nor cut-and-pasted. Am I understanding this correctly? If so, that's a plus for me as the data which would be utilized to populate the digital spectrometer on the front end would be pulled from other sources where editing functionality is authorized. The last sentence seems unrelated to the rest of the paragraph. Editing a data source is a very different thing from editing a local copy of text on a webpage. There is no reason to worry about the latter when it's the former that needs authorization. Using canvas just to make less-accessible text is inappropriate. Similarly, lack of copy/paste functionality is disconnected from anything you might need authorization for at the data source level. If you can copy/paste, you can just type it out yourself, so you aren't preventing anything. Efforts to restrict or disallow copy/paste on websites in the past (stretching back to the early days of JavaScript) have always been that terrible combination of utterly worthless and completely user-hostile. Using canvas to try and restrict copy/paste is a fool's errand, and inappropriate as well. That said, using canvas to easily create cross-platform visualizations of data is a very worthwhile and appropriate thing to do. ~TJ
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On 10/8/13 9:49 AM, Philip Jägenstedt wrote: Gecko has HTMLElement implements GlobalEventHandlers in its IDL,[1] but somewhat surprisingly also SVGElement implements GlobalEventHandlers.[2] Note that in Gecko SVG elements also have event handler content attributes and whatnot. What's your proposed handling of event handler content attributes? And note that the handling of these is not quite identical for HTML and SVG last I checked. :( -Boris
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, Oct 8, 2013 at 5:26 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 8, 2013 at 4:26 PM, Erik Dahlstrom e...@opera.com wrote: On Tue, 08 Oct 2013 15:49:48 +0200, Philip Jägenstedt phil...@opera.com wrote: 1. Do what Gecko does, even though there's no SVG spec requiring it yet. 2. Just say Element implements GlobalEventHandlers. I would prefer option 2, since we already have a unified Document implements GlobalEventHandlers. Either option is probably fine from a web compat standpoint, but I'd prefer option 2 too. Have we had success yet making id= and class= super-global? Not sure we should extend the experiment prematurely. I don't know anything about the move of those attributes, has it been attempted in spec and implementation and run into trouble? Philip
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, Oct 8, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/8/13 9:49 AM, Philip Jägenstedt wrote: Gecko has HTMLElement implements GlobalEventHandlers in its IDL,[1] but somewhat surprisingly also SVGElement implements GlobalEventHandlers.[2] Note that in Gecko SVG elements also have event handler content attributes and whatnot. What's your proposed handling of event handler content attributes? And note that the handling of these is not quite identical for HTML and SVG last I checked. :( Is there a spec for how the event handler content attributes (with reflection) work in SVG? In any event I haven't intended any changes here, whatever is already implemented sounds good. If implementations disagree, then getting agreement and a spec for it seems orthogonal to which interface the IDL attributes sit on. Philip
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, Oct 8, 2013 at 8:35 PM, Philip Jägenstedt phil...@opera.com wrote: I don't know anything about the move of those attributes, has it been attempted in spec and implementation and run into trouble? http://dom.spec.whatwg.org/ is the specification, but I don't think it's been implemented yet. Moving more attributes to be superglobal probably makes sense, but I feel somewhat hesitant since we haven't discussed this in detail and thought through the implications. Given that almost everyone ends up with HTMLElement and to a lesser extent SVGElement the implications are probably marginal to begin with... -- http://annevankesteren.nl/
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, 08 Oct 2013 20:38:48 +0200, Philip Jägenstedt phil...@opera.com wrote: On Tue, Oct 8, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/8/13 9:49 AM, Philip Jägenstedt wrote: Gecko has HTMLElement implements GlobalEventHandlers in its IDL,[1] but somewhat surprisingly also SVGElement implements GlobalEventHandlers.[2] Note that in Gecko SVG elements also have event handler content attributes and whatnot. What's your proposed handling of event handler content attributes? And note that the handling of these is not quite identical for HTML and SVG last I checked. :( Is there a spec for how the event handler content attributes (with reflection) work in SVG? http://www.w3.org/TR/SVG/script.html#EventAttributes http://www.w3.org/TR/SVG2/script.html#EventAttributes I don't see any IDL for event handlers in the SVG spec, so per spec there should only be content attributes... And only those that are specified for some elements, unlike HTML where most event handlers are available everywhere. In any event I haven't intended any changes here, whatever is already implemented sounds good. I'm not sure what should be done with SVG. Clearly the SVG spec doesn't reflect the we should do whatever HTML does idea. If implementations disagree, then getting agreement and a spec for it seems orthogonal to which interface the IDL attributes sit on. I think it would be bad to have an IDL attribute without a working content attribute for a given element. That's just confusing. -- Simon Pieters Opera Software
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, 8 Oct 2013, Simon Pieters wrote: I think it would be bad to have an IDL attribute without a working content attribute for a given element. That's just confusing. Yeah, that's the main reason I wouldn't put this on Element if it was up to me. It seems weird to say to everyone around the world that we're basically stomping on any content attribute starting with on. It's one thing to take id, and even maybe ok to take class (though that starts getting a bit iffy, it's easy to come up with examples where the attribute class means something different than we do in HTML), but I'm sure there's all kinds of vocabularies that have an onclick attribute with _very_ different semantics than ours. For example, I'm sure there's many XML-based UI languages that have onclick= handlers but I doubt that they all use JavaScript and I really doubt that they all have the crazy semantics that HTML has: http://whatwg.org/html/#event-handler-content-attributes -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] onclose events for MessagePort
On Tue, Oct 1, 2013 at 11:13 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/1/13 2:11 PM, Ian Hickson wrote: How often do we expect two tabs to be talking to each other though? Or a page to an out-of-process subframe? How often do we expect MessageChannel to be used at all? Speaking as an web developer, I've found MessageChannel to be pretty useful when writing a complex web application because it allows you to isolate different communication pathways and hop across multiple iframes in a single bound (while only knowing about the next step at any one layer... it is hard to explain why this is useful without having to dive into the app). You can do this all on top of window.postMessage but it is more complicated and fragile. (Due to this, I've had to write a a layer above these that allows me to use either so that my code can work on browsers that don't support MessageChannel but it will be easier to debug on those that do.) dave Is that even possible on phone browsers? Sure is in Firefox and FirefoxOS. Anyway, I'm happy to support this in principle. OK, good. ;) -Boris
