Re: [whatwg] WebWorkers vs. Threads
Shannon wrote: Jonas Sicking wrote: Shannon wrote: I've been following the WebWorkers discussion for some time trying to make sense of the problems it is trying to solve. I am starting to come to the conclusion that it provides little not already provided by: setTimeout(mainThreadFunc,1) setTimeout(workThreadFunc,2) setTimeout(workThreadFunc,2) Web workers provide two things over the above: 1. It makes it easier for the developer to implement heavy complex algorithms while not hanging the browser. 2. It allows web pages to take advantage of multicore CPUs. details: What you describe above is also known as cooperative multithreading. I.e. each thread has to manually stop itself regularly and give control to the other threads, and eventually they must do the same and give control back. However this means that you have to deep inside your threads algorithm return out to the main event loop. This can be complicated if you have a deep callstack with a lot of local variables holding a lot of state. Thus 1. Threading is easier to implement using workers since you don't have to escape back out to the main event loop. Also, web workers allow the browser to spin up real OS threads and put off the worker execution there. So if you have a multicore CPU, which is becoming very common today, the work the page is doing can take advantage of more cores, thus producing better throughput. I'm also unsure which mozilla developer has come out against the idea of web workers. I do know that we absolutely don't want the traditional threading APIs that include locks, mutexes, synchronization, shared memory etc. But that's not what the current spec has. It is a much much simpler shared nothing API which already has a basic implementation in recent nightlies. / Jonas I assumed setTimeout used real threads but I'm not advocating its use anyway. I think Lua co-routines solve every issue you raise. I hope WebWorkers will follow this model because I know from experience they are very easy to use. The basic features are: * each coroutine gets a real OS thread (if available). * coroutines can access global variables; Lua handles the locking itself. * yield and resume are available, but optional. * coroutines are garbage-collected when complete. * coroutines run a function, not a file. There is no need for a separate file download. the syntax is: function workerThreadFunction() ... do stuff ... end workerThread1 = coroutine.create( workerThreadFunction ) A Javascript implementation could also assist the programmer by automatically skipping threads that are waiting on IO or blocked waiting on user input since these actions usually represent a large faction of a web page workload. Maybe I misunderstand the concept of shared nothing but I think denying access to global objects is unwise. Maybe in a low-level language like C that's a bad thing but high-level languages can serialise simultaneous access to variables to prevent crashes and deadlocks. Performance can be improved by explicitly declaring private thread variables using var. If coroutines are adopted I hope they will be called coroutines. WebWorkers sounds silly and doesn't really assist in understanding their purpose (you have to already know what they are to understand the analogy). I think this proposal belongs in an ECMAScript discussion group but I only bring it up here due to my extreme dislike of the current WebWorkers proposal. I think the best way forward is to drop WebWorkers completely from HTML5 and let the ECMAScript group look at it for JS 2.0 or 3.0. One problem with what you're proposing is that in a browser environment the C host language and the javascript language is heavily intertwined. What do you do if a co-routine that lives in a separate thread calls into the DOM, which in most (all?) browser implementations isn't threadsafe? And what if that DOM call results in callbacks into javascript again? / Jonas
Re: [whatwg] WebWorkers vs. Threads
On Sun, Aug 10, 2008 at 5:54 PM, Shannon [EMAIL PROTECTED] wrote: * each coroutine gets a real OS thread (if available). snip Coroutines in Lua are not operating system threads or processes. Coroutines are blocks of Lua code which are created within Lua, and have their own flow of control like threads. Only one coroutine ever runs at a time, and it runs until it activates another coroutine, or yields (returns to the coroutine that invoked it). Coroutines are a way to express multiple cooperating threads of control in a convenient and natural way, but do not execute in parallel, and thus gain no performance benefit from multiple CPU's. However, since coroutines switch much faster than operating system threads and do not typically require complex and sometimes expensive locking mechanisms, using coroutines is typically faster than the equivalent program using full OS threads. /snip --http://lua-users.org/wiki/CoroutinesTutorial Is this description incorrect? It seems at odds with what you said about Lua coroutines getting an OS thread (if one is available). - a
[whatwg] web development approach
Dear web developer, I need your help! I am researching into how web developers choose a development approach. It is pure research and not a front for a commercial organisation, as such the whole survey looks very formal and it seems off putting to web developers. It is 4 screens in length and asks about your influences on choosing how to develop web systems. The survey does not require (it does ask ) for your contact details and so can be completely anonymous. I would really appreciate you taking 10 mins to complete the questionnaire located at www.websurvey.here.ws Many, many thanks Rob k Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [whatwg] HTML 5 : Misconceptions Documented
Neither the expression 'form.elements.$name' nor its expanded form 'form.elements[$name]' is supposed to be defined even if $name is an identifier of an embedded control. The correct way to address the control is 'form.elements($name)', which is a shorthand notation for 'form.elements.item($name)'. These two should not be confused. Therefore, the bug in Opera is not about shadowing the length property but about defining the corresponding property at all (in particular, 'form.elements.ell' should be null no matter what). OTOH, the expression 'form.length' is a perfect equivalent for 'form.elements(length)', provided a control with such a name is contained. Have you reported this to Opera technical support? I can see no harm in principle in assigning a value to 'form.length' because length is not an intrinsic property the form object. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Saturday, August 09, 2008 2:06 AM To: WHATWG List Cc: Maciej Stachowiak Subject: Re: [whatwg] HTML 5 : Misconceptions Documented On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote: I'd like to put this back on the list, and it doesn't contain anything personal, so I'm taking the liberty here. I'm not sure what you mean by in the binding. I meant the EcmaScript binding. Do you mean in Web IDL's definition of how to map Web IDL interfaces to the ECMAScript language, or one-off in the HTML5 spec for every interface this applies to? Narrowing the scope in the interest of not creating bugs seems like a very good idea. This could potentially be described in the EcmaScript bindings. But it would be a good idea to explore some edge cases. Particularly, if the case was the order of definition of properties: One such case would be an HTMLCollection with an element named length. In that case, the readonly length property would have to be the actual length of the collection; the value should not be replaced with an element of that name/id. forminput name=length/form document.forms[0].elements.length Opera9: [object HTMLInputElement] -- BUG FF3: 1 Saf3: 1 Another consideration would be a form element with an attribute length. That would be a problem as neither the attribute, nor the Netscape 4 DOM named items are specified as readonly. So that's one reason for not specifying the Netscape 4 DOM and for removing that example from WF 2.0 http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
Re: [whatwg] WebWorkers vs. Threads
Guarding concurrent access to global variables is not enough if those variables hold references to objects because an object can end up in a logically inconsistent state if two threads try modifying its properties concurrently. The objects would have to be lockable to avoid corrupting global state. Even if you limit yourself to scalar variables, there is nothing to prevent a script to define a compound state as a set of scalar variables, each one with its own name. While it is not a good programming practice, old code does it a lot because it is (or was) more efficient to say 'gTransCount' than 'gTrans.count'. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Monday, August 11, 2008 2:54 AM To: Jonas Sicking Cc: WHAT working group Subject: Re: [whatwg] WebWorkers vs. Threads Maybe I misunderstand the concept of shared nothing but I think denying access to global objects is unwise. Maybe in a low-level language like C that's a bad thing but high-level languages can serialise simultaneous access to variables to prevent crashes and deadlocks. Performance can be improved by explicitly declaring private thread variables using var.
Re: [whatwg] HTML 5 : Misconceptions Documented
On 8/11/08, Kristof Zelechovski [EMAIL PROTECTED] wrote: Hi Chris, Thanks for taking the time to respond to some things I was writing about. I think these are important things that deserve attention, too. If it's not too much to ask, have you considered inline style response? http://en.wikipedia.org/wiki/Posting_style#Inline_replying I tried to restore posting order, but since you are using Outlook, it was not effectively possible. Neither the expression 'form.elements.$name' nor its expanded form 'form.elements[$name]' is supposed to be defined even if $name is an identifier of an embedded control. The correct way to address the control is 'form.elements($name)', Can you cite a reference for this? AFAIK, this is an IE feature that was copied. which is a shorthand notation for 'form.elements.item($name)'. No, that is wrong. Doubly wrong, I think. The item method retrieves a node by ordinal index (based on depth-first traversal). now if you had wrote:- form.elements.namedItem($name) That would at least be partially correct. If namedItem is what you meant, then please supply a reference to back up your claim. I do not think the claim: | The correct way to address the control is 'form.elements($name)' is true and correct. I think it's an MSIE invention that other implementations copied. These two should not be confused. Therefore, the bug in Opera is not about shadowing the length property but about defining the corresponding property at all (in particular, 'form.elements.ell' should be null no matter what). Are you referring to the example I supplied? This could potentially be described in the EcmaScript bindings. But it would be a good idea to explore some edge cases. Particularly, if the case was the order of definition of properties: One such case would be an HTMLCollection with an element named length. In that case, the readonly length property would have to be the actual length of the collection; the value should not be replaced with an element of that name/id. forminput name=length/form document.forms[0].elements.length Opera9: [object HTMLInputElement] -- BUG FF3: 1 Saf3: 1 There was no element in my example with a id or name 'ell', so I would have to say that form.elements.ell would be undefined, not null. Where is this - ell - coming from? OTOH, the expression 'form.length' is a perfect equivalent for 'form.elements(length)', provided a control with such a name is contained. form.elements has a readonly property named length. That property can't be changed (legally) just because a parse event found an element named (or id'd) length. The length property of a form - form.length - refers to: Have you reported this to Opera technical support? I can see no harm in principle in assigning a value to 'form.length' because length is not an intrinsic property the form object. Chris, I have stated at least twice prior to this email that an HTMLCollection has a readonly length property. http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506 | length of type unsigned long, readonly | This attribute specifies the length or size of the list. Garrett Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Saturday, August 09, 2008 2:06 AM To: WHATWG List Cc: Maciej Stachowiak Subject: Re: [whatwg] HTML 5 : Misconceptions Documented On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote: I'd like to put this back on the list, and it doesn't contain anything personal, so I'm taking the liberty here. I'm not sure what you mean by in the binding. I meant the EcmaScript binding. Do you mean in Web IDL's definition of how to map Web IDL interfaces to the ECMAScript language, or one-off in the HTML5 spec for every interface this applies to? Narrowing the scope in the interest of not creating bugs seems like a very good idea. Another consideration would be a form element with an attribute length. That would be a problem as neither the attribute, nor the Netscape 4 DOM named items are specified as readonly. So that's one reason for not specifying the Netscape 4 DOM and for removing that example from WF 2.0 http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
Re: [whatwg] HTML 5 : Misconceptions Documented
I have considered inline response. I have two options: do it by hand (I am rather busy) and do it for every reply (which makes business people angry). I am sorry for the inconvenience it causes. The item method on a collection when the argument passed is a string that cannot be coerced to an integer is equivalent to namedItem. A form element does not have an intrinsic length property; it can be added as an embedded named control or by a script. The elements collection has the intrinsic length property and it cannot be shadowed. My source of information is MSDN, as you have correctly guessed. If you have contradictory information on legacy interfaces, please share it with us. Note that there is no way we can say it is correct or not; it is an obsolete interface after all. However, if it is consistent and all major implementations support it, there is no reason to think it is false. The name 'ell' I used is a name of an embedded control in order to make it different. I am not sure about undefined versus null; I rather use Visual Basic Scripting Edition and I get Nothing (not Empty) for a property an object does not have. It may as well be undefined under JavaScript. Chris See also http://msdn.microsoft.com/en-us/library/ms536460(VS.85).aspx. -Original Message- From: Garrett Smith [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2008 10:37 PM To: Kristof Zelechovski Cc: WHATWG List; Maciej Stachowiak Subject: Re: [whatwg] HTML 5 : Misconceptions Documented On 8/11/08, Kristof Zelechovski [EMAIL PROTECTED] wrote: Hi Chris, Thanks for taking the time to respond to some things I was writing about. I think these are important things that deserve attention, too. If it's not too much to ask, have you considered inline style response? http://en.wikipedia.org/wiki/Posting_style#Inline_replying I tried to restore posting order, but since you are using Outlook, it was not effectively possible. Neither the expression 'form.elements.$name' nor its expanded form 'form.elements[$name]' is supposed to be defined even if $name is an identifier of an embedded control. The correct way to address the control is 'form.elements($name)', Can you cite a reference for this? AFAIK, this is an IE feature that was copied. which is a shorthand notation for 'form.elements.item($name)'. No, that is wrong. Doubly wrong, I think. The item method retrieves a node by ordinal index (based on depth-first traversal). now if you had wrote:- form.elements.namedItem($name) That would at least be partially correct. If namedItem is what you meant, then please supply a reference to back up your claim. I do not think the claim: | The correct way to address the control is 'form.elements($name)' is true and correct. I think it's an MSIE invention that other implementations copied. These two should not be confused. Therefore, the bug in Opera is not about shadowing the length property but about defining the corresponding property at all (in particular, 'form.elements.ell' should be null no matter what). Are you referring to the example I supplied? This could potentially be described in the EcmaScript bindings. But it would be a good idea to explore some edge cases. Particularly, if the case was the order of definition of properties: One such case would be an HTMLCollection with an element named length. In that case, the readonly length property would have to be the actual length of the collection; the value should not be replaced with an element of that name/id. forminput name=length/form document.forms[0].elements.length Opera9: [object HTMLInputElement] -- BUG FF3: 1 Saf3: 1 There was no element in my example with a id or name 'ell', so I would have to say that form.elements.ell would be undefined, not null. Where is this - ell - coming from? OTOH, the expression 'form.length' is a perfect equivalent for 'form.elements(length)', provided a control with such a name is contained. form.elements has a readonly property named length. That property can't be changed (legally) just because a parse event found an element named (or id'd) length. The length property of a form - form.length - refers to: Have you reported this to Opera technical support? I can see no harm in principle in assigning a value to 'form.length' because length is not an intrinsic property the form object. Chris, I have stated at least twice prior to this email that an HTMLCollection has a readonly length property. http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506 | length of type unsigned long, readonly | This attribute specifies the length or size of the list. Garrett Chris
Re: [whatwg] VIDEO tag height/width best fit
Hi ! In this regard, video should be handled like img. While handling an image, if you specify a width and leave height as auto, the UA will resize the height to keep the aspect ratio, because the UA known the images intrinsic dimensions. The same behavior happens if you specific height and leave width as auto. IF you specifi non, intrinsic dimensions will be used. So, for video, the behavior should be the same. The UA knowns the video file intrisinc dimensions, so the samebehavior can be applied too. This way we would not overspecify new behavior, which is good, and IMO enough, therefore simplifying the work of the web authors by reusing the old algorithm used for images. Bye. On , Biju [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I apologize if I did not understood http://www.whatwg.org/specs/web-apps/current-work/#video I see a situation where we want to specify the height and width of the BOX in which a video need to be displayed. And while writing HTML code we dont know the height/width of the video. But when playing we want the video to be displayed with maximum size which can fit in the BOX without loosing the aspect ratio. After reading the video tag specification I dont see a way to achieve this with out javascript code. We should have one more attribute to tell how to fit the image/video == fit attribute values === * center - if it is small keep at center * stretch - stretch/skew height and width to fit * stretch-height - stretch/skew height only to fit, adjust width to maintain aspect ratio. * stretch-width - stretch/skew width only to fit, adjust height to maintain aspect ratio. * stretch-best- stretch/skew height or width to maximum so that other will fit in and maintain aspect ratio. May be we can also have a tile option This problem also exist for img tag.
Re: [whatwg] Find a number with . as the input
On Sat, 18 Nov 2006, Henri Sivonen wrote: The definition of find a number ( http://whatwg.org/specs/web-apps/ current-work/#find-a ) may cause a string containing a single U+002E FULL STOP to be fed to the algorithm entitled rules for parsing floating point number values ( http://whatwg.org/specs/web-apps/current-work/#rules1 ). The definition for find a number claims that this step can never fail, but step 9 in rules for parsing floating point number values returns an error in this case. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] meter and document conformance
On Sat, 18 Nov 2006, Henri Sivonen wrote: Is a document non-conforming if it contains a meter element that does not have a value attribute and the algorithm http://whatwg.org/specs/ web-apps/current-work/#steps fails to return either number1 and denominator or number1 and number2? I think such documents should be non-conforming. Done -- a value is required. Max isn't. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] meter and document conformance
On Sat, 18 Nov 2006, Henri Sivonen wrote: On Nov 18, 2006, at 14:32, Henri Sivonen wrote: Is a document non-conforming if it contains a meter element that does not have a value attribute and the algorithm http://whatwg.org/ specs/web-apps/current-work/#steps fails to return either number1 and denominator or number1 and number2? I think such documents should be non-conforming. The same question and opinion apply to progress as well. No, a progress element with no max and value is just an indeterminate progress bar. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Treat video like an image
I'm thinking that you're thinking like an author. I like it! Lots of fun and you're right to point out the possibility for problems. Allowing video to be turned off (just like browsers used to -- and probably still do -- allow for images to be turned off, when the hardware or user isn't up for it) would probably be required until about 2024 when the browser will be able to handle 4000 concurrent 6-channel 3-D video feeds, each diff-ed against all other pairs, in an omni-time-space analytic manifold of some sort that is tweaked by a hyperdimensional differential brainwave mouse . The Opera build with real-time SVG filters applied to video, made me think that HTML and SVG ought to be sharing the filter business rather than being mired down with the troglodytic canvas re-invention of wheel business, but then who's to say that wheels need to be round anyhow? cheers David Dailey - Original Message - From: João Eiras [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 11, 2008 9:28 PM Subject: [whatwg] Treat video like an image Hi ! Not a long time ago, we saw an Opera build which had video support. What was really really cool about it was that video was pretty much supported like any other image format so we could apply filtering and other complex stuff from svg like in this example. http://people.opera.com/howcome/2007/video/svg/video-filter.svg This gives us an entire range of possibilities with video, just like with svg, or img I think that video should be supported like any other image: - supporting transparencies (if the video codec allows) - embedding video files with video or object element - embedding video files with url() in css where images can be used, like background-image - embedding video files with url() in css content rules If course, this could raise some issues like: - performance - the UA should provide a way for the use to toggle video on and off, or could make decisions based on the platform's overall performance. Also, with rendering engines progressively migrating to architectures that support hardware acceleration, blending a background video with foreground content could be a trivial lightweight operation, although the same cannot be said for software renderers. - fallback in css not possible - if a UA does not support video, then it would ignore the content embedded in the stylesheet. Such behavior is also fully supported for other content types, like unrecognized image formats and the likes. However, the problem of adding fallback content with CSS not being trivial, is a problem with css itself, and out of scope of the video specification - accessibility, usability - by providing new means for authors to add more video and possibly other annoying animations in webpages, users could easily be annoyed with excess of animated content. This is more or less the same problem of performance, so the UA should give the user the option to disable video, preferably in site specific preferences, if supported. So, what do you think ? Bye.
Re: [whatwg] Treat video like an image
João Eiras wrote: Hi ! Not a long time ago, we saw an Opera build which had video support. What was really really cool about it was that video was pretty much supported like any other image format so we could apply filtering and other complex stuff from svg like in this example. http://people.opera.com/howcome/2007/video/svg/video-filter.svg This gives us an entire range of possibilities with video, just like with svg, or img I think that video should be supported like any other image: - supporting transparencies (if the video codec allows) - embedding video files with video or object element - embedding video files with url() in css where images can be used, like background-image - embedding video files with url() in css content rules If course, this could raise some issues like: - performance - the UA should provide a way for the use to toggle video on and off, or could make decisions based on the platform's overall performance. Also, with rendering engines progressively migrating to architectures that support hardware acceleration, blending a background video with foreground content could be a trivial lightweight operation, although the same cannot be said for software renderers. - fallback in css not possible - if a UA does not support video, then it would ignore the content embedded in the stylesheet. Such behavior is also fully supported for other content types, like unrecognized image formats and the likes. However, the problem of adding fallback content with CSS not being trivial, is a problem with css itself, and out of scope of the video specification - accessibility, usability - by providing new means for authors to add more video and possibly other annoying animations in webpages, users could easily be annoyed with excess of animated content. This is more or less the same problem of performance, so the UA should give the user the option to disable video, preferably in site specific preferences, if supported. I think I agree. But I don't see anything in any current specs that contradicts what you are saying. In other words, are you requesting any changes to any specific specs, or are you just asking UA developers to implement the feature set to full extent that specs allow? Note that the CSS spec says nothing about what format a url() can point to, thus there is no spec-wise reason pointing to a video file wouldn't work. And there is no documented limitation on which elements css transparency applies, thus applying it to a video element should work just fine, and already does in the implementation in recent firefox nightlies. / Jonas
Re: [whatwg] Treat video like an image
ddailey wrote: The Opera build with real-time SVG filters applied to video, made me think that HTML and SVG ought to be sharing the filter business rather than being mired down with the troglodytic canvas re-invention of wheel business, but then who's to say that wheels need to be round anyhow? You mean like this: http://www.bluishcoder.co.nz/2008/07/video-bling.html / Jonas
