Re: [whatwg]
On Mon, Mar 16, 2009 at 5:05 PM, Robert J Burns wrote: > Hi Tom, > > I think those examples and suggestions all look good. I have one correction > and one other example. > > First the correction > > A date is printed >> on the statue >> Printed on the page: "A date is printed on the statue" >> Tool tip shows: "12-11-10-09-08 (Mayan Long Count)" >> In this example, my user agent does not understand the date, and simply >> display in a non converted way >> > > > Here I think the tool tip has to be: > > Tool tip shows: "12-11-10-09-08 (Mayan)" >> > > directly providing the keyword without a localized natural language form > (as in your example). That is for unsupported calendars the UA would simply > have to present the raw attribute values in these cases. For supported > calendars the dates can be formatted and things like months, for example, > can be presented in a localized manner (January for English instead of 01, > Janvier for French, etc.). I can only agree with you. As the user agent does not understand calendar "Mayan" it obviously cannot do anything better than just reused the value provided. Let's add that on our proposal. I am not an expert in calendars, just someone who happens to have some interest in Native American history, thus my *basic* knowledge of the Mayan Long Count calendar. Assuming that I always saw the name exactly as "Mayan Long Count calendar" I guess the correct format would be: which would show correctly "12-12-12-12-12 (Mayan Long Count)" in the tooltip. Of course, this was only one possible way a user agent could display the data, I didn't propose that all user agents should display the data the way I did. > > > Another worthwhile example (one you suggest, but don't provide > specifically) would be to include something like > > This occurred on on > Ellis Island. > > where supporting UAs actually include the localized, formatted date > according to the user defaults. > > This occurred on March 14, 1882 on Ellis Island. > > A tool tip could still show shows: March 14, 1882 (Gregorian). Since Gregorian is the default calendar, and 99% of all dates on the web will be Gregorian, I don't expect that browsers will explicitly show "Gregorian", but rather only show what calendar is in use when the calendar in use is not Gregorian. However I think you wanted to show an example where no content is present, which obviously I forgot. Your example shows exactly what I would expect a user agent to do, although I would expect that at least some of them are going to try and avoid situation where the tooltip would not give any information which are not already displayed on screen (assuming they don't explicitly indicate "Gregorian"), but exactly how user agents decide on this kind of details is to be discussed on the Mozilla mailing list in a few months from now, isn't it? :) > > > Otherwise I'm in complete agreement with the remainder of your message. > > If nobody object, I could repost a similar message (with a compiled list of proposal updated with our latest agreements and relevant examples) every other day, so eventually we can reach a consensus.
Re: [whatwg]
On Mon, Mar 16, 2009 at 5:03 PM, Smylers wrote: > > Hi Tom. I'd like you to clarify an aspect of your proposal: Please don't see this as a proposal, but rather as a compilation of the things people seem to have agreed on so far. My intention was to compile in one post what has been discussed in several posts lately. I thought it would be easier to discuss the topic as a whole, but of course we will discuss each items separately where we do not agree. > > > > 2009-03-16 > > Printing directly on the page, no tool tip: "March 16, 2009" > > Because the author wrote a date in ISO 8601 format, a browser should > rewrite it the user's local date format, such that it is > indistinguishable from if the author had typed it that way in the first > place? > > (Obviously pre-HTML-5 browsers will still display the raw 2009-03-16.) > > Suppose I'm a UK user who happens to've configured my computer's date > format to DD/MM/ (which is common over here) and I see an American > conference's website American give its date as 04/07/2009. I know that > the USA date order is different from the UK's, so I'm used to having to > remember to read that as April 7th. You're suggesting that there should > be two possibilities I have to take into account: > > * The author literally wrote "04/07/2009", and the conference is on April > 7th. > > * The author literally wrote 2009-07-04, my browser > converted that to my local format and displayed it as 04/07/2009, and > the conference is on July 4th > > And that as a reader I can't tell which of these it is, without viewing > the document's source? (And even to spot that there is an ambiguity > I've got to be aware that my browser 'sometimes' changes dates, that it > depends on my computer's configuration, and what config I picked.) > > Does the same apply to times? Would they also be converted to the > user's local timezone? > > > 16 mars 2009 > > The user agent could, but is not required to, make an effort to > > interpret the date and do whatever it likes with it. However, if the > > date provided cannot be interpreted as ISO 8601 it could simply print > > the content as is without any change. In this example, if the user > > agent is able to understand this French date, the tool tip could be > > "March 16, 2009" > > If a browser interprets a date in a different format, the localized > version goes in the tooltip but the user sees exactly what the author > typed? > > That is, which version (author-written or localized) the browser shows > in the page depends on which format the author used? > > Smylers > I totally agree with you. That is something I haven't foreseen. I would go with your proposal. 2009-03-15 "2009-03-15" is displayed unaltered on the page, and the tooltip shows a representation as set in my preferences, such as "March 15, 2009". If the content cannot be interpreted by the user agent, then no tooltip is displayed at all. (Of course a tooltip is a suggested mechanism, a user agent could use another method.)
[whatwg] postMessage object cloning
So I've been looking at the object cloning rules for postMessage and
have noticed a couple of things that seem less than ideal. The first
is that it fails to specify the behaviour of cloning for prototype
chains. While this is definitely an issue specific to JS rather than
binding languages as a whole, JS is the language of the web, so if I
have an object, a la:
myObject = {};
myObject.__proto__ = {foo: "bar"}
Do we clone the prototype object? Do we flatten the prototype list?
or do we drop the prototype?
The other issue i bumped into is behaviour of ImageData/
CanvasPixelArray -- currently (per spec) these will not be cloned, and
instead have to be marshalled into and out of arrays by the
developer. This seems less than ideal -- could the internal
structuring algorithm be extended to include these types. The
alternative is to allow CPA, etc to be automatically marshalled to
arrays, which (while not ideal) would at least get processing correct
in one direction. Unfortunately the developer would still have to
manually marshall data coming from the worker, hence my preference for
allowing ImageData and CPA to be cloned.
--Oliver
Re: [whatwg]
Assuming that Gregorian dates are displayed in a tool tip, what happens when the user hovers over a time element that has both @datetime and @title specified? Chris
Re: [whatwg]
Tom Duhamel writes: > It seems that pretty much everyone agrees on this: Hi Tom. I'd like you to clarify an aspect of your proposal: > 2009-03-16 > Printing directly on the page, no tool tip: "March 16, 2009" Because the author wrote a date in ISO 8601 format, a browser should rewrite it the user's local date format, such that it is indistinguishable from if the author had typed it that way in the first place? (Obviously pre-HTML-5 browsers will still display the raw 2009-03-16.) Suppose I'm a UK user who happens to've configured my computer's date format to DD/MM/ (which is common over here) and I see an American conference's website American give its date as 04/07/2009. I know that the USA date order is different from the UK's, so I'm used to having to remember to read that as April 7th. You're suggesting that there should be two possibilities I have to take into account: * The author literally wrote "04/07/2009", and the conference is on April 7th. * The author literally wrote 2009-07-04, my browser converted that to my local format and displayed it as 04/07/2009, and the conference is on July 4th And that as a reader I can't tell which of these it is, without viewing the document's source? (And even to spot that there is an ambiguity I've got to be aware that my browser 'sometimes' changes dates, that it depends on my computer's configuration, and what config I picked.) Does the same apply to times? Would they also be converted to the user's local timezone? > 16 mars 2009 > The user agent could, but is not required to, make an effort to > interpret the date and do whatever it likes with it. However, if the > date provided cannot be interpreted as ISO 8601 it could simply print > the content as is without any change. In this example, if the user > agent is able to understand this French date, the tool tip could be > "March 16, 2009" If a browser interprets a date in a different format, the localized version goes in the tooltip but the user sees exactly what the author typed? That is, which version (author-written or localized) the browser shows in the page depends on which format the author used? Smylers
Re: [whatwg]
On 16 Mar 2009, at 20:10, Tom Duhamel wrote:
It seems that pretty much everyone agrees on this:
- Allow the use of an alternate calendar, but only Gregorian is
required to be understood by user agents
- We only require the user agent to display dates; they are free to
do more if they like (conversion, ...) but are not required to.
- Calendar is specified in a new attribute ('calendar' or something
similar) and the value of 'datetime' attibute is specified in the
calendar specified by that new attribute
- If 'datetime' attribute is missing, try to interpret the content
as an ISO date. User agent could print the content as is, or print
in a more friendly way if desired (in case it was successfully read
as a valid ISO date).
- If content is missing, print 'datetime' attribute (in a friendly
way, if desired and set by user, or simply as is if unable to do
better)
- If both content and datetime are present, print content on page
and show a representation of the date in datetime with a mechanism
such as a tool tip
This seems overly complex to me.
Can we follow existing practice from TEI ie. datetime may only be
Gregorian and no other calendar - calendar (if present) identifies
the calendar in the original text (analogous to the way the HTML lang
attribute indicates the language of the enclosed text).
So, a date marked up in a TEI document as
18th Feb. 1546
transforms to the following HTML
18th Feb. 1546
My reasoning here is that TEI is already in widespread use, authors
familiar with it will expect the same markup practices in HTML and
one of the largest uses for historical dates as elements will
be transformation of existing TEI documents to HTML.
It seems dangerous, to me, to adopt a whole new standard for
historical dates in HTML when there is an existing standard in wide use.
Essentially I'm asking that the spec for mirror the existing
spec for to make it compatible with historical texts:
http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html
Regards
Jim
Jim O'Donnell
j...@eatyourgreens.org.uk
http://eatyourgreens.org.uk
Re: [whatwg]
It seems that pretty much everyone agrees on this:
- Allow the use of an alternate calendar, but only Gregorian is required to
be understood by user agents
- We only require the user agent to display dates; they are free to do more
if they like (conversion, ...) but are not required to.
- Calendar is specified in a new attribute ('calendar' or something similar)
and the value of 'datetime' attibute is specified in the calendar specified
by that new attribute
- If 'datetime' attribute is missing, try to interpret the content as an ISO
date. User agent could print the content as is, or print in a more friendly
way if desired (in case it was successfully read as a valid ISO date).
- If content is missing, print 'datetime' attribute (in a friendly way, if
desired and set by user, or simply as is if unable to do better)
- If both content and datetime are present, print content on page and show a
representation of the date in datetime with a mechanism such as a tool tip
Does the following examples make sense?
[For theses examples, I'm assuming our user agent only follow the bare
minimum requirements we are setting as a draft (that is, they only
understand Gregorian), I understand that some specialized user agents might
(and probably will) perform conversion as set by the user in the preferences
(or some other mean) or do anything else they like.
I am assuming my particular user agent is set to print in American, long
format, but of course I expect user agents to display dates in an
appropriate way which the user has a control over.]
Today
Tool tip shows: "March 16, 2009"
Some date well in the
past
Tool tip shows: "May 11, 668 (Julian)"
Content could be a Gregorian conversion as performed by an author, or simply
the Julian date again, printed in human readable. User agent should print
what ever content the author wrote.
2009-03-16
Printing directly on the page, no tool tip: "March 16, 2009"
Today
The user agent can't do anything, but print "Today" directly
Content could be anything the user agent cannot interpret as a date/time
Note: This is an invalid use, so this would actually be the default
behavior, as I understand.
16 mars 2009
The user agent could, but is not required to, make an effort to interpret
the date and do whatever it likes with it. However, if the date provided
cannot be interpreted as ISO 8601 it could simply print the content as is
without any change. In this example, if the user agent is able to understand
this French date, the tool tip could be "March 16, 2009" (assuming a user
agent set to display dates as American long format)
A date is printed on
the statue
Printed on the page: "A date is printed on the statue"
Tool tip shows: "12-11-10-09-08 (Mayan Long Count)"
In this example, my user agent does not understand the date, and simply
display in a non converted way
Here is a good one:
A non valid Gregorian date
What shoud the tool tip reads?
"March 47, 2009" (print, without validation... which over time could help
user agents which do not understand non Gregorian when calendar attribute is
set to something other than Gregorian)
"2009-03-47" (as date is not valid, simply prints original value without any
conversion)
"Invalid Date" (just an error message)
or just do nothing, since the date is not valid
Re: [whatwg]
At 19:01 -0500 14/03/09, Robert J Burns wrote: The problem isn't that negative integers are not well-defined and understood well. The problem is understanding how an ISO 8601 representation - such as these examples include - maps to an author's or user's understanding of the year 2 BC (or is it 1 BC?). ISO 8601 provides no clear way out of that ambiguity. I disagree. It lays out a clear way of labelling dates, that happens to correspond to the Gregorian calendar after its introduction. It has a year 0 (because both it uses normal integers to count years, and because this keeps the leap year calculation correct). In everyday usage, 1BC (1BCE) precedes 1AD (1CE). So, yes, there is a adjustment of 1 moving between the two. 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. Since it defines both zero and negative years, how did it punt? 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. A note pointing this out might be prudent. 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? UA choice; it might display it in a different (mappable) calendar system entirely. That's one of the major points of having a well-defined day-labelling system - it can be mapped to any other well-defined system. 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. Could you cite specifically where you get that from ISO 8601:2000? I'm looking at ISO 8601:2004 and don't see a clear indication of that anywhere. "Consecutive calendar years are identified by sequentially assigned year numbers" In sequential numbers, zero precedes 1. In case of doubt, it even says, emphasizing that there is a year labelled as 0: "In the proleptic Gregorian calendar, the calendar year [] is a leap year. " It doesn't comment on mapping to other uses; it merely labels days and years. If you want to map to a calendar that omits the label "0" but uses 1BC (BCE) instead, then you'll need to adjust by 1. It could (but should not) have sections on mapping to any number of other calendar formats. We aren't really asking much of UAs in terms of implementation here. The HTML5 draft includes algorithms to parse the dates, but whatever happens with them after they are parsed are left up to other processors and other standards. This means that allowing keyword differentiation of alternate calendars (with clear norms for an omitted keyword and a "Gregorian" keyword) requires very little of UAs. It requires a huge amount; instead of mapping ISO 8601 to whatever they want to present, they have to be ready for arbitrary numbers of source formats, and they'll fail if the source format is unrecognized. If the author can't convert it, why assume the UA can? At 13:14 +0100 16/03/09, Leif Halvard Silli wrote: I can live with @datetime limited to ISO-8601, as long as @datetime also lives up to ISO-8601's own limitations: It isn't valid beyond 1582-10-15 I assume you mean 'before'. On the contrary, it says explicitly: "The Gregorian calendar was introduced on 15 October 1582. In the calendar set by this standard the calendar day preceding that calendar day is referred to as 14 October 1582." At 8:00 -0500 16/03/09, Robert J Burns wrote: The other problem I think you're missing is that dates referenced in historical documents are often non-Gregorian dates. It isn't "standard" to use the proleptic Gregorian calendar to reference the date of historical events. It is "standard" to use whatever calendar is used locally (or elsewhere in the world) at the time of the event (especially for Julian calendar usage). Right; you write the source document's date in the body text, and you provide, if you can, the ISO 8601 label of that day, in the attribute. The ides of march, 14 BC This allows the UA to present the day in any calendar mappable from an ISO 8601 day-label, to the user, in whatever accessibility modality the user wants. At 15:59 +0200 16/03/09, Mikko Rantalainen wrote: How about specifying that the content of element will be parsed for the date only if 'datetime' attribute i
Re: [whatwg]
The most the specification can say about dates without a machine-readable value attribute is that the user agent should do its best to figure out what the content means given the language the document is in, perhaps with precedence given to Gregorian calendar in case of doubt. The exact rules for that require too much artificial intelligence to be universally specified. Note that the specification does not (and cannot) say that a HTML document MUST be valid. It merely describes how the user agent should handle HTML documents, including ones containing random text. IMHO, Chris
Re: [whatwg]
Tom Duhamel wrote: > 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 How about specifying that the content of element will be parsed for the date only if 'datetime' attribute is empty. In addition, the spec should explicitly say that if the content is time in any other calendar system but Proleptic Gregorian calendar then the datetime MUST contain equivalent time in standard format (whatever the spec for 'datetime' will be). -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Mon, Mar 16, 2009 at 2:43 PM, Anne van Kesteren wrote: > On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker > wrote: >>> >>> Why does the DOM need to get involved here? >> >> Well it should be involved, although I don't think we can actually do >> it. I think the CORS header response should be stored and be available >> the same way across all DOM elements that can load data. If that would >> be provided by a special interface from which all elements that load >> data descend, it would not only make the whole thing cleaner in the >> spec, but also in the implementations. > > If the specifics are not exposed to authors the DOM does not need to get > involved. Correct. I'm not a browser maker, so my perspective is probably a bit different than yours. I just write JS. The problem for me is that if such data is not available, I would be forced to basically do a lot of try/catch or other form of error catching just to find out what exactly I can do when I could just look it up in the elements attributes. >> Instead of an UA supporting >> first XHR, then image, then video, then XY, the status of the >> implementation would be identical in all parts of the UA. Basically, >> it would force implementations to create the CORS dom support with a >> common codebase for all elements that use it, instead of having >> duplicate code which might behave differently. > > I don't think we should be in the business of enforcing how implementations > implement things. We can certainly encourage things by re-using algorithms, > indicating things are identical, etc., but if there is no author-observable > difference we cannot test it. Well, a bit. We do that all the time when we specify inheritance. At least we encourage it and plant the idea that this really should be in a common spot. 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. >>> >>> I don't see how this is wrong. Since the exact semantics of a >>> cross-origin request vary per API anyway grouping the common things >>> somewhere makes sense to me. (E.g. EventSource would completely fail in case >>> the resource sharing check fails where as an image would still be >>> displayed.) >> >> Reading this again the next morning I really should have worded that >> differently. Sorry about that. But I'm really afraid JS developers, in >> addition to catching different behaviours in different UAs would also >> have to deal with different behaviour inside the same UA. Yes, the >> actual use would be different across different cases, but at least the >> raw data would be readable the same way and the parts that implement >> the different uses would have a standardized to where to get their >> data from. > > Consistency is enforced by tests and proper specifications. Currently HTML5 > has not integrated support for CORS (yet) so it seems a bit early to > complain :-) Better now than when the damage is done, right?
Re: [whatwg]
Smylers wrote: > Robert J Burns writes: >> 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": > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#parse-a-month-component > > So my suggestion for a spec change is to replace "zero" with "1582". > That further reduces the set of dates that 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. Just remove the rule "If year is not a number greater than zero, then fail." The objective, if I've understood correctly, is to be able to markup a specific time. Proleptic Gregorian calendar is suitable for specifying a moment of time before 1582 without a doubt. The only thing that must be *exclicitly* defined is whether or not the day before 0001-01-01 is -12-31 or not. I think that it should be. If it is, it immediately follows that year "-6" is same as "7 BC" and I cannot see any problem with that. The "BC" is different unit so there can (and should) be an offset compared to unitless year number. If you cannot accept Proleptic Gregorian calendar because you believe that it cannot be defined exactly enough, then another possible choice would be the POSIX time (number of seconds since 1970-01-01 00:00:00 UTC). Make that floating point number with arbitrary precision and it can specify any moment in the history or in the future. If less than one second precision is needed, require author to always specify range in that case. Really simple to implement and definitely exact enough. Different calendar systems and daylight saving times are only methods for displaying or describing specific moments of time. The only thing required for HTML is *a method* for marking up any specific moment of time. I repeat: primary objective is to markup any specific moment and secondary objective is to make markup easy enough for the authors (I believe that the unix timestamp is not acceptable because it cannot be authored without using software aids). I do not believe that marking up a given moment with multiple different methods should be an objective. -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker wrote: Why does the DOM need to get involved here? Well it should be involved, although I don't think we can actually do it. I think the CORS header response should be stored and be available the same way across all DOM elements that can load data. If that would be provided by a special interface from which all elements that load data descend, it would not only make the whole thing cleaner in the spec, but also in the implementations. If the specifics are not exposed to authors the DOM does not need to get involved. Instead of an UA supporting first XHR, then image, then video, then XY, the status of the implementation would be identical in all parts of the UA. Basically, it would force implementations to create the CORS dom support with a common codebase for all elements that use it, instead of having duplicate code which might behave differently. I don't think we should be in the business of enforcing how implementations implement things. We can certainly encourage things by re-using algorithms, indicating things are identical, etc., but if there is no author-observable difference we cannot test it. 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. I don't see how this is wrong. Since the exact semantics of a cross-origin request vary per API anyway grouping the common things somewhere makes sense to me. (E.g. EventSource would completely fail in case the resource sharing check fails where as an image would still be displayed.) Reading this again the next morning I really should have worded that differently. Sorry about that. But I'm really afraid JS developers, in addition to catching different behaviours in different UAs would also have to deal with different behaviour inside the same UA. Yes, the actual use would be different across different cases, but at least the raw data would be readable the same way and the parts that implement the different uses would have a standardized to where to get their data from. Consistency is enforced by tests and proper specifications. Currently HTML5 has not integrated support for CORS (yet) so it seems a bit early to complain :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
>> 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. > > Why does the DOM need to get involved here? Well it should be involved, although I don't think we can actually do it. I think the CORS header response should be stored and be available the same way across all DOM elements that can load data. If that would be provided by a special interface from which all elements that load data descend, it would not only make the whole thing cleaner in the spec, but also in the implementations. Instead of an UA supporting first XHR, then image, then video, then XY, the status of the implementation would be identical in all parts of the UA. Basically, it would force implementations to create the CORS dom support with a common codebase for all elements that use it, instead of having duplicate code which might behave differently. >> 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. > > I don't see how this is wrong. Since the exact semantics of a cross-origin > request vary per API anyway grouping the common things somewhere makes sense > to me. (E.g. EventSource would completely fail in case the resource sharing > check fails where as an image would still be displayed.) Reading this again the next morning I really should have worded that differently. Sorry about that. But I'm really afraid JS developers, in addition to catching different behaviours in different UAs would also have to deal with different behaviour inside the same UA. Yes, the actual use would be different across different cases, but at least the raw data would be readable the same way and the parts that implement the different uses would have a standardized to where to get their data from.
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Sun, 15 Mar 2009 22:09:16 +0100, Hans Schmucker wrote: 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. I don't think anyone is disagreeing with that. 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. Why does the DOM need to get involved here? 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. I don't see how this is wrong. Since the exact semantics of a cross-origin request vary per API anyway grouping the common things somewhere makes sense to me. (E.g. EventSource would completely fail in case the resource sharing check fails where as an image would still be displayed.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg]
Leif Halvard Silli wrote: > Mikko Rantalainen 2009-03-13 11.33: >> Andy Mabbett wrote: >>> In message , >>> Jim O'Donnell writes > And is also touted as an accessibilty feature. And this > Proleptic Gregorian calendar is, I hear, supposed to - > automatically - make everything good. I thought that was sematic web feature - making possible for computers to make sense about date and/or time. Humans are quite good deciphering the different date and time notations on the page already. > I am concerned of the authors. And I am concerned that they do not > get a way to record what they need to record. I am concerned that > they will convert dates to Proleptic Gregorian, not realising that > readeres will read/hear that date in his modern day calender. I am > also concerned about how complicated it becomes for the author to > link the (proleptic) day he has recorded to the (julian) day in > history he is writing about. Perhaps the spec should suggest that the rendering of the element should make it clear to the user that the time is in standard calendar e.g. appending text " (Standard Calendar)" at the end of tooltip when displaying the machine readable time. (I used the term "Standard" instead of "Proleptic Gregorian" because that wouldn't say anything to common man.) If the author cannot convert the [whatever calendar] to Proleptic Gregorian calendar, then I do not see much point using the markup at all. What's the point marking something as "time" if you don't have the time? Is there a real difference between "unknown" and ""? > I think, however, that even authors need - and are interested in - > linking historic dates to the modern calendar. And that it > therefore could work, if authors could record the date according > to the historic (aka Julian) calendar, noting in a second > attribute, how that date differs/relates to the One True calendar. I don't understand how that follows. Why is this (using Julian calendar in the attribute) requirement for using the markup? > So for example, Andy's date above > Feb. 11, 1731. > > could be noted like this: > > Feb. 11, 1731. > > Where the purpose of @datetime is to note the date in a format > that is universally recognisable, and where the purpose of @schema > is to note a) how many days this date differs from modern > calendar and b) if there is a year correction (because the > historic calendar considered another day the beginning of that year. > > This could work for the all calendars based on the Julian > calendar. I think that historians and hobby historians are quite > familiar with using lists that equiate historic dates to modern > dates. And it would, be very simple to maintain such lists. The author has clearly the means to convert the 'value' attribute to Proleptic Gregorian, but instead he opts to use different calendar system and an offset. Why on earth? Is it because Julian calendar happens to use somewhat similar counting system (days, months, years)? How this would help the author or the user? Why is this any better than always using Proleptic Gregorian calendar for datetime attribute, no exceptions allowed? -- Mikko signature.asc Description: OpenPGP digital signature
