Re: [whatwg] Link.onload
On Sat, Mar 14, 2009 at 10:21 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
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?
A web application, such as GMail, wanting to show a dialog box to the
user asking the user to enter some information. In order to do this it
needs to first load a stylesheet to properly style the dialog box. The
application would do this by inserting a link rel=stylesheet
href=dialog.css into the head of the document. It would then want
to know when the stylesheet has loaded so that it can display the
dialog box.
There's a few reasons depends is not a good solution for this scenario.
First off, in order to use it the page would have had to not only
insert the link element, but also ad a script
depends=dialogStylesheetIddisplayDialog()/script.
Second, it gets even worse if a specific dialog is to be displayed,
since then the script has to not just generate the above script
element, but also dynamically generate the javascript code inside it,
for example script depends=dialogStylesheetIddisplayDialog(Dialog
Title)/script. This is particularly bad if you'd want to pass a
reference to an object to the displayDialog function. The only way I
can think of for doing that would be using global variables, and
serializing the variable name of the global variable into the script.
This would be terrible software design.
Third, if something like Content Security Policy [1] gets adopted in
browsers it would be impossible to use an inline script. You would
instead have to host a separate file that contains the call to
displayDialog() call. This would get even worse when combined with the
ability to show a specific dialog as described above.
It seems much simpler to be able to do:
link = document.createElement('link');
link.rel = stylesheet;
link.href = dialog.css;
link.onload = function() {
displayDialog(Dialog Title, someObject);
}
document.getElementsByTagName('head')[0].appendChild(link);
/ Jonas
[1] http://people.mozilla.org/~bsterne/content-security-policy/
Re: [whatwg] Link.onload
Greg Houston wrote: This is a request for the link element to be given an onload attribute. And presumably a readyState property.
Re: [whatwg] Link.onload
Jonas Sicking wrote on 15 mars 2009 02:55: 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. 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. I also think this is a good thing that should make it into the spec independently of the depends ideas. It is already specified that script elements fire (on)load or (on)error events (see end of 4.3.1[0]) to signal whether loading the external file was successful. Wouldn't it be nice and symmetric if analogous behaviour was specified for all loading of external resources? HTML5 already specifies onload/onerror event handlers for all elements so the actual handlers are already in place on link elements (and others). What remains is to define that link should actually fire these events. Best regards Mike Wilson
Re: [whatwg] Link.onload
Sean Hogan wrote: This is a request for the link element to be given an onload attribute. And presumably a readyState property. At least in Gecko, you can already detect whether the sheet is done loading: if you try to get its cssRules and that throws INVALID_ACCESS_ERR, then it's still loading. (If it throws DOM_SECURITY_ERR then you're not allowed to read the style data; that's why you have to check for the exact type of exception thrown. Though really, if you're loading style sheets cross-site you're in for a world of hurt unless you control both sites.) -Boris
Re: [whatwg] Link.onload
Jonas Sicking wrote: 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. Indeed, and there are some things that need specifying around this. See https://bugzilla.mozilla.org/show_bug.cgi?id=185236#c12 and https://bugzilla.mozilla.org/show_bug.cgi?id=185236#c15 for example. Note that image onload events do fire asynchronously in Gecko even if the data is synchronously available, so I have no problem with defining that all the load events, including for inline style with no imports, fire async. Note that inline scripts do not fire load events, by the way. Inline sheets with @import really should, though, no matter what happens for inline sheets without @import. -Boris
Re: [whatwg] Link.onload
Here is how to obtain the functionality of a deferred style sheet for a
run-time dialogue box: the semantics of the depends attribute must be
changed so that it causes all script code *except function definitions* to
wait for the style sheet to load (and perhaps cause it to load as well);
whereas all functions defined in such a script would be tagged with the
dependency of the script element and wait for the dependents when *called*.
Thus, the script handling the dialogue box can be static, and the dependents
would be loaded only when one of the functions defined there is invoked.
style id=dbSheeet /style
script depends=dbSheet
/* does not wait for dbSheet */
function displayDialogue(title, args) { } /script
button
onClick=displayDialogue(Peekaboo, this)
/* waits for dbSheet and passes a reference to an object */
/button
This would work even if dbSheet is dynamic.
The downside of this solution is that the instruction
window .displayDialogue = function displayDialogue(title, args) {}
would not be equivalent to a plain definition of function displayDialogue.
This difference, however, would manifest itself only on pages that would be
broken anyway.
Chris
Re: [whatwg] Link.onload
On Sun, Mar 15, 2009 at 12:07 AM, Jonas Sicking jo...@sicking.cc wrote:
On Sat, Mar 14, 2009 at 10:21 PM, Garrett Smith dhtmlkitc...@gmail.com
wrote:
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:
[...]
What other cases do you have?
A web application, such as GMail, wanting to show a dialog box to the
user asking the user to enter some information. In order to do this it
needs to first load a stylesheet to properly style the dialog box. The
application would do this by inserting a link rel=stylesheet
href=dialog.css into the head of the document. It would then want
to know when the stylesheet has loaded so that it can display the
dialog box.
(To avoid FOUC on the dialog box).
That is a case where it would seem useful to have a scope=[selector]
on the link element. (wildly off-topic, I know).
There's a few reasons depends is not a good solution for this scenario.
First off, in order to use it the page would have had to not only
insert the link element, but also ad a script
depends=dialogStylesheetIddisplayDialog()/script.
Provided that no script was downloaded, then yes, onload would be easier.
If the dialog needed a script that did not exist, it might be useful
to use depends.
[...]
Third, if something like Content Security Policy [1] gets adopted in
browsers it would be impossible to use an inline script. You would
instead have to host a separate file that contains the call to
displayDialog() call. This would get even worse when combined with the
ability to show a specific dialog as described above.
Adding an inline script is painful.
It seems much simpler to be able to do:
link = document.createElement('link');
link.rel = stylesheet;
link.href = dialog.css;
link.onload = function() {
 displayDialog(Dialog Title, someObject);
}
Why not implement EventTarget on link? For example:
link.addEventListener('load', displayDialog, true);
What happens if dialog.css has:
@import panel.css
/* other rules */
?
What do IE and Opera do?
document.getElementsByTagName('head')[0].appendChild(link);
/ Jonas
[1] http://people.mozilla.org/~bsterne/content-security-policy/
Will look into that.
Garrett
Re: [whatwg] Link.onload
Garrett Smith wrote:
On Sun, Mar 15, 2009 at 12:07 AM, Jonas Sicking jo...@sicking.cc wrote:
link.onload = function() {
displayDialog(Dialog Title, someObject);
}
Why not implement EventTarget on link? For example:
link.addEventListener('load', displayDialog, true);
It's the same thing. link already implements EventTarget; the only
question is what events are dispatched, not how one listens to them.
What happens if dialog.css has:
@import panel.css
/* other rules */
Then the load event for the link would not fire until the panel.css
file has finished loading, I would hope!
-Boris
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Sat, Mar 14, 2009 at 3:11 PM, Anne van Kesteren ann...@opera.com wrote: 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/ Thank you Anne, but I think this has to be dealt with primarily inside the HTML5 spec. The Access Control spec is already pretty clear on how things are supposed to work on the server and from the server to the client and it's probably mostly enough to say that Image and Video elements in addition to cross-origin linking also allow for cross-origin use as described in Cross-Origin Resource Sharing. Me and Chris actually assumed it would work that way until we tried it. The main question for me (aside from the question if image/video/canvas elements should retain all necessary information to check for valid origins that are allowed access again or just be marked standard/public) is where to put it in the spec. It's an issue that applies to pretty much anything that allows access to the raw data (which is just canvas now, but nobody knows what the future will bring) and to make matters worse its nature not only requires changes to canvas itself, but also to the elements that are drawable, like img or video. So to me it would make the most sense to put this as far away as possible from Canvas and make it more into a generic item how DOM elements are supposed to hold data about cross origin headers. Then the canvas description would need virtually no changed beyond obeys cross-origin rules for pixel access.
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Sun, 15 Mar 2009 20:45:17 +0100, Hans Schmucker hansschmuc...@gmail.com wrote: Thank you Anne, but I think this has to be dealt with primarily inside the HTML5 spec. Yes, hence me using the word aside... Anyway, ... The Access Control spec is already pretty clear on how things are supposed to work on the server and from the server to the client and it's probably mostly enough to say that Image and Video elements in addition to cross-origin linking also allow for cross-origin use as described in Cross-Origin Resource Sharing. No, currently you actually have to state which algorithm you use in CORS and how. Otherwise CORS does not apply (at least not from a specification standpoint). Me and Chris actually assumed it would work that way until we tried it. The main question for me (aside from the question if image/video/canvas elements should retain all necessary information to check for valid origins that are allowed access again or just be marked standard/public) is where to put it in the spec. It's an issue that applies to pretty much anything that allows access to the raw data (which is just canvas now, but nobody knows what the future will bring) and to make matters worse its nature not only requires changes to canvas itself, but also to the elements that are drawable, like img or video. So to me it would make the most sense to put this as far away as possible from Canvas and make it more into a generic item how DOM elements are supposed to hold data about cross origin headers. Then the canvas description would need virtually no changed beyond obeys cross-origin rules for pixel access. That does sound nice yes. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
Thank you Anne, but I think this has to be dealt with primarily inside the HTML5 spec. Yes, hence me using the word aside... Sorry, I didn't mean to make it sound like an attack, I really just meant to say that this (for me) belongs more into HTML5, which deals primarily with the user agent, than into the CORS spec, which more or less focuses on the server side and the communication between server and client. No, currently you actually have to state which algorithm you use in CORS and how. Otherwise CORS does not apply (at least not from a specification standpoint). Yes, we pretty much assumed that HTML5 had already adapted to CORS. It was an assumption, but it's an assumption many people are bound to make as other HTML5 features depend on CORS. It's an issue that applies to pretty much anything that allows access to the raw data (which is just canvas now, but nobody knows what the future will bring) and to make matters worse its nature not only requires changes to canvas itself, but also to the elements that are drawable, like img or video. So to me it would make the most sense to put this as far away as possible from Canvas and make it more into a generic item how DOM elements are supposed to hold data about cross origin headers. Then the canvas description would need virtually no changed beyond obeys cross-origin rules for pixel access. That does sound nice yes. So, where would you put it? The problem for me is that there's no logical grouping of elements that load offsite resources (like img, script, link, video, ...) where one could add the necessary attributes. All off them descend directly from HTMLElement. So there would be two routes: Either making all elements that load offsite data descend from a common HTMLRemotelyFedElement interface (which seems like the right way to do things, but it's also IMHO completely unrealistic as it would either require reworking the DOM top to bottom or including ugly hacks) or adding the necessary attributes to HTMLElement itself... which seems like asking for trouble. Then there's the (IMHO) despicable way of just writing a random chapter about it and referencing that chapter in the spec wherever appropriate. Feels very, very wrong, but I don't think we have much choice here.
[whatwg] Fwd: time
Re posted because accidentally posted offline (well even I can do mistakes...) -- Forwarded message -- From: Tom Duhamel tom420.duha...@gmail.com Date: Sun, Mar 15, 2009 at 1:50 AM Subject: Re: [whatwg] time To: Robert J Burns r...@robburns.com (I saddly stripped down this very long post to only the parts relevant to my replies, but really if you are currently reading this from an archive 10 years from now find and read the original post, Rob really has a lot to say and I'm looking forward to read more of his ideas and opinions) On Sat, Mar 14, 2009 at 8:01 PM, Robert J Burns r...@robburns.com wrote: Use ISO 8601 with the following provisions: - Allow all four digit years, positive and negative We cannot agree on this unless we go beyond ISO 8601 and define how those representations map to BC/BCE while also keeping consistent leap year rules in place (note this is an area that does require some calendar expertise). - Allow lower granularity dates: 2009-03-14, 2009-03, 2009 Agreed - Allow ranges: 2009-03-01/2009-03-14 Agreed - Allow only extended format: 2009-03-14 (rather than 20090314) which will help with simplification and future extensions This may be more controversial. I think we could allow the omission of hyphens for years of four digits. Others have contended that we might also allow the omission of hyphens always if we omit support for ordinal dates (e.g., -DDD). I don't see a use case for -DDD, and haven't seen anyone propose one yet. I really believe that would be of no use for us. However, see my comment below about why I think extended format should be mandatory. 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. I would add that keyword support for alternate calendars is an important part of keeping options open for HTML6 and also to help reduce authoring errors. 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. It is important because we want dates before 0001-01-01 to be encoded unambiguously. If we don't address such issues we need to limit ourselves to 0001-01-01 and later. I think it should be allowed. Historians deny the existence of year 0, but astronomers use it. It isn't a matter of denial or belief. This is an issue of precisely defining a Gregorian calendar to apply to the past: a calendar which was defined in 1582 with only the future in mind. ISO 8601 could have stepped in an further defined the Gregorian calendar but it punted. So no one is denying the year exists. The question is whether the Gregorian calendar should call the year before 1 AD, year 0. Could you provide some reference to astronomy's used of a year 0 between 1 AD and 1 BC (for example the Starry Night astronomical software I use does not have a year 0 between 1 AD and 1 BC. I often see such claims made, but I've never seen such definition/use of a specialized Gregorian calendar). Again I do not claim any expertise here, but I was always told astronomers use the year 0 because it makes calculations easier. They don't use BC or AD notation, but instead use positive and negative signs (+2009, -54...). They do decal from historic dates. That is, what they call year -1 is what historians call 2BC. For a starter: http://en.wikipedia.org/wiki/Year_0 (Before someone debates over Wikipedia, I have never considered Wikipedia as THE reference, but always thought it was a good starting point, from which one serious enough can go an do more researches.) 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? If I understand current proleptic Gregorian calendar use correctly (such as that used by astronomers) the implication is that HTML will not match the other uses of that calendar. ISO 8601 has unambiguous leap year rules which are to be applied to 000 and negative years as well. If we accept year 0, then -0001 would mean 2 BC. That's fine, but we need to make it clear to authors and there's some concern authors would make the mistake of thinking -0001 was instead 1 BC. HTML parser does not perform math over dates, it merely displays information based on what an author instructed. However, if the UA displays the information in a non-machine readable form, how does it make that conversion for presentation purposes. Does -01-01 get displayed as 1 January 1 BC? Or as 1 January 00? Since I always thought of HTML as a method of enclosing content for the purpose of display only, my thinking was that it was not important whether or not year 0 existed or not. I thought that an author would put -54-03-17 and the user agent would show March 17th, 54 BC. Then if one decides he
Re: [whatwg] time (apparantly o)
[I left Robert's replies in, even those I didn't have anything to reply to, because Robert originally sent the message only to me (off-list).] On Sun, Mar 15, 2009 at 4:36 PM, Robert J Burns r...@robburns.com wrote: - Allow only extended format: 2009-03-14 (rather than 20090314) which will help with simplification and future extensions This may be more controversial. I think we could allow the omission of hyphens for years of four digits. Others have contended that we might also allow the omission of hyphens always if we omit support for ordinal dates (e.g., -DDD). I don't see a use case for -DDD, and haven't seen anyone propose one yet. I really believe that would be of no use for us. However, see my comment below about why I think extended format should be mandatory. Neither do I really. I was simply raising the issue because someone else said they wanted hyphens to be optional (I don't recall which message or who composed it at the moment). Again I do not claim any expertise here, but I was always told astronomers use the year 0 because it makes calculations easier. They don't use BC or AD notation, but instead use positive and negative signs (+2009, -54...). They do decal from historic dates. That is, what they call year -1 is what historians call 2BC. OK, I see what you mean. That's a fine approach as long as we're clear how the under the hood encoding of dates maps to the human-consumable dates which will be expressed in terms of AD and BC (or CE and BCE). The only concern I have with that approach is that I think authors will often make errors: for example, using -0007 to designate 7 BC instead of 8 BC. That is the issue I see with this now. This approach ( = 1BC, 0001 = 2BC) is the one that looks, but yes I foresee frequent among authors. If we do allow year but do not introduce a decal (0001 = 1AD, = nothing, -0001 = 1BC) we introduce a complication for programs which are going to extract the data for calculations. If we forbid year 0, then we are restricting some authors from using, and we still introduce the problem from the previous sentence. For a starter: http://en.wikipedia.org/wiki/Year_0 (Before someone debates over Wikipedia, I have never considered Wikipedia as THE reference, but always thought it was a good starting point, from which one serious enough can go an do more researches.) 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? If I understand current proleptic Gregorian calendar use correctly (such as that used by astronomers) the implication is that HTML will not match the other uses of that calendar. ISO 8601 has unambiguous leap year rules which are to be applied to 000 and negative years as well. If we accept year 0, then -0001 would mean 2 BC. That's fine, but we need to make it clear to authors and there's some concern authors would make the mistake of thinking -0001 was instead 1 BC. HTML parser does not perform math over dates, it merely displays information based on what an author instructed. However, if the UA displays the information in a non-machine readable form, how does it make that conversion for presentation purposes. Does -01-01 get displayed as 1 January 1 BC? Or as 1 January 00? Since I always thought of HTML as a method of enclosing content for the purpose of display only, my thinking was that it was not important whether or not year 0 existed or not. I thought that an author would put -54-03-17 and the user agent would show March 17th, 54 BC. Then if one decides he likes the year 0, he would put -12-25 and the user agent would print December 25th, 0. The browser would just print what we told him to print, without an actual understanding of what it means. But after reading your comments above and below (in particular the place where you mention the possible use of a HTML file for something other than displaying to a reader), and checking a few more pages on the web, I now understand it does in fact matter whether or not a year 0 is used. Yeah, the main purpose of the 'datetime' attribute and the ISO 8601-like encoding of dates is for extraction and use elsewhere. The contents of the 'time' element are simply displayed. I would like to see the 'datetime' also used for localized dates regardless, using CSS or another presentational mechanism. However, obviously that's not a part of the HTML5 project (at least not currently). However, there's really no reason to encode the dates in the 'datetime' attribute unless it can be extracted and used in a precise machine-consumable form. Supplementing the date with a keyword prefix or suffix permits even more precise date representation. Here is how I would like to see user agents implement the time element: This software was released on
Re: [whatwg] Fwd: time
On Sun, Mar 15, 2009 at 6:30 PM, Tom Duhamel tom420.duha...@gmail.com wrote: What about those 'other calendars of concern'? Are they reasonably compatible with Gregorian, or so much different that my example of the Mayan long count becomes a good one? I know nothing about those, but I fear it's the later. You're correct. For instance, the Jewish calendar has 12 months of 29 or 30 days, except that sometimes it has 13 months, and it only syncs up with the Julian calendar every 19 years, except sometimes when it's off by a day, and the algorithm for calculating whether months have 29 or 30 days depends on when the new moon will hypothetically first be visible in Jerusalem according to an astronomical model that was finalized early in the first millennium CE, plus also on when certain holidays would fall out in the coming year. I don't know much about the other calendars, but they're similarly unrelated to the Gregorian calendar, for sure. Apparently, some variants of the Islamic calendar aren't even planned out in advance -- you literally have no idea whether the current month is going to be 29 days or 30 until it's actually announced based on observation of the new moon, and different Muslim countries decide it differently. There are variants that allow the start of Islamic months to be calculated in advance, but there seem to be several different ones.
