Re: [whatwg] [Canvas] Text height
On Mon, 23 Apr 2012, Tyler Larson wrote: The measureText method in canvas' 2d context only returns the width of a span of text. Why not the height? Your information is out of date. :-) http://www.whatwg.org/specs/web-apps/current-work/#dom-context-2d-measuretext -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Fri, Apr 20, 2012 at 3:43 AM, Henri Sivonen hsivo...@iki.fi wrote: On Tue, Jan 10, 2012 at 2:10 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 31 May 2011, Henri Sivonen wrote: Recently, there was discussion about changing media element state in the same task that fires the event about the state change so that scripts that probe the state can make non-racy conclusions about whether a certain event has fired already. Currently, there seems to be no correct non-racy way to write code that probes a document to determine if DOMContentLoaded or load has fired and runs code immediately if the event of interest has fired or adds a listener to wait for the event if the event hasn't fired. Are there compat or other reasons why we couldn't or shouldn't make it so that the same task that fires DOMContentLoaded changes the readyState to interactive and the same task that fires load changes readyState to complete? Fixed for 'load'. I don't see a good way to fix this for 'DOMContentLoaded', unfortunately. It turns out that Firefox has accidentally been running defer scripts after DOMContentLoaded. I haven't seen bug reports about this. Embracing this bug might offer a way to always keep the readystatechange to interactive in the same task that fire DOMContentLoaded. See http://hsivonen.iki.fi/test/moz/readystate/defer-script.html Hmm.. how long as that been the case? I thought that when we originally implemented @defer we ran them before DOMContentLoaded was fired for various internal sanity reasons as well as because it gave authors better migration paths. It seems nice to me to be able to depend on that all scripts have run by the time that DOMContentLoaded is fired. Except for async scripts of course, which are always unreliable as to when and which order they execute. I.e. async scripts is an explicit footgun, but I'd rather have fewer of those. / Jonas
Re: [whatwg] Readiness of script-created documents
On Mon, Apr 23, 2012 at 4:55 AM, Henri Sivonen hsivo...@iki.fi wrote: On Mon, Jun 20, 2011 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen hsivo...@iki.fi wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) complete seems like the most useful and consistent value which would seem like a good reason to require that. Why don't aborted documents reach complete in Gecko? It seems weird to have aborted documents stay in the loading state when they are not, in fact, loading. Sounds like a bug, I don't think this was done on purpose. I agree that we should ideally only be in loading when we're actually loading. / Jonas
[whatwg] File based permission files?
How about adding file based permission files? While working with the canvas tag when you want to edit pixel data within an image loaded from another server you need to have these images served from a web server with cross origin resource sharing headers. http://www.w3.org/TR/cors/ This means every web server around the internet will need to be reconfigured to output these headers for each asset they want to give access to. As you can see from threads like this https://forums.aws.amazon.com/thread.jspa?threadID=34281 host don't want to change the way they serve files. Reconfiguring most web servers is out of the question for a majority of situations. The flash player has similar security concerns, you can not load an image from another server and edit its pixel information without a crossdomain.xml file. This system has been in place so long that most companies have these files already in place and are usually giving access to all assets on their servers. http://www.google.com/crossdomain.xml http://www.apple.com/crossdomain.xml http://www.yahoo.com/crossdomain.xml http://www.adobe.com/crossdomain.xml It took a lot of convincing to get these files in place and this was just adding a single file. Changing the way that people configure there file servers is simply out of the question in relation to the conversations I have had with people. I would think at minimum we need a way to do file based permissions. The format of the document could be per file or per domain or uri but what might be even better than coming up with a new standard might be to use the one that is already in place. How about just using these crossdomain.xml files. Here is adobe's spec http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html Microsofts supports crossdomain.xml files for some of their technologies http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx Java supports it also http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML I'm sure there are other technologies as well but I'm sorry I don't have links.
Re: [whatwg] File based permission files?
On 4/25/2012 12:08 PM, Tyler Larson wrote: I would think at minimum we need a way to do file based permissions. The format of the document could be per file or per domain or uri but what might be even better than coming up with a new standard might be to use the one that is already in place. How about just using these crossdomain.xml files. You can do cross-domain permission via IFRAME and postMessage. Now that transfer semantics are widely accepted, you can efficiently send an array buffer across frames. So you setup something like trampoline.html, you connect to it via iframe and send it a message, then trampoline.html does an XHR request (in its own domain) and sends back the data. It's better than a .xml file because it's scriptable. -Charles
Re: [whatwg] File based permission files?
You can do cross-domain permission via IFRAME and postMessage. Now that transfer semantics are widely accepted, you can efficiently send an array buffer across frames. So you setup something like trampoline.html, you connect to it via iframe and send it a message, then trampoline.html does an XHR request (in its own domain) and sends back the data. It's better than a .xml file because it's scriptable. -Charles Good to know, I haven't used this before but it still seems to be intended for a different use case. I'm basing my knowledge on write ups like this, https://developer.mozilla.org/en/DOM/window.postMessage From my understanding the pixel data would need to be loaded into the iframes page, that page would then get the pixel data and post that data back so that I could then use it. I can get around my issue a bunch of different ways and people will be forced to create all forms of hacks and proxy servers to make their applications work but based on the things I have seen, what you are suggesting is far more complicated than a standard crossdomain.xml setup. Setting something up once and moving on, rather than needing to script a communication layer between what files you want to load and sending that information across a messing system. I still think that my proposal is valid. Lets say I am building anything using the canvas that loads images from anywhere else on the internet and then wants to manipulate them. If javascript used the same setup, a crossdomain.xml file would be loaded without the developer needing to do anything as soon as they requested something that needed the permissions. An event would be fired if this you tried to do something that you didn't have permissions to do, otherwise everything would just work. The current COR setup is also transparent which I like, what I don't like about it is simply that system admins will fight needing to reconfigure their servers to add these headers leaving developers unable to use these features. If we make use of the security files already in place we can get going on canvas based image manipulation today without anyone needing to change anything. -Tyler Larson
Re: [whatwg] File based permission files?
On 4/25/2012 1:01 PM, Tyler Larson wrote: You can do cross-domain permission via IFRAME and postMessage. Now that transfer semantics are widely accepted, you can efficiently send an array buffer across frames. So you setup something like trampoline.html, you connect to it via iframe and send it a message, then trampoline.html does an XHR request (in its own domain) and sends back the data. It's better than a .xml file because it's scriptable. -Charles Good to know, I haven't used this before but it still seems to be intended for a different use case. I'm basing my knowledge on write ups like this, https://developer.mozilla.org/en/DOM/window.postMessage From my understanding the pixel data would need to be loaded into the iframes page, that page would then get the pixel data and post that data back so that I could then use it. Yes, you'd send pixel data or you'd send the file data (as received from XHR as an array buffer or blob). I can get around my issue a bunch of different ways and people will be forced to create all forms of hacks and proxy servers to make their applications work but based on the things I have seen, what you are suggesting is far more complicated than a standard crossdomain.xml setup. Setting something up once and moving on, rather than needing to script a communication layer between what files you want to load and sending that information across a messing system. It's not very complicated, it's a few lines of code. It's certainly more complicated than things just working with crossdomain.xml and/or CORS. But it is a solution that works across all browsers that work with postMessage. It's also a solution that we may see more of with things like web intents and wider use of SharedWorker. I still think that my proposal is valid. Lets say I am building anything using the canvas that loads images from anywhere else on the internet and then wants to manipulate them. If javascript used the same setup, a crossdomain.xml file would be loaded without the developer needing to do anything as soon as they requested something that needed the permissions. An event would be fired if this you tried to do something that you didn't have permissions to do, otherwise everything would just work. Your proposal is certainly valid. Currently one could probably use Flash for crossdomain.xml. You're looking to put something out there that people can use without needing to change settings on their web host. That's a reasonable goal. And crossdomain.xml did work well for a limited set of cases with Flash. I'm just saying that we have methods in place today that do work. The current COR setup is also transparent which I like, what I don't like about it is simply that system admins will fight needing to reconfigure their servers to add these headers leaving developers unable to use these features. If we make use of the security files already in place we can get going on canvas based image manipulation today without anyone needing to change anything. Seems like it's about four lines of code in Flash: http://stackoverflow.com/questions/1088323/flash-crossdomain-xml-problems postMessage isn't much different. I doubt you'll see vendor buy-in on the proposal simply because so much is working with web messaging. -Charles
[whatwg] Footer inside header
Currently, a footer tag is not allowed to appear inside a header tag and vice-versa. That does makes sense when sticking to what the names of the elements imply, yet conceptually I see no reason a footer as in textual metadata of a section can't be inside a header (lead of a section). Could this be considered to be allowed?
Re: [whatwg] File based permission files?
On 25.4.2012 22:01, Tyler Larson wrote: You can do cross-domain permission via IFRAME and postMessage. Now that transfer semantics are widely accepted, you can efficiently send an array buffer across frames. So you setup something like trampoline.html, you connect to it via iframe and send it a message, then trampoline.html does an XHR request (in its own domain) and sends back the data. It's better than a .xml file because it's scriptable. -Charles Good to know, I haven't used this before but it still seems to be intended for a different use case. I'm basing my knowledge on write ups like this, https://developer.mozilla.org/en/DOM/window.postMessage From my understanding the pixel data would need to be loaded into the iframes page, that page would then get the pixel data and post that data back so that I could then use it. I can get around my issue a bunch of different ways and people will be forced to create all forms of hacks and proxy servers to make their applications work but based on the things I have seen, what you are suggesting is far more complicated than a standard crossdomain.xml setup. Setting something up once and moving on, rather than needing to script a communication layer between what files you want to load and sending that information across a messing system. I still think that my proposal is valid. Lets say I am building anything using the canvas that loads images from anywhere else on the internet and then wants to manipulate them. If javascript used the same setup, a crossdomain.xml file would be loaded without the developer needing to do anything as soon as they requested something that needed the permissions. An event would be fired if this you tried to do something that you didn't have permissions to do, otherwise everything would just work. The current COR setup is also transparent which I like, what I don't like about it is simply that system admins will fight needing to reconfigure their servers to add these headers leaving developers unable to use these features. If we make use of the security files already in place we can get going on canvas based image manipulation today without anyone needing to change anything. -Tyler Larson your solution have several issues: 1/ yet another request a) you make prefligh request b) you make xml file request c) you download data 2/ those specification are not 1:1 compatible, how should those be combined? Should they be combined? 3/ there may be collision in HTTP headers and you XML file, one negating setting of the other. Which should take precedence? a) HTTP over XML file? then you solution makes no sense (since default server settings disallows CORS, XML has no chance here) b) XML over HTTP? I doubt W3C and browser vendors would be happy with specification they have no control over, and one thing is how Adobe is managing policy in their Flash, another thing is to get consensus among all parties within whole W3C (Adobe can change their specification and implement it in Flash as Adobe see fit, without any consensus, this is not possible for W3C / browser vendors) 4/ changes in one could create pressure to change the other and the other party may not be willing to do so... and we are back in combining / precedence issue You simply have to make a pressure on sharing services, that if want to share data, they have to allow it. And if they do not want to allow it, they simply do not want to share... and that is why we have CORS... Yes, they will either solve it by reconfiguring server, or some domain level policy file specific to server could solve it (e.g. .htaccess) Brona
