Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Sat, Mar 14, 2009 at 12:53 PM, Hans Schmucker hansschmuc...@gmail.comwrote: 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? I don't think changing the definition of origins is the right way to go. It seems better to define a category of public resources, specify that a resource served with Access-Control-Allow-Origin: * is public, and have canvas. treat public resources specially. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] time
In message 20090314083450.ga30...@stripey.com, Smylers smyl...@stripey.com writes This thread appears to be proving that dates are very complicated and that to get them right for the general case involves lots of subtleties, All true. which would be a reason for punting -- only doing the simplest possible thing for now, acknowledging that that doesn't meet all desirable scenarios, and leaving everything else for HTML 6. I'm not clear on what basis you reach that conclusion from the undisputed facts above. Even attempts to produce a small list of changes that we have consensus on yields others disputing them, showing that we don't have consensus. ...yet. Right now we have a draft that: 2) allows without attaching sufficient meaning to it I don't think that's the case; the algorithm for parsing a year requires a number greater than zero: What a pity that human history - as published in the wild - doesn't fit that convenient shortcut. So my suggestion for a spec change is to replace zero with 1582. That further reduces the set of dates that time can represent, but avoids the complexity of pre-Gregorian dates, and avoids inadvertently giving a meaning to them that hampers the efforts of a future version of HTML to do all of this right. What advantage does deferring this problem give us, other than side-stepping something which needs to be addressed? -- Andy Mabbett Says NO! to compulsory UK ID Cards: http://www.no2id.net/ and: Free Our Data: http://www.freeourdata.org.uk (both also on Facebook)
Re: [whatwg] time
On 13 Mar 2009, at 16:19, David Singer wrote: Can we drop this topic? Apart from suggesting a) that the fully delimited date format be required (extended format); b) that year and before be allowed; c) that parsing the body text as 8601 may be dangerous if it's notated the same way but not (possibly proleptic) Gregorian; I agree, with the addition of time periods denoted by two datetimes seperated by a / eg. 1914/1918. This would bring HTML5 in line with existing authorship practices in use in TEI. Authors will be able to encode any historical date be it Julian, Roman, Mayan, Chinese etc by continuing to do what they're already accustomed to doing - publishing the machine readable date as a proleptic Gregorian date. The proposed schemes for alternative calendars seem like a red herring to me, since noone in practice encodes machine readable versions of alternative calendars when digitising a text. Regards Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens http://twitter.com/pekingspring
Re: [whatwg] time
On 13 Mar 2009, at 10:33, Mikko Rantalainen wrote: 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 original, written date enclosed in the tags. I'm not sure why the original calendar would need to be indicated in the 'calendar' attribute. It does not matter for the 'value' or software in general, if I've understood correctly. If the 'value' is always in Proleptic Gregorian calendar, it's all the software needs to know. Hello, the usual use of TEI is encoding historical papers for digital preservation eg. digitising large archives of correspondence or literature. The calendar attribute exists to preserve semantic information in the digital version of a paper document. I was interested to know whether there was value in preserving such information in HTML also, since digital versions of historic documents are published on the web as HTML. I understand, though, that HTML should not become a grab bag of features from other SGML or XML vocabularies so I wouldn't push for a calendar attribute on time if it isn't generally useful or if I'm the only person that wants it. Regards Jim Jim O'Donnell j...@eatyourgreens.org.uk http://eatyourgreens.org.uk
Re: [whatwg] time
Andy Mabbett writes: In message 20090314083450.ga30...@stripey.com, Smylers smyl...@stripey.com writes This thread appears to be proving that dates are very complicated and that to get them right for the general case involves lots of subtleties, All true. which would be a reason for punting -- only doing the simplest possible thing for now, acknowledging that that doesn't meet all desirable scenarios, and leaving everything else for HTML 6. I'm not clear on what basis you reach that conclusion from the undisputed facts above. Even attempts to produce a small list of changes that we have consensus on yields others disputing them, showing that we don't have consensus. ...yet. Indeed. Spending more time on this may well yield something useful and acceptable to at least most of those with opinions. When that has happened the outcome can be incorporated in HTML 6. So my suggestion for a spec change is to replace zero with 1582. That further reduces the set of dates that time can represent, but avoids the complexity of pre-Gregorian dates, and avoids inadvertently giving a meaning to them that hampers the efforts of a future version of HTML to do all of this right. What advantage does deferring this problem give us, other than side-stepping ... Side-stepping _is_ the advantage. HTML 5 has many improvements over current specs, most of them not in the slightest bit related to dates, eras, timezones, lunar cycles, or Popes. ... something which needs to be addressed? It doesn't need to be addressed in order for people to benefit from the other features, and improved interoperability, in HTML 5. An HTML standard which doesn't provide a completely general time element is still a useful HTML standard. I'm proposing that we don't hold up that standard while trying to solve a hard problem. (I'm still in favour of people working on it to solve it. And if there happened to be a consensus for a (partial) solution now I wouldn't be against including it. But that isn't where we are.) Smylers
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
Doesn't that kind of defeat the purpose of access control to have fine grained control over who is allowed access? Public resources are a quick fix for most scenarios that I can imagine, but I think using patterns would appear more consistent and logical to most users. It may not be terribly useful, but it would avoid a few embarassing moments for people who use access control. On 3/14/09, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 14, 2009 at 12:53 PM, Hans Schmucker hansschmuc...@gmail.comwrote: 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? I don't think changing the definition of origins is the right way to go. It seems better to define a category of public resources, specify that a resource served with Access-Control-Allow-Origin: * is public, and have canvas. treat public resources specially. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Fri, 13 Mar 2009 23:53:36 -, Hans Schmucker hansschmuc...@gmail.com wrote: 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? Aside: You might want to take a look at a later version of the specification (the one that is being implemented): http://dev.w3.org/2006/waf/access-control/ -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Link.onload
This is a request for the link element to be given an onload attribute. Often when lazy loading a plugin into an web app it is necessary for the plugin's stylesheets to be applied before the plugin's JavaScript is downloaded. Without the link element having an onload event there is not really a straightforward way of doing this. Currently I am using XMLHttpRequests to grab the stylesheets first since XHR has a success callback, and then appending the stylesheets to the document.head relying on the browser using the cached stylesheet. This seems to work for the most part, but really there are no guarantees. There are other odd workarounds but none of them as straightforward, elegant, and easy to use as the link elements simply having an onload attribute. Thank you for your consideration. Greg Houston
Re: [whatwg] Link.onload
On Sat, Mar 14, 2009 at 1:48 PM, Greg Houston gregory.hous...@gmail.com wrote: This is a request for the link element to be given an onload attribute. I see. Often when lazy loading a plugin into an web app it is necessary for the plugin's stylesheets to be applied before the plugin's JavaScript is downloaded. Without the link element having an onload event there is not really a straightforward way of doing this. It sounds like you want to load resource with dependencies. Currently I am using XMLHttpRequests to grab the stylesheets first since XHR has a success callback, and then appending the stylesheets to the document.head relying on the browser using the cached stylesheet. This seems to work for the most part, but really there are no guarantees. When a stylesheet is added to the document, how (or even if) the resource is downloaded and applied is not part of any official standard. There are other odd workarounds but none of them as straightforward, elegant, and easy to use as the link elements simply having an onload attribute. I proposed a solution to a similar problem not too long ago. script depends=[idref] .../script This would allow for scripts to run without having to wait for stylesheets to load. When the browser parses script depends=..., it looks for elements matching ids in the depends attribute and downloads all of them before running the script. This could be used for other resources, too. object depends=[idref] ... /object - where [idref] is the stylesheet to be loaded. Thank you for your consideration. You seem optimistic. Check the thread: [whatwg] defer on style, depends http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018420.html The first sentence:- | This is a request for the link element to be given an onload attribute. Example:- link onload=loadPlayer() ... - would solve your problem, but with less simplicity than the depends=[...] would. Greg Houston Garrett
Re: [whatwg] time
On Sat, Mar 14, 2009 at 8:23 AM, Smylers smyl...@stripey.com wrote: only doing the simplest possible thing for now, acknowledging that that doesn't meet all desirable scenarios, and leaving everything else for HTML 6. I'm proposing that we don't hold up that standard while trying to solve a hard problem. (I'm still in favour of people working on it to solve it. And if there happened to be a consensus for a (partial) solution now I wouldn't be against including it. But that isn't where we are.) Smylers Wait. HTML 5 is a work performed over a decade, which we are only in the middle. We are certainly no delaying anything here. HTML 6 would be another decade of work. What we don't do now, we won't do for 15 years. We don't have a consensus yet, and that is why I joined the debate. Because I feel my opinion is important, although I feel people much more knowledgeable then I am are going to show how wrong I am :P I feel we are close to a 'partial' consensus, to reuse your term. Here is what I feel most people agree on: Use ISO 8601 with the following provisions: - Allow all four digit years, positive and negative - Allow lower granularity dates: 2009-03-14, 2009-03, 2009 - Allow ranges: 2009-03-01/2009-03-14 - Allow only extended format: 2009-03-14 (rather than 20090314) which will help with simplification and future extensions I'm not sure many have arguments against any of the above. Sorry if I missed anything. I don't claim we have actually reached a consensus. Here are items which we are debating over, with my opinion on these: - Allow year or not? Actually I don't see why it's important. I think it should be allowed. Historians deny the existence of year 0, but astronomers use it. What if year 0 is accepted as a valid date for the purpose of HTML, and then not used by authors? It would become available for those authors who use year 0, and ignored by others. Whats the implication? HTML parser does not perform math over dates, it merely displays information based on what an author instructed. Here his the only debate I see over this: ISO 8601:2000 and above suggest that year be used and be considered year 1 BC, and then -0001 is 2 BC, etc. Most, I believe, will want year -0004 = 4BC (and this is what I'd suggest). - Allow 5 or more digit dates? Like year 10,000 or year 100,000 BC? It's feasible: 1-01-01, or -10-01-01 (which is more likely to be used with lower granularity I guess). I don't think this is going to give parsers a greater complication. - Allow non Gregorian calendars? There are actually two debates on this issue. One is whether to allow other calendars as the datetime attribute values, the other is to always have the datetime attribute value specified as a Gregorian date while adding a new attribute which would indicate what calendar is used for the content. I would personally go against the use of any non Gregorian calendar at all, since I do believe the use cases are too few. However if it is considered that the use of non Gregorian is to be supported, I would go with the later solution (allow non Gregorian as the content only, and have the datetime attribute always defined as a Gregorian date), since that would not put much complication on the parser (which does not have any calculation/conversion to perform, leaving that to the author). The new attribute would then be used by the browser to tell what calendar is used, but the datetime attribute is still used to indicate to the user the Gregorian equivalent. I do see too many problems with accepting non Gregorian as the value of the datetime attribute: too many calendars are way incompatible (try to represent a Mayan Long Count calendar),... Those are pretty much the current debates, as I see it. Please feel free to add anything I missed. My current recommandation would be that we try to come to an agreement on current debates, rather than come up with more debates. We have already determined that none of use are calendar experts (and I have already proven I'm far from one), but I think we can come up with something that would give enough flexibility to anyone without giving much restrictions. One idea that comes to mind (if ever allowed by the current HTML draft, I am no sure) could be to force parsers into a minimum set of rules (i.e. accept at least 4 digits for years) while giving them the freedom to decide whether or not to implement extended features (accept any number of digits for years). Most popular browsers would probably implement everything, while smaller ones (those with more restrictions, such as cell phone browsers) could go with the minumem (and still cover 95% of use cases) while leaving the extended, more demanding features (although I don't feel my long year example is a good one to represent a 'demanding feature').
Re: [whatwg] Link.onload
On Sat, Mar 14, 2009 at 4:46 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
I proposed a solution to a similar problem not too long ago.
script depends=[idref] .../script
For me to implement my own depends lazy loader without any hacks the
only thing missing is that link onload callback.
Given the following example, with depends, if a, b, or c are links,
how would you set their title, rel, href, media and other
attributes? If a, b, or c is a script, how would you set the id or
type of that script?
script depends=a b c/script
Example:-
link onload=loadPlayer() ...
This is sort of what I am doing, but missing a couple steps:
This is basic usage:
[The following examples are using Mootools syntax]
MyApp.extend({
Calendar: function(args){ // This entire function is replaced when
calendear.js is loaded.
$require({
dir: MyApp.pluginDirectory + 'Calendar/',
cssFirst: true,
css: [{url: 'css/calandar.css', media: 'all'}, {url:
'css/calandarPrint.css', media: 'print'}],
images: ['images/bg.jpg', 'images/dayHover.png'],
javascript: [{url: 'js/calandar.js', id:
'calendarScript'}],
onProgress: function(counter, index, assetsToLoad){
console.log(counter + ' of ' + assetsToLoad + '
required files loaded.');
},
onload: function(){
console.log('All required files loaded.');
new MyApp.Calendar(args);
}.bind(this)
});
},
Chat: function(){ // This entire function is replaced when chat.js is
loaded.
$require({
// ...
onload: function(){
new MyApp.Chat();
}
});
}
});
There is a Core.js file that sets up the MyApp namespace. There are
plugins called MyApp.Calendar, MyApp.Chat, and so forth. If the user
does something that fires new MyApp.Calendar(args), all of the
Calendar assets are loaded, CSS first. The JavaScript in Calendar.js
overwrites the MyApp.Calendar lazy loading function with the Class
method for the Calendar. When the $require onload is fired it then
runs new MyApp.Calendar(args) again, this time creating a new Calendar
instance.
calendar.js:
MyApp.Calendar = new Class({
Implements: [Events, Options],
options: {
//
},
initialize: function(options){
//
}
)};
The MyApp.Calendar lazy loader is now completely gone and any future
calls to new MyApp.Calendar() immediately creates a new Calendar
instance.
So instead of link onload=loadPlayer() ...
it would be more like:
link onload=checkLoadProgress() ...
loadPlayer() would not happen until all the required files are loaded.
checkLoadProgress() keeps a tally of the progress.
The CSS is created something like this:
css: function(directory, source, properties){
properties = $merge({
rel: 'stylesheet',
media: 'screen',
type: 'text/css'
}, properties);
return new Element('link', {
rel: properties.rel,
media: properties.media,
type: properties.type,
href: directory + source,
onload: function(){ checkLoadProgress(); }
}).inject(document.head);
}
I think a native lazy loader such as something along the lines of your
depends is a great idea. It would obviously have to be much simpler
than what I am doing, sort of in the same vein that you can use the
HTML 5 meter or create your own and have more control. I think your
idea would probably need more fleshing out though and would require a
great deal more from the user agents than what I am requesting, which
again is just an onload callback from the link element.
On a side note, I can actually attach a functioning onload event to a
link element in Internet Explorer. Firefox, Safari, and Chrome ignore
my attempt, and Opera will fire the onload event but not update the
style of the page. Opera gives the most curious result. I didn't
actually check the DOM to see if Opera appended the stylesheet or not.
It may be that it just short circuits and fires the onload event.
return new Element('link', {
rel: properties.rel,
media: properties.media,
type: properties.type,
href: directory + source
}).addEvent('load', function(){
alert('Hello World');
}).inject(document.head);
Cheers,
G.
Re: [whatwg] Link.onload
On Sat, Mar 14, 2009 at 5:24 PM, Greg Houston gregory.hous...@gmail.com wrote:
On Sat, Mar 14, 2009 at 4:46 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
I proposed a solution to a similar problem not too long ago.
script depends=[idref] .../script
For me to implement my own depends lazy loader without any hacks the
only thing missing is that link onload callback.
Given the following example, with depends, if a, b, or c are links,
how would you set their title, rel, href, media and other
attributes? If a, b, or c is a script, how would you set the id or
type of that script?
The proposal is to add the id in the markup, using the ID existing attribute:-
link rel=stylesheet href=a.css title=a styles media=screen id=a
- and -
script id=b src=b.js/script
script depends=a b c/script
Waits for a and b to load and:-
script depends=/script
waits for nothing.
Example:-
link onload=loadPlayer() ...
This is sort of what I am doing, but missing a couple steps:
This is basic usage:
[The following examples are using Mootools syntax]
I understand you are using Mootools. The syntax is ECMA-compliant (in
this case).
That, and the example seems to add more complexity than necessary to
provide sufficient explanation (IMO, a simpler example is preferable).
The method chaining and Mootools' misguided augmentation of Host
object (document.head here) makes the code less clear. The reader
should not be forced to understand details about Mootools to
understand your example.
[snip code]
I think a native lazy loader such as something along the lines of your
depends is a great idea. It would obviously have to be much simpler
than what I am doing, sort of in the same vein that you can use the
HTML 5 meter or create your own and have more control. I think your
idea would probably need more fleshing out though and would require a
great deal more from the user agents than what I am requesting, which
again is just an onload callback from the link element.
It would require more support from implementors than what I have
gotten, that is for sure.
Link.onload is simpler for implementors. We have at least two browsers
(opera, IE) that support that already.
OTOH, depends= offers declarative style for automatic resolution of
dependencies. Though more complex than link onload, depends= would
seem to be cleanly implementable (though slightly more complex) via
internal events. If depends= were implemented, what would be the
use-case for link onload?
On a side note, I can actually attach a functioning onload event to a
link element in Internet Explorer. Firefox, Safari, and Chrome ignore
my attempt, and Opera will fire the onload event but not update the
style of the page. Opera gives the most curious result. I didn't
You got a result (in Opera, using Mootools). It should be explainable.
Possibly you have invalid css syntax that opera rejects (check your
error console).
actually check the DOM to see if Opera appended the stylesheet or not.
It may be that it just short circuits and fires the onload event.
Opera will fire the onload event when the stylesheet load fails.
[snip example]
Mootools provides a layer of abstration that gets in the way of making
your case. It seems more prudent to use the actual syntax you desire,
sans the Mootools abstraction layer.
!DOCTYPE HTML
html lang=en
head
titlelink onload/title
/head
body
script type=text/javascript
function addStyleSheet() {
var l = document.createElement(link);
l.onload = linkLoaded;
l.type = text/css;
l.rel = stylesheet;
l.href = l.css;
document.getElementsByTagName('head')[0].appendChild(l);
}
function linkLoaded() {
document.getElementById('m').firstChild.data = link onload fired.;
}
/script
button onclick=addStyleSheet()addStyleSheet()/button
pre id='m'link not added/pre
/body
/html
l.css:
body {
background: #3f3;
}
Result:
All browsers updated the document.
Opera, IE7:
link onload fired.
Mozilla rv:1.9.1b3pre, Webkit 3.1.2, Chrome:
link not added
Cheers,
G.
Garrett
Re: [whatwg] Link.onload
On Sat, Mar 14, 2009 at 1:48 PM, Greg Houston gregory.hous...@gmail.com wrote: This is a request for the link element to be given an onload attribute. Often when lazy loading a plugin into an web app it is necessary for the plugin's stylesheets to be applied before the plugin's JavaScript is downloaded. Without the link element having an onload event there is not really a straightforward way of doing this. This sounds like a good idea to me. Seems useful for dynamically added stylesheets too, and possibly for stylesheets where the href attribute is dynamically changed. Same thing goes for the style element since an inline stylesheet can have @import rules. Garrett: Whatever we decide when it comes to the defer attribute, it is always useful to have scripting APIs as well. There is just no way that you can cover all use cases declaratively, so it's useful to be able to fall back to using scripting for cases not covered. / Jonas
[whatwg] Canvas ImageData with HSL values.
Hi, Just like canvas.getImageData() and canvas.putImageData() Why canvas.getImageHSLData() and canvas.putImageHSLData() API are provide? Is it something discussed and planned not have? Cheers Biju
[whatwg] Canvas ImageData with HSL values.
oops... Why canvas.getImageHSLData() and canvas.putImageHSLData() API are NOT provide? Is it something discussed and planned not TO have?
Re: [whatwg] Link.onload
On Sat, Mar 14, 2009 at 6:54 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Mar 14, 2009 at 1:48 PM, Greg Houston gregory.hous...@gmail.com wrote: [...] Garrett: Whatever we decide when it comes to the defer attribute, it is always useful to have scripting APIs as well. There is just no way that you can cover all use cases declaratively, so it's useful to be able to fall back to using scripting for cases not covered. What other cases do you have? Garrett
Re: [whatwg] time
On Sat, Mar 14, 2009 at 9:36 PM, Smylers smyl...@stripey.com wrote: Tom Duhamel writes: - Allow only extended format: 2009-03-14 (rather than 20090314) which will help with simplification and future extensions Note that the draft already requires hyphens, so this wouldn't be a change: http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#parse-a-date-component Smylers Indeed, but others have suggested a change, so (for reasons given in my other post) I am suggesting that we keep the mandatory hyphens. Also, I am feeling right now that our current debate have already voided the existing draft and that we are actually slowly rewriting the whole time section :)
