Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (JZ and David Bruant)
Le 26/04/2010 11:25, Frank Migacz a écrit : What is the implication of denying dynamic changes to the HTMLCollection in a CORS environment? In some variant of Comet (or asynchronous UA polling), how can the UA implement change if it is regularly processing inside locked control blocks? I am not sure I fully understand what you are saying. I don't have the impression that in the code samples we wrote we were locked in any control block. Can you provide more details with your example ? To answer one question (which may not be yours), if a JS code is stuck in a while(1), then, events are never handled. In that situation, XMLHttpRequest events or server-sent events are particular cases of events which won't be handled as well. David
Re: [whatwg] Dealing with Stereoscopic displays
Hi again, Thanks for the replies and informed feedback. I wasn't fully aware of the significance of the replicate proposal, and I like what it potential offers for my use case, but the hardware control problem remains. Essentially the UC is this; USE CASE: A web developer wants to utilise the next generation of stereoscopic displays (for arguments sake we assume that these are going to become ubiquitous as quickly as LCD flat-screens did) for UIs which create an impression of depth (coverflows, time-machines, head-up-displays, etc.) SCENARIOS: * A user visits the National Museum site and wants to see a time-machine view of objects in the collection with a sense of 3D depth based on their age * Her PC is connected to a stereoscopic screen but the web application can't know the details of the implementation: Anaglyph glasses, polarising glasses, lenticular cover etc. * The web page has a device selector with type = stereo_display (?) which detects / gives access to the stereo functions of the display - i.e. turns on whatever feature gives stereopsis * The UA has awareness of a left and right render path for two widows / documents but knows that these are stereoscopically linked (is this sensible ?) * The web application now has two render targets * The web application now generates slightly different left eye and right eye views * The UA renders the two documents in the correct window REQUIREMENTS: * Stereo displays should be discoverable (through device ?) * Stereo displays should be controllable by the UA (again through device ?). * Scripts should have access to both render targets Any suggestions / criticisms? Regards, Eoin. On Tue, Apr 27, 2010 at 3:15 AM, ddailey ddai...@zoominternet.net wrote: No it isn't simple. Allied issues have been discussed here before. As the nature of input devices become richer (e.g. eye movement glasses that give binocular disparity data to the display device) then the nature of the convergence data that defines the scene becomes more relevant to its primary semantics. As SVG and 3D technologies begin to bridge the gap between 2 and 3D (cf. the replicate proposal [1] or [2] ) the distinction between styling and markup so tenaciously held in HTML may cease to be so clearcut. cheers David [1] http://old.nabble.com/A-proposal-for-declaritive-drawing-(%3Creplicate%3E)-to-be-added-into--SVG-td28155426.html [2] http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm - Original Message - From: David Singer sin...@apple.com To: whatwg@lists.whatwg.org Sent: Monday, April 26, 2010 8:02 PM Subject: Re: [whatwg] Dealing with Stereoscopic displays I agree that this probably means that web elements that are 'flat' would be styled by CSS with a depth. This is important if other material presented to the user really is stereo (e.g. a left/right eye coded movie). The movie will be set so that the eyes are expected to have a certain 'convergence' (i.e. they are looking slightly inward towards some point) and it's important that if material is overlaid on that. it has the same convergence. Obviously, this is unlike the real world where focus distance and convergence distance are the same (focus distance is fixed at the screen distance), but the brain can get very confused if two things that are both in focus are at difference convergence distances. This is not a simple question, as I expect you are beginning to realize. David Singer Multimedia and Software Standards, Apple Inc. -- Eoin Kilfeather Digital Media Centre Dublin Institute of Technology Aungier Street Dublin 2 m. +353 87 2235928 skype:ekilfeather
Re: [whatwg] Dealing with Stereoscopic displays
On Tue, Apr 27, 2010 at 8:38 PM, Eoin Kilfeather ekilfeat...@dmc.dit.iewrote: * A user visits the National Museum site and wants to see a time-machine view of objects in the collection with a sense of 3D depth based on their age I think this is the closest you get to an actual use-case :-). The rest is mixed up with information about possible solutions. Also, it's highly unlikely the a user will visit your site with a fully formed desire to view objects in a collection with a sense of 3D depth based on their age :-). But let's say the authors of that site want to visualize objects in the collection with different objects at different depths. It seems to me either WebGL or CSS 3D transforms --- or a mixture --- could be used for this, maybe with some extra information provided to identity the camera positions for rendering the stereo views. Actually, I probably shouldn't be involved in this discussion since I'm monocular :-). Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 26/04/10 19:50, And Clover wrote: David Flanagan wrote: Rather that trying to make DOM collections feel like arrays, how about just giving them a toArray() method? I like that, as a practical and explicit (JavaScript-specific) binding. In the longer term, what's the thinking on a more basic change: - Require specific DOM interfaces like NodeList, HTMLCollection, Element etc. to be available for prototype monkey-patching under their interface names as properties of `window`? Then we wouldn't have to worry about what Array-like methods need to be provided on HTMLCollection, because application and framework authors could choose whichever they liked to prototype in. IE8/Moz/Op/Saf/Chr already do this to a significant extent, but there's no standard that says they have to. It would allow DOM extension to be put on a much less shaky footing than the messy hack Prototype 1.x uses. Is this something that's a reasonable requirement for browsers in future? HTML5 through WebIDL and its ECMAScript binding already does require this. -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
Le 27/04/2010 03:54, Geoffrey Sneddon a écrit : On 26/04/10 19:50, And Clover wrote: David Flanagan wrote: Rather that trying to make DOM collections feel like arrays, how about just giving them a toArray() method? I like that, as a practical and explicit (JavaScript-specific) binding. In the longer term, what's the thinking on a more basic change: - Require specific DOM interfaces like NodeList, HTMLCollection, Element etc. to be available for prototype monkey-patching under their interface names as properties of `window`? Then we wouldn't have to worry about what Array-like methods need to be provided on HTMLCollection, because application and framework authors could choose whichever they liked to prototype in. IE8/Moz/Op/Saf/Chr already do this to a significant extent, but there's no standard that says they have to. It would allow DOM extension to be put on a much less shaky footing than the messy hack Prototype 1.x uses. Is this something that's a reasonable requirement for browsers in future? HTML5 through WebIDL and its ECMAScript binding already does require this. I can see where interfaces are expected to be exposed ([NamedConstructor]) in the global object, but I don't see where it is said that the prototype of the constructor must be extensible. I don't even see this in the section which is the relevent one in my opinion (Interface prototype object) I have read this version of WebIDL : http://dev.w3.org/2006/webapi/WebIDL/ David
Re: [whatwg] Ping + Ping-prefix meta element.
On 2010-04-27 00:41, Aryeh Gregor wrote: On Mon, Apr 26, 2010 at 4:17 PM, Roger Hågensenresca...@emsai.net wrote: Oh, and could someone on the HTML5 list poke some of the guys over there and see if a ping attribute for the body tag in a similar vein could be considered? This *is* the HTML5 list -- or one of them, anyway. The editor reads this list as well as public-html, and responds to all points made on this list (albeit sometimes months after the fact). Ah! That was a copy paste. (corrected a brainfart typo, aside from that it's a duplicate of the text on the bugzilla database, I just didn't strip out that part of the text). -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
