Re: [whatwg] Workers feedback
Nov 14, 2008, в 2:30 AM, Ian Hickson написал(а): I believe that the idea that the API for shared and dedicated workers should be the same is misguided. The spec used to make the two cases identical. The result was confusion, and the dedicated case was much more complex than necessary. This is the strongest argument for having separate interfaces of all presented, but in my opinion, it misses some important data points: - Was introducing a new interface the only way to resolve the confusion? Maybe renaming a method or two would have had a positive effect? - Did it help resolve the confusion? - What kind of danger the confusion was? Would authors write under- performing and unreliable code, or refuse to use such a cumbersome API at all? Or was is just a momentary delay for some, resolved quickly and harmlessly? I don't remember any of these discussed here. Shared workers and dedicated workers are fundamentally different and have different needs, and we should expose these needs in ways optimised for the two cases. The basic need is that dedicated workers be able to have a two-way communication channel with their creators, and shared workers be able to have a two-way communication with each user of the worker. I think that this argument is false. It is normal for a single API to support multiple use cases. Replace Worker with XMLHttpRequest, and we end up with separate interfaces for GET and POST. skipped code samples For dedicated workers though that's way more complexity than we want to require of authors -- why do they have to listen for a port when there will always be exactly one? So it makes sense to use It is not true that there will always be one - additional ports can be passed in via postMessage(). Now, we've at this point made the two different already, so as to simplify the dedicated worker, so we could (and the spec does) make the dedicated worker even simpler while we're at it. Returning to the XMLHttpRequest example, we really can combine open() and send() for XMLHttpRequestGET, but not for XMLHttpRequestPOST. Generally, the interfaces can be very different if we try to. One way to do that is to bury the ports into the Worker and global scope objects. If we do one side, though, we have to do the other, because it would be really weird to have a message channel that half-acts like a two-port channel and half doesn't. I agree. For example, if we bury it, we shouldn't expose .close(), since it's better for the worker to be closed using the actual .close() or .terminate() API, but if we only bury one side, then one end could close the pipe and not the other, and we'd have to make sure we expose .onclose on the buried end, and so forth. I agree that if we have a direct interface for messaging on one side, we should have it on both sides. So, we end up with what the spec has now. I think what we have now is better than making dedicated and shared workers superficially the same (as the spec used to be, and as the people involved in this thread argued was bad) is more confusing for authors. I'd be more that happy with a separate interface if the objects actually behaved differently. One example of a good reason to have separate interfaces was recently proposed here: shared workers should outlive their creators. This is the sort of difference that would make having a separate API reasonable, in my opinion. At this point, if the only arguments for changing the API are it's confusing for authors, then I'd rather not change the API. We got to where we are today by carefully considering what would be better for authors. We could continue going back-and-forth and reverting earlier decisions until the cows come home, but I see no benefit to doing so. I don't think it's inappropriate to continue back-and-forth until there is at least one reasonably complete implementation validating the spec. Currently, the Mozilla implementation is very different in spirit, not supporting MessagePorts at all. * I still don't buy the utility of passing around MessagePorts, so I suggest we table that for v2. It can always be added back later. Since they so drastically affect the API design, I think putting them off is a mistake. We might end up constraining ourselves in unobvious ways. I agree. - WBR, Alexey Proskuryakov
[whatwg] attribute media on script element
Hi, I don't know if the question has already been posted... Would it be possible to have media attribute in the SCRIPT element? Addmitted vaues would be the same of STYLE element (all, screen, print, handheld ...) Personally, I'd really love this feature. Thank you Kind regards Filippo -- Filippo Levizzani filippo (dot) levizzani (at) gmail (dot) com
Re: [whatwg] Deprecating small, b ?
On Fri, Nov 14, 2008 at 06:09, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: The small element represents small print [...] The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance [...] Both definitions seems rather presentational (contrasting, for example, the new semantic definition for the i element) and could also be realized by use of span elements. Why use span class=smallprintCopyright (c) 2008 …/span instead of just smallCopyright (c) 2008 …/small? The latter possibility is way more semantic. And why use span class=brandSiemens/span instead of just bSiemens/b? To me, the small and b elements – especially the former – make perfect sense. -david
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Nov 14, 2008, в 3:59 AM, Ian Hickson написал(а): For the sake of completeness, a connect/startConversation method on a worker really should automatically open the receiving port - this is what examples posted so far implied, and it would cause a lot of aggravation if it didn't. I know I'm often forgetting to open the port when writing my tests, and it's not a very easy mistake to spot. What do you mean by open the port? Do you mean calling start()? If so, that should happen automatically when you set onmessage the first time, per spec. Oh, that's my mistake - I totally didn't expect that it could have such side effect. It seems weird that addEventListener(message, ...) does not have such effect, does it? In an async processing model, there is simply no way for the receiver to have a list of all objects that were posted to it - it's exactly the reason for the existence of the queue that events are delivered asynchronously and cannot be peeked before being delivered. For example, in a multi-process implementation, these events may still be across process boundary. It actually doesn't really matter if there is something that has been posted but not yet received, because that is indistinguishable (as far as I can tell) from the case of the worker having shut down a split second before that object was posted. I'm not sure what state you mean by shut down here - the spec does not define this, and shutting down a side of an async communication channel is complicated (see e.g. a TCP/IP state diagram). Anyway, the contents of the worker's ports is used for defining active needed worker and suspendable worker further on, which are concepts that are very important for worker lifetime definition. If the ports in event queue are not important, then the spec should not say that they are included in the worker's ports. This would resolve the concurrency problem, but I don't think that the resulting behavior would be desirable. It is not possible to have a symmetric relationship in an asynchronous messaging model - we need a multi-step entagling/unentangling protocol, so the relationship is necessarily asymmetric. One can't freeze another process (or really, even another thread) to change something in it synchronously. The above is not a requirement, it's just a description of the concept. I don't think anything actually depends on it being symmetric; all the parts that actually entangle ports have (or, are intended to have, maybe I missed some) pretty well-defined synchronisation points. OK, say there is a pair of entangled ports in different threads/ processes, portA and portB. We concurrently post both with postMessage, which causes the ports to be cloned. From the point of view of first thread, PortA is now unentangled, and portA' is entangled with portB. From the point of view of second thread, PortB is unentangled, and portB' is entangled with portA. Next, threads send asynchronous notifications to each other, asking to update entangling information. First thread's notification asks portB to become entangled with portA'. So, portB will need to forward this notification to portB' (and possibly further, because portB' may have been posted and cloned again). This already is unduly complicated. Now consider that all these ports need to have destroyed sooner or later, but not too soon. This basically means that we now have a many- to-many distributed GC system. It was bad enough when we had to garbage protect ports between threads, because this required modification of the JavaScript interpreter to support a certain case of distributed GC. But this example basically shows that we need a full-blown distributed GC system in order to implement port cloning. For example, any method that entangles two ports blocks until both threads are synchronised and entangled. This will cause deadlocks - if portB' is sent to the first thread as portB'' in the above scheme, the lock will not let synchronization ever finish. (The spec is somewhat implicit about this, but the intent is that workers really be implemented either as two system threads, one doing communication and one running the JS, or by one system thread that runs the JS in an interruptible fashion. In particular, doing something that synchronises with a worker isn't expected to have to wait for that worker to finish running its current JS.) The JS thread will need to be interrupted in any case - we certainly don't want it to read a half-written pointer from memory or something. Adding memory barriers around access to data that can be modified externally is not sufficient, because MessagePort algorithms are not designed in a lock-free fashion (lock-free algorithms that only rely on read/write atomicity do exist, but these aren't such). Locking around all MessagePort functions will cause deadlocks, as demonstrated above, and is
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Nov 14, 2008, в 7:37 AM, Jonas Sicking написал(а): Feel free to try our implementation of a subset of the spec ;) I did not say that there was anything wrong with Mozilla's implementation! What I said was that it was very different from the current spec, at least in spirit. In fact, I'm strongly considering dropping MessagePort from WebKit (at least for now), and going with Mozilla worker API. - WBR, Alexey Proskuryakov
[whatwg] attribute media on script element
Hi, Would it be possible to have media attribute in the SCRIPT element? Addmitted vaues would be the same of STYLE element (all, screen, print, handheld ...) Thank you Kind regards Filippo
Re: [whatwg] Workers feedback
On Fri, Nov 14, 2008 at 9:00 AM, Jonas Sicking [EMAIL PROTECTED] wrote:
Oh?! Then I understand even less what the use case is. This is something
that doesn't exist for script and i've never heard anyone ask for it
(granted, that is not proof that no one wants it).
a script can figure out where it is by using try { null.null } catch
(e) { location=e.fileName }
and i do have scripts which do stuff like that.
that said i don't see a reason to add such a feature, just let people
pass it if they need to.
Re: [whatwg] About input type=hidden
Ian Hickson wrote: On Fri, 17 Oct 2008, Mike Wilson wrote: but for more decoupled systems you may want to specify a HTML snippet per object type or similar - and then apply recursive view rendering on an object graph. I agree, but it seems that having the hidden inputs be inside the next li of a list, or the next td, or whatever is appropriate, isn't much to ask for. It's good that you see what problems I am describing. There are two problems here, and I think you are mainly referring to the one which is about the templating system having to parse the HTML it is producing to find the next insertion spot. This is solvable but would be nice to not having to do. The other problem is that you sometimes would have to produce new markup, and probably hide it, in case there is no next li or tr f ex. (I notice that the requirement for at least one td has not been loosened up as it has been for tr.) Anyway, I understand that you do not see a good way of letting postable state become position independent, so we can close this discussion. Best regards Mike Wilson
Re: [whatwg] Workers feedback
Nov 14, 2008, в 10:00 AM, Jonas Sicking написал(а): What are the use cases? Also note that we can't use it with shared workers since they can be connected to several pages from different uris. It returns the script's URL, not the page's. Oh?! Then I understand even less what the use case is. This is something that doesn't exist for script and i've never heard anyone ask for it (granted, that is not proof that no one wants it). Actually, this exists for script is you say that it returns the URL that the script execution context uses for resolving relative URLs. It just so happens that for script, it's document URL, and for workers, it's script URL. - WBR, Alexey Proskuryakov
Re: [whatwg] Deprecating small, b ?
The small element represents small print [...] The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance [...] Both definitions seems rather presentational (contrasting, for example, the new semantic definition for the i element) and could also be realized by use of span elements. Why use span class=smallprintCopyright (c) 2008 ?/span instead of just smallCopyright (c) 2008 ?/small? The latter possibility is way more semantic. And why use span class=brandSiemens/span instead of just bSiemens/b? To me, the small and b elements ? especially the former ? make perfect sense. -david I agree with the original poster on this. 1) Just because it makes sense to a human (it doesn't to me), does not mean it makes sense to a machine. 2) When using small on different text-nodes throughout the document, one would expect all these text-nodes to be semantically the same. But they are not (unless all of them are copyright notices). 3) small is a styling element, it has zero semantic meaning, so it does not belong inside HTML. 4) bSiemens/b also does not tell me anything about the semantics. Is it used as a name, a brand a foreign word ? etc. I cannot get that information from looking at the b element. Bert
Re: [whatwg] Deprecating small, b ?
Dne Fri, 14 Nov 2008 14:40:20 +0100 Pentasis [EMAIL PROTECTED] napsal/-a: I agree with the original poster on this. 1) Just because it makes sense to a human (it doesn't to me), does not mean it makes sense to a machine. 2) When using small on different text-nodes throughout the document, one would expect all these text-nodes to be semantically the same. But they are not (unless all of them are copyright notices). 3) small is a styling element, it has zero semantic meaning, so it does not belong inside HTML. 4) bSiemens/b also does not tell me anything about the semantics. Is it used as a name, a brand a foreign word ? etc. I cannot get that information from looking at the b element. Bert I second that, even though it might have a zero value. Ollie
Re: [whatwg] Deprecating small, b ?
On Fri, Nov 14, 2008 at 7:40 AM, Pentasis [EMAIL PROTECTED] wrote: The small element represents small print [...] The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance [...] Both definitions seems rather presentational (contrasting, for example, the new semantic definition for the i element) and could also be realized by use of span elements. Why use span class=smallprintCopyright (c) 2008 ?/span instead of just smallCopyright (c) 2008 ?/small? The latter possibility is way more semantic. And why use span class=brandSiemens/span instead of just bSiemens/b? To me, the small and b elements ? especially the former ? make perfect sense. -david I agree with the original poster on this. 1) Just because it makes sense to a human (it doesn't to me), does not mean it makes sense to a machine. 2) When using small on different text-nodes throughout the document, one would expect all these text-nodes to be semantically the same. But they are not (unless all of them are copyright notices). Why would you expect this? Or rather, why would you expect this level of semantic specificity? small means something fairly broad that multiple types of specific semantics can fall under. 3) small is a styling element, it has zero semantic meaning, so it does not belong inside HTML. It *had* zero semantic meaning. Actually, though, this wasn't quite true. The semantics that have been attached to small (and i, and b) are an approximation of the common semantics that users of the elements conferred on the contents. Text within small was, quite often, used for small print. Matching up theory with practice is a good thing here. i and b, once you subtract the semantics stolen by em and strong, are used pretty much specifically as the spec states. 4) bSiemens/b also does not tell me anything about the semantics. Is it used as a name, a brand a foreign word ? etc. I cannot get that information from looking at the b element. Of course not. You're not intended to. What you *do* get, though, is that this is a word which is *intentionally* stylistically offset from the rest of the text. This conveys semantic meaning to a human - it means that the word is special or being used in a particular context. b and i don't communicate *much*, but they communicate *something*. One could, of course, also use a span to mark up and style the text, thus communicating the same intent to a person reading the styled text, but to a machine the span means literally nothing, while b and i have the possibility to communicate *something*. In addition, the fact that these elements traditionally have a particular preferred rendering means something. A dumb terminal which doesn't understand CSS won't give any indication to the user that a span exists at all, while b and i have a chance of providing fallback rendering that still accomplishes what they were designed to do. A decent chunk of html5 concerns itself with providing fallbacks and graceful degradation (or progressive enhancement, whichever way you want to look at it). Having some *nearly* semantic-free elements which have a meaningful fallback can be useful. Of course, it may certainly be more useful to you if you provide a class on the i as well. ~TJ
Re: [whatwg] Deprecating small, b ?
Of course not. You're not intended to. What you *do* get, though, is that this is a word which is *intentionally* stylistically offset from the rest of the text. This conveys semantic meaning to a human - it means that the word is special or being used in a particular context. b and i don't communicate *much*, but they communicate *something*. One could, of course, also use a span to mark up and style the text, thus communicating the same intent to a person reading the styled text, but to a machine the span means literally nothing, while b and i have the possibility to communicate *something*. In addition, the fact that these elements traditionally have a particular preferred rendering means something. A dumb terminal which doesn't understand CSS won't give any indication to the user that a span exists at all, while b and i have a chance of providing fallback rendering that still accomplishes what they were designed to do. A decent chunk of html5 concerns itself with providing fallbacks and graceful degradation (or progressive enhancement, whichever way you want to look at it). Having some *nearly* semantic-free elements which have a meaningful fallback can be useful. Of course, it may certainly be more useful to you if you provide a class on the i as well. ~TJ First: Computers are binary instruments. conveying *something* is not very logical seen from a computers point of view. It is not usefull to *me* to provide a class to the i or any other element, it is usefull to the computer, as humans may indeed come to some sort of conclusion based on style or strangely used semantics, computers cannot, they (still) need a more literal means of semantics. Second: Suppose I want to collect all copyright notices from 1000 websites (don't ask me why, I just want to), how am I to do this when they are marked up in smalls? I will definatly end up with a lot of text that has nothing to do with copyrights (and probably miss a lot of copyright notices as they are marked up differently) Whereas If they were maked up in (for example) span class=copyright I could retrieve it all based on the class-name. Bert
Re: [whatwg] Deprecating small, b ?
On Fri, Nov 14, 2008 at 9:38 AM, Pentasis [EMAIL PROTECTED] wrote: Of course not. You're not intended to. What you *do* get, though, is that this is a word which is *intentionally* stylistically offset from the rest of the text. This conveys semantic meaning to a human - it means that the word is special or being used in a particular context. b and i don't communicate *much*, but they communicate *something*. One could, of course, also use a span to mark up and style the text, thus communicating the same intent to a person reading the styled text, but to a machine the span means literally nothing, while b and i have the possibility to communicate *something*. In addition, the fact that these elements traditionally have a particular preferred rendering means something. A dumb terminal which doesn't understand CSS won't give any indication to the user that a span exists at all, while b and i have a chance of providing fallback rendering that still accomplishes what they were designed to do. A decent chunk of html5 concerns itself with providing fallbacks and graceful degradation (or progressive enhancement, whichever way you want to look at it). Having some *nearly* semantic-free elements which have a meaningful fallback can be useful. Of course, it may certainly be more useful to you if you provide a class on the i as well. ~TJ First: Computers are binary instruments. conveying *something* is not very logical seen from a computers point of view. It is not usefull to *me* to provide a class to the i or any other element, it is usefull to the computer, as humans may indeed come to some sort of conclusion based on style or strangely used semantics, computers cannot, they (still) need a more literal means of semantics. If we wish to communicate that level of semantics, yes. It may not be useful to us. If you *really* need some metadata/semantics, @class probably can't convey it with enough granularity. Check out the big discussion from a few months ago about ccRel and RDFa. Second: Suppose I want to collect all copyright notices from 1000 websites (don't ask me why, I just want to), how am I to do this when they are marked up in smalls? I will definatly end up with a lot of text that has nothing to do with copyrights (and probably miss a lot of copyright notices as they are marked up differently) Whereas If they were maked up in (for example) span class=copyright I could retrieve it all based on the class-name. That would be a wonderful perfect world. I'd like the copyright date as well, so I can retrieve only things copyrighted in the last ten years. Assuming that metadata will exist is a fool's errand. The fact is that if you are searching for copyright notices, the most efficient way is likely to just search for the string copyright and the (c) symbol. That'll net you copyright notices with a high accuracy, and some training on real data can yield further rules to improve the data-mining accuracy. While we're hoping for copyright notices to be marked up as span class=copyright, though, why not wish for small class=copyright? If you're going to be providing metadata, it works the same. Is it that you believe people won't provide a special class for copyrights if the small tag already gives them the preferred display? Do you believe that everyone will automatically use class=copyright to mark up their copyright notices? What if they use class=copyright-notice? Or class=license? Or any of a million other distinct possibilities that would destroy any naive attempt to datamine based on a particular class name? ~TJ
Re: [whatwg] video tag: pixel aspect ratio
On Thu, Nov 13, 2008 at 9:12 PM, Pierre-Olivier Latour [EMAIL PROTECTED]wrote: In any case, if this attribute really needs to be present, we should rename it at the minimum (picking a term from the professional video world requires taking the constraints that come with it), maybe displayRatio or something? If you are going to keep it, how about pixelfloat, as it clearly is not presented as a ratio. The word display makes me think DAR. -- Sander
Re: [whatwg] Workers feedback
Ian, Thanks for taking the time to read and understand all the feedback. Although this is not my most preferred design for the API, I can live with it. I'm happy that we removed startConversation(). I think that was just extra complexity on top of an already large API. As for putting forward contradictory suggestions, I apologize for that. In the future, I will try to form final opinions before opining. Thanks, - a
Re: [whatwg] attribute media on script element
On Friday 2008-11-14 11:37 +0100, Filippo Levizzani wrote: Would it be possible to have media attribute in the SCRIPT element? Addmitted vaues would be the same of STYLE element (all, screen, print, handheld ...) I'm not quite sure how this would work, since there are two things that seem incompatible: * scripts are executed during parsing / content model construction * whether a media attribute is true can change over time This seems to imply that we'd have to go un-execute a script, or that we'd have to execute later something that was skipped earlier, even when that no longer makes sense. What was the actual use case you were trying to solve with this attribute? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Deprecating small, b ?
If we wish to communicate that level of semantics, yes. It may not be useful to us. If you *really* need some metadata/semantics, @class probably can't convey it with enough granularity. Check out the big discussion from a few months ago about ccRel and RDFa. Not yet maybe, but we could at least try to keep options open for the future. Second: Suppose I want to collect all copyright notices from 1000 websites (don't ask me why, I just want to), how am I to do this when they are marked up in smalls? I will definatly end up with a lot of text that has nothing to do with copyrights (and probably miss a lot of copyright notices as they are marked up differently) Whereas If they were maked up in (for example) span class=copyright I could retrieve it all based on the class-name. That would be a wonderful perfect world. I'd like the copyright date as well, so I can retrieve only things copyrighted in the last ten years. Assuming that metadata will exist is a fool's errand. The fact is that if you are searching for copyright notices, the most efficient way is likely to just search for the string copyright and the (c) symbol. That'll net you copyright notices with a high accuracy, and some training on real data can yield further rules to improve the data-mining accuracy. You say it yourself, only in a perfect world where all websites in the world would be written in the same language would your solution work. Unfortunatly I would miss out on all the chinese copyright stuff. But another example (based on siemens) wouldn't it be nice if I could tell Google I am looking for a person named Siemens so it would ignore the brand-name? While we're hoping for copyright notices to be marked up as span class=copyright, though, why not wish for small class=copyright? If you're going to be providing metadata, it works the same. Is it that you believe people won't provide a special class for copyrights if the small tag already gives them the preferred display? Do you believe that everyone will automatically use class=copyright to mark up their copyright notices? What if they use class=copyright-notice? Or class=license? Or any of a million other distinct possibilities that would destroy any naive attempt to datamine based on a particular class name? Well, that would have to be defined in the standard, wouldn't it? I'm not saying -again- it should be defined NOW, but at least leave the door open. I have no problems with using small over span, neither one is correct as far as I can see, in this context. Using copyright instead of license or copyright-notice would have to be defined somewhere, either in the standard or in an externally maintained document that is accepted as best practice or standards related. PS: I find it very difficult to respond to rich-text/html messages as they seriously mess up the indentation. Sorry therfor if this message is unclear as original message and reply are mixed up.
Re: [whatwg] Deprecating small, b ?
On Fri, Nov 14, 2008 at 10:44 AM, Pentasis [EMAIL PROTECTED] wrote: If we wish to communicate that level of semantics, yes. It may not be useful to us. If you *really* need some metadata/semantics, @class probably can't convey it with enough granularity. Check out the big discussion from a few months ago about ccRel and RDFa. Not yet maybe, but we could at least try to keep options open for the future. Of course, but I don't think having small in the language closes any options. Second: Suppose I want to collect all copyright notices from 1000 websites (don't ask me why, I just want to), how am I to do this when they are marked up in smalls? I will definatly end up with a lot of text that has nothing to do with copyrights (and probably miss a lot of copyright notices as they are marked up differently) Whereas If they were maked up in (for example) span class=copyright I could retrieve it all based on the class-name. That would be a wonderful perfect world. I'd like the copyright date as well, so I can retrieve only things copyrighted in the last ten years. Assuming that metadata will exist is a fool's errand. The fact is that if you are searching for copyright notices, the most efficient way is likely to just search for the string copyright and the (c) symbol. That'll net you copyright notices with a high accuracy, and some training on real data can yield further rules to improve the data-mining accuracy. You say it yourself, only in a perfect world where all websites in the world would be written in the same language would your solution work. Unfortunatly I would miss out on all the chinese copyright stuff. Of course. But would you expect chinese speakers to use class=copyright on their pages anyway? But another example (based on siemens) wouldn't it be nice if I could tell Google I am looking for a person named Siemens so it would ignore the brand-name? Certainly. But at this point you're expecting authors to mark up their pages with metadata every time they mention someone's name. The use of b doesn't prevent this, but your use-case certainly requires quite a lot more. While we're hoping for copyright notices to be marked up as span class=copyright, though, why not wish for small class=copyright? If you're going to be providing metadata, it works the same. Is it that you believe people won't provide a special class for copyrights if the small tag already gives them the preferred display? Do you believe that everyone will automatically use class=copyright to mark up their copyright notices? What if they use class=copyright-notice? Or class=license? Or any of a million other distinct possibilities that would destroy any naive attempt to datamine based on a particular class name? Well, that would have to be defined in the standard, wouldn't it? I'm not saying -again- it should be defined NOW, but at least leave the door open. I have no problems with using small over span, neither one is correct as far as I can see, in this context. Using copyright instead of license or copyright-notice would have to be defined somewhere, either in the standard or in an externally maintained document that is accepted as best practice or standards related. Okay, then we have no issue with small. There has been some discussion, btw, about standardizing a set of normative class names. You should be able to turn something up about it. PS: I find it very difficult to respond to rich-text/html messages as they seriously mess up the indentation. Sorry therfor if this message is unclear as original message and reply are mixed up. No problem; it was clear enough. The only richtext I use is quote levels, and with the conversation context nearby anyway, it's not difficult to puzzle out when it occasionally messes up. ~TJ
Re: [whatwg] Sending MessagePorts after they have started
Nov 14, 2008, в 8:50 AM, Jonas Sicking написал(а): To fix all this I propose that if a port has been started, we don't allow it to be passed to postMessage. If that is done an exception is thrown. Could you please explain how this scenario is affected by the port being started? Messages are queued in closed ports until those are started, so I think that it applies word to word to closed ports. - WBR, Alexey Proskuryakov
Re: [whatwg] Workers feedback
On Thu, Nov 13, 2008 at 10:17 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Aaron Boodman wrote: On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: Actually, i think we should remove the location accessor as well. I can't think of a common enough use case that warrants an explicit API. You can always transfer the data through postMessage. I added that one becase Aaron asked for it. Aaron? I think it's useful. Obviously it's not totally necessary. What are the use cases? Also note that we can't use it with shared workers since they can be connected to several pages from different uris. It represents the URI of the worker itself, not the URI of the calling page. In Gears, authors asked us for a location object because they had applications that could be served from different origins. Also in Gears, workers can be accessed across origins, so incoming messages need to be validated that they are from the correct origin. It's more convenient for a worker to access its own origin through an API the UA provides than to bake it into the script or send it in the first postMessage(). Although HTML5 workers don't have the ability to be accessed across origins, you do have the ability to receive ports that are connected to other origins, right? So this might still be an issue. Other than that, I can't think of any specific use cases. It seemed like a generally useful API to have access to. - a
Re: [whatwg] attribute media on script element
On Friday 2008-11-14 18:53 +0100, Filippo Levizzani wrote: * whether a media attribute is true can change over time but the same applies to style element , I guess Yes, but styles can be applied and unapplied easily. This seems to imply that we'd have to go un-execute a script, or that we'd have to execute later something that was skipped earlier, even when that no longer makes sense. What was the actual use case you were trying to solve with this attribute? For instance, I'd like to call SWFObject function (to replace html content with flash) only if media=screen. Other times there are js funcions that have no sense if a given style sheet has not been applied to the page. Would an API that you call from script that allows you to determine if a given media query matches the default view be sufficient for your needs? That seems like it could be more useful than an attribute that simply prevents scripts from executing, and it avoids introducing similar-looking attributes that actually behave very differently. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[whatwg] Off-topic: listserv bounces
Could a list admin please contact me off-list regarding strange bounce errors? I've tried contacting an admin through the list admin email twice and have received no responses. Thanks Aaron
Re: [whatwg] Sending MessagePorts after they have started
Alexey Proskuryakov wrote: Nov 14, 2008, в 8:50 AM, Jonas Sicking написал(а): To fix all this I propose that if a port has been started, we don't allow it to be passed to postMessage. If that is done an exception is thrown. Could you please explain how this scenario is affected by the port being started? Messages are queued in closed ports until those are started, so I think that it applies word to word to closed ports. Where the messages are queued are an implementation detail. So you can queue messages in the outgoing port until you get word from the receiving port that it has been opened. At that point you know where the receiving port lives and will always live for the rest of its life and can send all messages directly there. That said, we have to review this whole pass-around-ability thing again. You definitely highlighted some pretty serious problems in another thread, especially around the need to do cross-process GC. I think the communication problem can be solved, i'm less sure about the GC one. / Jonas
Re: [whatwg] Workers feedback
Alexey Proskuryakov wrote: Nov 14, 2008, в 10:00 AM, Jonas Sicking написал(а): What are the use cases? Also note that we can't use it with shared workers since they can be connected to several pages from different uris. It returns the script's URL, not the page's. Oh?! Then I understand even less what the use case is. This is something that doesn't exist for script and i've never heard anyone ask for it (granted, that is not proof that no one wants it). Actually, this exists for script is you say that it returns the URL that the script execution context uses for resolving relative URLs. It just so happens that for script, it's document URL, and for workers, it's script URL. That works the same in Workers iirc, without the need for a .location API. Actually, come to think of it, what is the BaseURI for workers? I.e. what URI is importScripts and XHR resolved against? / Jonas
Re: [whatwg] Sending MessagePorts after they have started
Nov 14, 2008, в 11:31 PM, Jonas Sicking написал(а): Could you please explain how this scenario is affected by the port being started? Messages are queued in closed ports until those are started, so I think that it applies word to word to closed ports. Where the messages are queued are an implementation detail. So you can queue messages in the outgoing port until you get word from the receiving port that it has been opened. At that point you know where the receiving port lives and will always live for the rest of its life and can send all messages directly there. That's an interesting idea! But this means that such ports have to remain entangled (in an invisible manner) even after being explicitly told to close. E.g., if portA sends messages, then is closed, and only after that, portB is started. If messages are to be queued at portA, they will need to be sent at this point - tricky! I agree that the communication problem is much simpler than GC though - it's just that trying to fix it makes GC even more complicated because of the need to track forwarding objects, hidden entangled state etc. Nov 14, 2008, в 11:32 PM, Jonas Sicking написал(а): Actually, come to think of it, what is the BaseURI for workers? I.e. what URI is importScripts and XHR resolved against? The base URL of a URL passed to an API in a worker is the absolute URL given that the worker's location attribute represents. Both the origin and effective script origin of scripts running in workers are the origin of the absolute URL given that the worker's locationattribute represents. - WBR, Alexey Proskuryakov
Re: [whatwg] attribute media on script element
On Fri, 14 Nov 2008, Filippo Levizzani wrote: Would it be possible to have media attribute in the SCRIPT element? Addmitted vaues would be the same of STYLE element (all, screen, print, handheld ...) This doesn't really work because media queries are supposed to change dynamically. The real solution here is a combination of XBL2 and a new API in the CSSOM-View draft (window.media). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Bug in worker example 1.2.5
Example 1.2.5 Delegation has a bug in it. The subworker defines a function do, which I guess is technically ok, but then calls it like this: do();. This triggers an exception. Let's rename the function to something less evil. -Ben
Re: [whatwg] Sending MessagePorts after they have started
Alexey Proskuryakov wrote: Nov 14, 2008, в 11:31 PM, Jonas Sicking написал(а): Could you please explain how this scenario is affected by the port being started? Messages are queued in closed ports until those are started, so I think that it applies word to word to closed ports. Where the messages are queued are an implementation detail. So you can queue messages in the outgoing port until you get word from the receiving port that it has been opened. At that point you know where the receiving port lives and will always live for the rest of its life and can send all messages directly there. That's an interesting idea! But this means that such ports have to remain entangled (in an invisible manner) even after being explicitly told to close. E.g., if portA sends messages, then is closed, and only after that, portB is started. If messages are to be queued at portA, they will need to be sent at this point - tricky! I agree that the communication problem is much simpler than GC though - it's just that trying to fix it makes GC even more complicated because of the need to track forwarding objects, hidden entangled state etc. Indeed. Nov 14, 2008, в 11:32 PM, Jonas Sicking написал(а): Actually, come to think of it, what is the BaseURI for workers? I.e. what URI is importScripts and XHR resolved against? The base URL of a URL passed to an API in a worker is the absolute URL given that the worker's location attribute represents. Both the origin and effective script origin of scripts running in workers are the origin of the absolute URL given that the worker's locationattribute represents. Hmm.. this makes a lot of sense for importScripts, but for XHR you probably want the baseURI to be that of the opening page, since it's quite likely that the opening page gave you a URI to open and process. Of course that would be quite confusing (different baseURIs for different APIs), as well as impossible for shared workers as they don't have a single document as opener. What we need is an API for resolving relative URIs, that way scripts can at least do the resolving manually. We could also add an API for getting the baseURI of the document on the other side of a port (should possibly live on the message event). / Jonas
Re: [whatwg] Sending MessagePorts after they have started
On Fri, Nov 14, 2008 at 4:33 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Hmm.. this makes a lot of sense for importScripts, but for XHR you probably want the baseURI to be that of the opening page, since it's quite likely that the opening page gave you a URI to open and process. My expectation was that the base URI would always be the URI of the worker. I think of opening a worker a lot like starting a new process, or opening a new window. I would expect that the new process has its own base URI which is the same URI as the script it is running. - a
Re: [whatwg] Sending MessagePorts after they have started
On Fri, Nov 14, 2008 at 4:37 PM, Aaron Boodman [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2008 at 4:33 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Hmm.. this makes a lot of sense for importScripts, but for XHR you probably want the baseURI to be that of the opening page, since it's quite likely that the opening page gave you a URI to open and process. My expectation was that the base URI would always be the URI of the worker. I think of opening a worker a lot like starting a new process, or opening a new window. I would expect that the new process has its own base URI which is the same URI as the script it is running. My mental model for workers is a GUI less document almost. A dedicated worker is akin to a nested iframe. A shared worker is akin to a top window or tab. In that model, base is src of the resource loaded into the context. baseURI of the opening page I don't think that would work well for shared workers. - a
Re: [whatwg] Sending MessagePorts after they have started
Aaron Boodman wrote:
On Fri, Nov 14, 2008 at 4:33 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Hmm.. this makes a lot of sense for importScripts, but for XHR you probably
want the baseURI to be that of the opening page, since it's quite likely
that the opening page gave you a URI to open and process.
My expectation was that the base URI would always be the URI of the
worker. I think of opening a worker a lot like starting a new process,
or opening a new window. I would expect that the new process has its
own base URI which is the same URI as the script it is running.
Indeed, and that is what the spec says. However I think in many cases
for XHR that is probably not what is the most useful. Consider for example:
example.html:
w = new Worker(http://docs.google.com/MSWordParser.js;);
w.onmessage = function (e) {
doneLoadingDoc(JSON.parse(e.data));
}
w.postMessage(/documents/report.doc);
MSWordParser.js:
onmessage = function(e) {
xhr = new XMLHttpRequest();
xhr.open(GET, e.data, false);
xhr.send();
res = mainParse(xhr.responseText);
postMessage(JSON.stringify(res));
}
The above won't work since the URL is relative to the worker JS file,
not relative to example.html. So an absolute URI always needs to be used
which sort of sucks as is unintuitive from the point of view of most DOM
APIs today.
I don't really have a good solution to propose though. We might need to
add an API for resolving relative URIs and require that scripts use that
manually.
/ Jonas
Re: [whatwg] Reworking the media load() algorithm so that it tries more than one video
The changes look like improvements to me, but I have some questions. 1. Is there any particular reason why step 7 generate the list of potential media resources is done in the synchronous part of the algorithm? Would it for example be an error to consider playing sources added in a loadstart event handler? As it stands one would have to actually make a list of candidate URLS and pixel ratio overrides up front. I don't really object, I just want to confirm that this is intentional. 2. Did you remove canPlayType? It was added in http://html5.org/tools/web-apps-tracker?from=2331to=2332 and now it seems to be gone, but I can't find the revision in which that happened. 3. MEDIA_ERR_DECODE isn't just for corrupted data. If source type=application/ogg is given and the browser doesn't know it cannot render it but it turns out that it couldn't decode any of the content (perhaps it was Ogg FLAC), isn't MEDIA_ERR_DECODE precisely what should happen? In other words, the word corrupted ought to be unrecognized, not decodable or something which doesn't imply that the media resource itself is at fault. Philip On Fri, 2008-11-14 at 06:51 +, Ian Hickson wrote: On Thu, 16 Oct 2008, Robert O'Callahan wrote: I am proposing changing the spec to make the load() not select a resource. Instead, load() would immediately return, and the user agent would then asynchronously try each resource that it might otherwise use in turn, firing a single loadstart event at the start, lots of progress events, and then a loadedmetadata or error event depending on how things go. That sounds good. I've now done this. This is a pretty big change. I'm sure I've screwed something up in the process. Implementors! Please let me know if you see anything newly broken with loading resources! Thanks. :-) Cheers, -- Philip Jägenstedt Opera Software
Re: [whatwg] Exposing UA information to workers
Jonas asked me about this in IRC, and specifically why I suggested
appCodeName (since everyone claims they are Mozilla). My thinking was:
a) Browser detection is a mess, scripts use everything on the
navigator object (often incorrectly) to try and figure out which
browser is which
b) HTML5 may eventually define something better
Therefore, I could see two rational things for workers to expose: all
of whatever window.navigator has today, or whatever the new better API
is that HTML5 defines. I guess doing some subset of what
window.navigator does today could also be rational, but I don't know
how to pick the subset.
FWIW, here is the browser detection code that many Google apps use:
http://code.google.com/p/doctype/wiki/ArticleUserAgent
It uses:
- userAgent
- product
- vendor
- platform
- a
On Mon, Nov 3, 2008 at 3:59 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
For future compat it would be good to expose to workers information on what
browser is currently being used. This can be used to work around bugs and
lack of features.
In a 'normal' window context the navigator object exposes a set of
properties, such as userAgent, that can be used for this purpose. I suggest
we add something similar to the worker context. The HTML5 spec defines the
following:
interface Navigator {
// client identification
readonly attribute DOMString appName;
readonly attribute DOMString appVersion;
readonly attribute DOMString platform;
readonly attribute DOMString userAgent;
// ... other things not related to identifying the UA
};
I'm not sure how stable this part of the HTML5 spec is, (I know firefox
exposes a whole host of more properties), but it seems like a good set to
start with. We should probably keep the two in sync if the window context
Navigator object changes in the future.
Orthoginally, it seems like at least the 'onLine' boolean on the Navigator
interface would be useful too, and could be exposed at the same place.
Let me know what you think.
/ Jonas
Re: [whatwg] Scripted querying of video capabilities
On Thu, 16 Oct 2008, Robert O'Callahan wrote: I have added window.navigator.canPlayType(mimeType). It returns 1, 0, or -1 to represent positive, neutral, and negative responses. navigator.canPlayType could be confusing since authors might think it includes media playable via plugins or other browser functionality. Making it a method on video/audio would be more obvious and, I think, no less useful in practice. Ok. Done. On Thu, 16 Oct 2008, Maciej Stachowiak wrote: This API would be tempting to treat as a boolean but would of course do completely the wrong thing. I think it would be better to either ensure that the positive and neutral responses are both values that JS would treat as true (for instance make the values true, maybe and false), or else make all of the return values something self-descriptive and symbolic (for instance the strings yes, maybe and no). I think 1, 0, -1 are neither clear nor likely to be in any way beneficial for perforamnce. I've made the method return strings. On Fri, 14 Nov 2008, Robert O'Callahan wrote: I think it would be a lot better if there were two methods returning booleans, say, canPlayType and cannotPlayType. I think it would be misleading to return false from cannotPlayType(). On Thu, 13 Nov 2008, Jeremy Doig wrote: did this thread go anywhere ?i'm concerned about the maybe case - looks way too much like: http://en.wikipedia.org/wiki/DShow#Codec_hell Well we have to have a maybe case, since the UA might not know the answer. also - when you probe for mime type, do you mean the entire type parameter (including the codecs string) ? for example, there are too many cases where just passing video/mp4 would be insufficient. (fragmented index support ? base/main/high profile ? paff ? cabac ?) Clarified this. On Thu, 13 Nov 2008, Philip J�genstedt wrote: I'm also a bit concerned about how to interpret the yes, no and maybe return values. The truthful answer is going to be maybe for all but the obviously unsupporter (application/x-ms-dos-executable) and the more trivial formats (audio/wav). Indeed (except for audio/wave). When asking about application/ogg, this could mean 2 things: 1. can I demux Ogg streams? 2. can I demux Ogg streams and decode unknown codecs? It's the second (and thus the answer can only ever be maybe or no). The answer to question 1 is reasonably simple to answer in most cases, even if the underlying media frame doesn't support querying for mime types a mapping between mime type and supported decoders isn't impossible. The answer to question 2, on the other hand, is always no or maybe. Right. Unless the codecs parameter is to be made mandatory I think that spec should explicitly make it such that the question asked is 1. In either case we will end up there because 2 is not a meaningful question and user agents will make untruthful answers in attempts to stay compatible with unknown and future content (which might be supported by installing new codecs in the media framework without upgrading the browser). Now, if the codec parameter is used then the user agent may answer yes and no in a way that actually makes some sense. The spec now encourages codecs= be provided. I also think that this should be explicitly related to the type attribute of the source element. One should be able to use canPlayType to predict with 100% accuracy which source the user agent will use when it encounters. Done. On Fri, 14 Nov 2008, Robert O'Callahan wrote: The browser can only answer no or maybe in this case. That seems fine to me. It lets the author know whether the browser can demux Ogg streams, while staying consistent with the behaviour when codec information is given in the MIME type. I don't understand what the incentives are for browsers to lie. If we start off telling the truth, then authors will have to write scripts that either accept maybe or, better still, provide the codec information, or their scripts won't work. I don't see how that would change over time. Authors should be strongly encouraged to give the codec parameters. Agreed. On Thu, 13 Nov 2008, Dave Singer wrote: Pitching in here, I think it's OK if we want to go to a two-state answer -- but those answers are No and Maybe, not No and Yes. There are, after all, vanishingly small numbers of mime types where I can be 'completely' (within reason) confident of a 'yes' answer. On the other hand, given a mime type I simply don't recognize, or a codec I know I don't have, I can be confident of a No. Documenting it as providing a No/Maybe indication, and that how positive the 'Maybe' is depends to a large extent on how precise the supplied mime type is, would be fine by me, I think. I've left it as a three-state method, but encouraged implementors to not return a positive answer unless they're sure. -- Ian Hickson U+1047E
