Re: [whatwg]

Robert J Burns wrote: ... Let us keep in mind that the HTML5 draft does not reference ISO 8601. It also already reaches way beyond ISO 8601 and claims to handle dates all the way back to -01-01 whereas ISO 8601 only handles dates between 1582 and . So HTML5 already takes on the task of

Re: [whatwg]

An author need not be the first author. An editor charged with maintaining a site where Julian date markup is used would have to learn Julian date markup. In this way, whenever we include a feature that we consider optional, we ultimately make the editors, if not the primary authors, learn about

Re: [whatwg]

Andy Mabbett wrote: > In message , > Jim O'Donnell writes > >> This is already a solved problem in the Text Encoding Intiative (TEI). >> The value of a date/time is encoded in the Gregorian calendar, using >> ISO8601. The calendar attribute is used to indicate the calendar of >> the origin

Re: [whatwg]

At 17:02 +0100 13/03/09, Leif Halvard Silli wrote: I struggle to understand why it is better to ask *authors* to use One True Calendar instead of e.g having a scheme attribute through which the author can specify the date/time format. You might want to read

[whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

This problem recently became apparent while trying to process a public video on tinyvid.tv: In article 4.8.11.3 "Security with canvas elements", the origin-clean flag is only set depending on an element's origin. However there are many scenarios where an image/video may actually be public and acti

Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

I think this is an excellent point. I've been playing with the Chroma-Key replacement trick demonstrated in FireFox 3.1b3: https://developer.mozilla.org/samples/video/chroma-key/index.xhtml https://developer.mozilla.org/En/Manipulating_video_using_canvas For my own experiments, I grabbed a green-s

Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

On Fri, Mar 13, 2009 at 9:24 AM, Hans Schmucker wrote: > This problem recently became apparent while trying to process a public > video on tinyvid.tv: > > In article 4.8.11.3 "Security with canvas elements", the origin-clean > flag is only set depending on an element's origin. However there are >

Re: [whatwg] Proposal for enhancing postMessage

On Wed, Mar 11, 2009 at 2:30 PM, Drew Wilson wrote: > Mark, I won't pretend to completely understand the use cases you're > describing as I'm not familiar with the prior work you've cited. But my > understanding of the postMessage() API is that they are primarily useful for > handing off ports to

Re: [whatwg] Proposal for enhancing postMessage

Yes, it sends a clone, but the source port becomes unentangled (inactive) - step 5 of the "clone a port" specification reads: Entangle the remote port and new port objects. The original port object will be unentangled

Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

Question is: what would be the best way to fix it? Of course the spec could be changed for video and image, but wouldn't it be simpler to update the defintion of origins to include patterns that can represent allow rules?

Re: [whatwg]

At 19:26 -0500 13/03/09, Robert J Burns wrote: The chief accomplishments of ISO 8601 is the ability to represent dates in a uniform manner and in defining the Gregorian calendar from 1582 to in an unambiguous way. Beyond those dates it leaves things imprecise and ambiguous. You keep say