Re: [whatwg] Accessing cookies from workers

[Michael Nordman]

> Jonas (and I) were talking about setRequestHeader(),
> getAllResponseHeaders(), and getResponseHeader().

Sure.

> postMessage()? :-)

That certainly works for "dedicated workers". Not so great for shared
workers or persistent workers. In the shared case, the postMessage
sender and receiver would have to know the locations of each other to
access and associate cookies at the right level in the path (and a
given shared worker may or may not have a channel open with a "page"
context). In the persistent case, there may not be anyone to
postMessage with at all.

I don't see any fundamental reason to not allow cookies to be
read/written from a worker context? I think of them as DOM/UI 'less
frames in many respects.

Re: [whatwg] Accessing cookies from workers

[Drew Wilson]

>
>
> postMessage()? :-)
>
>
I'm still wondering if we're just trying to ensure behavior (allowing JS
code to access the cookies without having them change asynchronously) that
the spec fundamentally doesn't guarantee anyway.

-atw

Re: [whatwg] Accessing cookies from workers

[Anne van Kesteren]

On Fri, 06 Mar 2009 12:56:43 +0900, Michael Nordman   
wrote:
On Thu, Mar 5, 2009 at 5:40 PM, Anne van Kesteren   
wrote:
Yes, cookies are no longer exposed through XMLHttpRequest in any way  
per the specification.


So am i to understand that cookies headers are not sent to the servers
when using XHR, and that set-cookie headers in a server response to an
XHRs is not respected by the UA? Since that would break about every
known app in the world, I somehow think not.


That's not what I said.



This is all you would need in order to set/read cookies from a worker
(albeit a very expensive operation), provided you had a server that
would cooperate with you.


Fair enough, though Jonas (and I) were talking about setRequestHeader(),  
getAllResponseHeaders(), and getResponseHeader().




Regarding being able to read/write cookies from a worker context... of
course you should be able to do that... if it takes an async api than
so be it.


postMessage()? :-)


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] Accessing cookies from workers

[Michael Nordman]

On Thu, Mar 5, 2009 at 5:40 PM, Anne van Kesteren  wrote:
> On Fri, 06 Mar 2009 10:35:19 +0900, Jonas Sicking  wrote:
>>
>> Gecko, and I believe the latest XHR spec drafts, have disabled access
>> to cookies through XHR in order to prevent leaking of HTTPOnly
>> cookies.
>
> Yes, cookies are no longer exposed through XMLHttpRequest in any way per the
> specification.

So am i to understand that cookies headers are not sent to the servers
when using XHR, and that set-cookie headers in a server response to an
XHRs is not respected by the UA? Since that would break about every
known app in the world, I somehow think not.

This is all you would need in order to set/read cookies from a worker
(albeit a very expensive operation), provided you had a server that
would cooperate with you.

Regarding being able to read/write cookies from a worker context... of
course you should be able to do that... if it takes an async api than
so be it.

>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [whatwg] Accessing cookies from workers

[Boris Zbarsky]

Drew Wilson wrote:

(workers that continue running even after all entangled windows are closed).


On a side note, why would a UA allow these?  Once a user leaves a site, 
the site shouldn't be using any more CPU on the user's computer, no?


-Boris

Re: [whatwg] Accessing cookies from workers

[Drew Wilson]

So I get what you are saying - from an implementation standpoint, any access
to shared data exposes the asynchronously threaded nature of workers to the
developer, without giving them any tools to manage this access (locks, etc).

For cookies, I'd always assumed that cookie state was mutable, since the
server could set the cookie state via an HTTP response coming down in
parallel with the execution of javascript. Perhaps the spec makes guarantees
about the immutability of document.cookies? It doesn't seem to:

"Otherwise, the user agent must act as it would when processing cookies if
it had just attempted to
fetch the
document's 
addressover
HTTP, and had received a response with a
Set-Cookie header whose value was the specified value, as per RFC 2109
sections 4.3.1, 4.3.2, and 4.3.3 or later specifications, but without
overwriting the values of HTTP-only cookies.
[RFC2109]
[RFC2965] "

It seems like developers shouldn't be depending on the value of
document.cookie being static anyway.

-atw

On Thu, Mar 5, 2009 at 5:55 PM, Jonas Sicking  wrote:

> On Thu, Mar 5, 2009 at 5:44 PM, Drew Wilson  wrote:
> > So an asynchronous cookie setting API would look like:
> >
> > setCookie(cookieStr, callback)
> >
> > ...where the callback is invoked once the cookie has been set?
> >
> > I guess I don't yet entirely understand the implementation details - it
> > sounds like there are problems accessing any shared state between workers
> > and window context?
>
> The problem is with code like the following:
>
> if (sharedState < 0) {
>  sharedState = sharedState * -1;
> }
>
> You would expect sharedState to always be non-negative at the end of
> such a program, right? Well, that might not be the case since script
> running in parallel in the main window might have changed the value of
> sharedState from -5 to 10 between the if-statement and the assignment,
> resulting in sharedState being -10 at the end.
>
> This is why workers use a shared-nothing message passing interface
> between workers and windows. This is something that simply can't be
> fixed in the implementation, but something that scripts would have to
> deal with themselves. It's unlikely that web developers would do this
> correctly since working with threads is *very hard* and something that
> even seasoned developers often get wrong.
>
> / Jonas
>

Re: [whatwg] Accessing cookies from workers

[Drew Wilson]

In my particular case, I'm trying to figure out how to use cookie-based
authentication from workers.
I could use postMessage() to a main window to set cookies. However, I have
another motivation for exploring this: my team is planning to experiment
with persistent workers (workers that continue running even after all
entangled windows are closed). In that case, there may not be any window you
can use to set cookies. I'll send more about this in a separate thread.

Finally, there's one thing you can do with cookies that I don't think you
can do with local storage: share data with other subdomains (i.e. if I'm
running code under foo.example.com, I can write a cookie with 'domain=.
example.com' and it'll be visible to code running under
bar.example.comalso). This is useful for things like single sign-on
authentication.

-atw

On Thu, Mar 5, 2009 at 5:42 PM, Jonas Sicking  wrote:

> On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman 
> wrote:
> >> Allowing cookie to be set would unfortunately create a synchronous
> >> communication channel between the worker and the main window. This is
> >> something that we need to avoid to prevent users from having to deal
> >> with locking and other thread related issues.
> >
> > Hmmm... the cookie setting API could be async in workers.
>
> Or you could just use postMessage() and ask the main thread to do it?
>
> What is the use case for reading/writing cookies though? Could use use
> localStorage instead (once we figure out a different API for it that
> doesn't have the shared-state problem that the current API has)
>
> Even just synchronous read access has race-condition problems. For
> example the following script:
>
> if (docCookies == "hello") {
>  doStuff();
> }
> else {
>  log("cookies certainly aren't 'hello', they are: " + docCookies);
> }
>
> could result in "cookies certainly aren't 'hello', they are: hello"
> being printed.
>
> / Jonas
>

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Thu, Mar 5, 2009 at 5:44 PM, Drew Wilson  wrote:
> So an asynchronous cookie setting API would look like:
>
> setCookie(cookieStr, callback)
>
> ...where the callback is invoked once the cookie has been set?
>
> I guess I don't yet entirely understand the implementation details - it
> sounds like there are problems accessing any shared state between workers
> and window context?

The problem is with code like the following:

if (sharedState < 0) {
  sharedState = sharedState * -1;
}

You would expect sharedState to always be non-negative at the end of
such a program, right? Well, that might not be the case since script
running in parallel in the main window might have changed the value of
sharedState from -5 to 10 between the if-statement and the assignment,
resulting in sharedState being -10 at the end.

This is why workers use a shared-nothing message passing interface
between workers and windows. This is something that simply can't be
fixed in the implementation, but something that scripts would have to
deal with themselves. It's unlikely that web developers would do this
correctly since working with threads is *very hard* and something that
even seasoned developers often get wrong.

/ Jonas

Re: [whatwg] Accessing cookies from workers

[Drew Wilson]

So an asynchronous cookie setting API would look like:

setCookie(cookieStr, callback)

...where the callback is invoked once the cookie has been set?

I guess I don't yet entirely understand the implementation details - it
sounds like there are problems accessing any shared state between workers
and window context?

-atw

On Thu, Mar 5, 2009 at 5:35 PM, Jonas Sicking  wrote:

> On Thu, Mar 5, 2009 at 5:33 PM, Michael Nordman 
> wrote:
> > On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman 
> wrote:
> >>> Allowing cookie to be set would unfortunately create a synchronous
> >>> communication channel between the worker and the main window. This is
> >>> something that we need to avoid to prevent users from having to deal
> >>> with locking and other thread related issues.
> >>
> >> Hmmm... the cookie setting API could be async in workers.
> >
> > In the absence of providing such an API, one exists (provided network
> > connectivity) indirectly in the form the XHR... ask the server to
> > either read or set cookies values for you.
>
> Gecko, and I believe the latest XHR spec drafts, have disabled access
> to cookies through XHR in order to prevent leaking of HTTPOnly
> cookies.
>
> / Jonas
>

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman  wrote:
>> Allowing cookie to be set would unfortunately create a synchronous
>> communication channel between the worker and the main window. This is
>> something that we need to avoid to prevent users from having to deal
>> with locking and other thread related issues.
>
> Hmmm... the cookie setting API could be async in workers.

Or you could just use postMessage() and ask the main thread to do it?

What is the use case for reading/writing cookies though? Could use use
localStorage instead (once we figure out a different API for it that
doesn't have the shared-state problem that the current API has)

Even just synchronous read access has race-condition problems. For
example the following script:

if (docCookies == "hello") {
  doStuff();
}
else {
  log("cookies certainly aren't 'hello', they are: " + docCookies);
}

could result in "cookies certainly aren't 'hello', they are: hello"
being printed.

/ Jonas

Re: [whatwg] Accessing cookies from workers

[Anne van Kesteren]

On Fri, 06 Mar 2009 10:35:19 +0900, Jonas Sicking  wrote:

Gecko, and I believe the latest XHR spec drafts, have disabled access
to cookies through XHR in order to prevent leaking of HTTPOnly
cookies.


Yes, cookies are no longer exposed through XMLHttpRequest in any way per  
the specification.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Thu, Mar 5, 2009 at 5:33 PM, Michael Nordman  wrote:
> On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman  wrote:
>>> Allowing cookie to be set would unfortunately create a synchronous
>>> communication channel between the worker and the main window. This is
>>> something that we need to avoid to prevent users from having to deal
>>> with locking and other thread related issues.
>>
>> Hmmm... the cookie setting API could be async in workers.
>
> In the absence of providing such an API, one exists (provided network
> connectivity) indirectly in the form the XHR... ask the server to
> either read or set cookies values for you.

Gecko, and I believe the latest XHR spec drafts, have disabled access
to cookies through XHR in order to prevent leaking of HTTPOnly
cookies.

/ Jonas

Re: [whatwg] Accessing cookies from workers

[Michael Nordman]

On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman  wrote:
>> Allowing cookie to be set would unfortunately create a synchronous
>> communication channel between the worker and the main window. This is
>> something that we need to avoid to prevent users from having to deal
>> with locking and other thread related issues.
>
> Hmmm... the cookie setting API could be async in workers.

In the absence of providing such an API, one exists (provided network
connectivity) indirectly in the form the XHR... ask the server to
either read or set cookies values for you.

Re: [whatwg] Accessing cookies from workers

[Michael Nordman]

> Allowing cookie to be set would unfortunately create a synchronous
> communication channel between the worker and the main window. This is
> something that we need to avoid to prevent users from having to deal
> with locking and other thread related issues.

Hmmm... the cookie setting API could be async in workers.

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Thu, Mar 5, 2009 at 3:02 PM, Drew Wilson  wrote:
> Hi all,
>
> There's currently no way to set or get cookies from workers, which makes
> various types of cookie-based operations problematic.
>
> I'd like to suggest that we add an API to workers to support this, via a
> "cookie" attribute on the WorkerGlobalScope interface. This cookie attribute
> would act like the document.cookie attribute from page context.
>
> When setting cookies, the cookie path would default to the path of the
> script associated with the worker. Likewise, the cookie domain would default
> to the domain of the worker itself (i.e. self.location.hostname).
>
> So, as an example:
>
>     var allCookies = self.cookie;
>     self.cookie='root_cookie=value;path=/;domain=.example.com';
>
> An alternative would be to have explicit getAllCookies() and setCookie()
> APIs, if we don't like carrying over the document.cookie paradigm.
>
> Any thoughts?

Allowing cookie to be set would unfortunately create a synchronous
communication channel between the worker and the main window. This is
something that we need to avoid to prevent users from having to deal
with locking and other thread related issues.

For what it's worth, this is a problem that exists with the
localStorage API that is also exposed in current workers draft.
Something that also needs to be fixed.

It seems like it should fine to allow reading cookies in dedicated
workers though.

/ Jonas

[whatwg] Accessing cookies from workers

[Drew Wilson]

Hi all,

There's currently no way to set or get cookies from workers, which makes
various types of cookie-based operations problematic.

I'd like to suggest that we add an API to workers to support this, via a
"cookie" attribute on the WorkerGlobalScope interface. This cookie attribute
would act like the document.cookie attribute from page context.

When setting cookies, the cookie path would default to the path of the
script associated with the worker. Likewise, the cookie domain would default
to the domain of the worker itself (i.e. self.location.hostname).

So, as an example:

var allCookies = self.cookie;
self.cookie='root_cookie=value;path=/;domain=.example.com';

An alternative would be to have explicit getAllCookies() and setCookie()
APIs, if we don't like carrying over the document.cookie paradigm.

Any thoughts?

-atw

Re: [whatwg] Media element delaying load event

[Chris Pearce]

There's an additional problem with the current media load algorithm 
spec, it's possible to cause two resource-selection asynchronous calls 
to run in parallel with the following javascript:


var v = document.createElement("video");
v.src = "foo.ogg";
v.load();
document.body.appendChild(v);

The load() method will asynchronously invoke the media element's 
resource selection algorithm, and if the resource selection algorithm 
doesn't execute fast enough in the background to change the 
networkState, when we add the video to the document and the networkState 
is still NETWORK_EMPTY, the add-to-a-document code will asynchronously 
invoke the resource selection algorithm again.


I think we should either:

1. Change the networkState in the load() method. This will prevent 
another asychronous invokation of the resource selection algorithm when 
we add the media element to a document, or
2. never asynchronously invoke the resource selection algorithm if 
there's another instance running, or
3. add a guard at the start of the resource selection algorithm to abort 
the async call if there's already another instance running.


Because we have waiting in the load algorithm now, there's no need to 
have multiple instances of the resource selection algorithm active. So 
option 2 is probably the easiest.


I still think we need to delay the load event in the load() method, 
rather than in the resource selection algorithm, as I said in my 
previous post.



Thanks,
Chris Pearce.


On 4/03/2009 10:17 a.m., Chris Pearce wrote:

The media element spec says:

If a media element

whose |networkState
|
has the value |NETWORK_EMPTY
|
is inserted into a document
,
the user agent must asynchronously invoke the media element
's
resource selection algorithm
.


The resource selection algorithm then goes on to set the
delaying-the-load-event flag to true. Depending on how the asynchronous
invocation is implemented, the document could actually complete loading
during the time after the insertion of a media element, but before the
resource-selection algorithm sets the delaying-the-load-event flag is
set to true. This means the load event could fire during that time, even
though we intended to delay the load event.

Maybe we should set the delaying-the-load-event flag to true before we
asynchronously call the resource-selection algorithm, and then then
resource-selection algorithm can set the delaying-the-load-event flag to
false if that decides it needs to wait for a src or source element child?

Thanks,
Chris Pearce.

Re: [whatwg] Historic dates in HTML5

[Jim O'Donnell]

On 5 Mar 2009, at 15:17, Greg Houston wrote:


Personally, I think it would be an improvement to the datetime
attribute if it was valid for at least - - :

 ... For these events to take place within a three week or so
period is simply impossible. The eclipse cannot be the one written in the
records of Josephus.


I agree that this would be an improvement, since it would make   
compatible with hCalendar by using ISO8601 for datetime.


By remarkable serendipity, Paul Tarjan posted a presentation about  
searchmonkey today

http://www.slideshare.net/ptarjan/semantic-searchmonkey
It mentions searching the web by date, where that information is  
available. So I would say a key use case for marking up historic  
dates is searching large archives by date eg. searching the National  
Maritime Museum archive for Elizabethan Navy records dating from 1595.


Wikipedia uses the date-time design pattern, from microformats, to  
mark up historic dates using ISO8601. In addition, TEI is widely used  
by archives and libraries to mark up texts, including ISO8601 dates  
(http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html). Since  
authors are already publishing dates online, surely HTML5 should  
accept all ISO8601 dates rather than a limited subset, which requires  
additional processing on the part of authoring and publishing  
software to filter out valid dates that are invalid HTML5.


Regards
Jim

Jim O'Donnell
j...@eatyourgreens.org.uk
http://eatyourgreens.org.uk
http://flickr.com/photos/eatyourgreens
http://twitter.com/pekingspring

[whatwg] Out-of-document media elements delaying the load event

[Robert O'Callahan]

Should media elements that are loading, haven't reached HAVE_CURRENT_DATA,
but are not actually in the document delay the load event for their owner
document? The spec doesn't say elements that delay the load event have to be
in the document, but it also doesn't say specifically which document's load
event an element delays.

Out-of-document image loads can delay the load event for their owner
document, so I think it makes most sense to allow it for media elements too.

Context: https://bugzilla.mozilla.org/show_bug.cgi?id=479711

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] Historic dates in HTML5

[Andy Mabbett]

In message <10c0368b-e984-42a7-933f-b7cb6f1f2...@iki.fi>, Henri Sivonen 
 writes



On Mar 5, 2009, at 01:29, Jim O'Donnell wrote:

Is there any suitable markup in HTML5 for dates in digitised 
documents from museums, libraries and archives?


What would consuming software do with those dates?


I have already described some of the many use-cases for such dates, in:

  


et seq.


The  element is meant as a replacement for the microformat
 design pattern in hCalendar


Is it? What about the other abuses of ABBR in microformats, such as for 
coordinates and duration:


5:48 ?


(if the microformat community  embraces ; if not,  in pretty

>much pointless in HTML5).

What about the use-cases which I have described, most of which are not 
dependent on microformats?



The expected use cases of hCalendar are mainly transferring *future*
event entries from a Web page into an application like iCal.


Are they? Could you provide a citation for that?

The hCalendar spec doesn't include a definitive set of use-cases 
(indeed, hardly any at all - but then it doesn't even include a full set 
of hCalendar parameters), but it does explicitly refer to "writeups of 
past events".


Many of the hCalendar microformats which I've seen published are for 
historic events, such as those on Wikipedia, for example:


Launch of Sputnik 1:


Marriage Act, 1753:


Are you suggesting that they are in some way in breach of the hCalendar 
spec? If so, how??


You also seem to overlook that dates are not used not only in hCalendar, 
but also in other microformats, such as hAtom (for dating feeds) , and 
hCard (for people's birth dates), for example:


Sir Tim Berners-Lee:


Anthony of Saxony:


The only limit on the use of dates in microformats is that they 
currently rely on ISO8601, which is restricted to Gregorian dates 
(chiefly after 1750, but see:




for the complex change-over dates in different countries). This was 
identified as an issue with the hCalendar specification in September 
2006:




and is still awaiting a solution, hence my proposal for allowing 
non-Gregorian dates in  (at the first URL given above).


--
Andy Mabbett

Re: [whatwg] Historic dates in HTML5

[Greg Houston]

On Wed, Mar 4, 2009 at 5:29 PM, Jim O'Donnell  wrote:
> This then leads to a
> situation where some dates on the web can be marked up, semantically, as
> dates but others cannot, which seems somewhat ridiculous really.

I imagine most teachers and students marking up a timeline would come
to the same conclusion, though if my understanding is correct you can
use the time tag for any date, it is the datetime attribute of the
time tag that has this particular limitation. Someone correct me if I
am wrong.


If you Google "HTML5 time" the first result is a W3Schools page. It
gives these two examples:

We open at 10:00 every morning.

I have a date on Valentines day

There is no mention that the datetime attribute's year must be between
1 and , and if it did, I think the average person's first thought
would be, "That's weird".


Despite that, here are a couple workarounds that I think are valid:

Something happened

On March 5th, 205 b.c.Something happened.

In the first example, the data-datetime would be for internal use only.


Personally, I think it would be an improvement to the datetime
attribute if it was valid for at least - - :

 ... For these events to take place within a three week or so
period is simply impossible. The eclipse cannot be the one written in the
records of Josephus.


Potentially relevant:
http://en.wikipedia.org/wiki/Year_10,000_problem

G.

Re: [whatwg] Historic dates in HTML5

[Bil Corry]

Tab Atkins Jr. wrote on 3/5/2009 6:55 AM: 
> For example, someone writing a calendar app can safely assume that
> any and all dates they have to deal with are within the appropriate
> era.

Unless it contains "This Day in History" type content or a family calendar with 
significant genealogical dates.  But I get that  isn't designed for these 
types of use cases.


- Bil

Re: [whatwg] Historic dates in HTML5

[j...@eatyourgreens.org.uk]

On Thu, Mar 5, 2009 at 12:56 PM, James Graham  wrote:
> Philip Taylor wrote:
>
>> and make sure their stylesheets use the selector ".time" instead of
>> "time", to guarantee everything is going to work correctly even with
>> unexpected input values.
>>
>> So the restriction adds complexity (and bugs) to code that wants to be
>> good and careful and generate valid markup.
>>
>
> On the other hand the python datetime class doesn't seem to support years
<=
> 0 at all so consuming software written in python would have to
re-implement
> the whole datetime module, potentially causing incompatibilities with
third
> party libraries that expect datetimes to have year >= 0. This seems like a
> great deal more effort than simply checking that dates are in the allowed
> range before serializing or consuming them in languages that do support
> years <= 0.

I think limiting the HTML5 spec based on the capabilities of user-agents
(or client software) is dangerous. Firstly, software capabilities change
over time as features are added/removed. Secondly, capabilities vary
between languages and applications. To add to Philip's examples, mysql
datetimes are restricted to years >= 1000 while MS Sql Server will not
accept datetimes prior to 1752. Hence developers parse dates into their
components and use integer types, not datetimes, for very old stuff. Should
HTML5 cater to the lowest common denominator and refuse datetimes before
1752?

Henri is right that the spec should be driven by the needs of authors to
markup specific information online and the value of adding particular
semantics to the web. If I'm the only publisher who sees a value in marking
up historical dates then that's nice, but I'll accept that the HTML spec
shouldn't change to accomodate my individual needs.

However, Henri is also right that a limited datetime in HTML needs to be
absolutely clear in the spec too, which it isn't at the moment.

Regards
Jim



mail2web - Check your email from the web at
http://link.mail2web.com/mail2web

Re: [whatwg] Historic dates in HTML5

[Philip Taylor]

On Thu, Mar 5, 2009 at 12:56 PM, James Graham  wrote:
> Philip Taylor wrote:
>
>> and make sure their stylesheets use the selector ".time" instead of
>> "time", to guarantee everything is going to work correctly even with
>> unexpected input values.
>>
>> So the restriction adds complexity (and bugs) to code that wants to be
>> good and careful and generate valid markup.
>>
>
> On the other hand the python datetime class doesn't seem to support years <=
> 0 at all so consuming software written in python would have to re-implement
> the whole datetime module, potentially causing incompatibilities with third
> party libraries that expect datetimes to have year >= 0. This seems like a
> great deal more effort than simply checking that dates are in the allowed
> range before serializing or consuming them in languages that do support
> years <= 0.

The Python datetime class doesn't seem to support years >  either,
which HTML5 allows. So Python consumers will already have to do "if
not year <= : discard this time element since I'm not going to be
able to do anything with it", and it's easy for them to change that to
"if not 1 <= year <= : ...". That seems less effort than adding
checks into the producers.

If there is a desire that any valid HTML5 date-time string should be
representable in Python's datetime class, then HTML5 should limit it
to 4 digits and refuse to parse anything longer. If so, why Python's
datetime in particular? The C++ Boost.Date_Time
(http://www.boost.org/doc/libs/1_38_0/doc/html/date_time/gregorian.html)
is apparently limited to "1400-Jan-01 to -Dec-31". Perl DateTime
and PHP DateTime and Java joda-time
(http://joda-time.sourceforge.net/field.html) seem happy with a range
of millions of years in both directions. I'm not sure about any other
libraries. The range 1.. seems pretty arbitrary since it only
matches Python, and 1..inf doesn't match anything, so neither seems
particularly justified by implementations.

-- 
Philip Taylor
exc...@gmail.com

Re: [whatwg] Historic dates in HTML5

[Tab Atkins Jr.]

On Thu, Mar 5, 2009 at 6:16 AM, Philip Taylor  wrote:
> But given HTML5's restrictions against BCE years, they'd actually have
> to write something more like:
>
>  if ($t->getYear() > 0) { # (be careful not to write ">= 0" here)
>    print " datetime=".$t->toISO8601Date().">".$t->toLocalisedHumanReadableDate()."";
>  } else {
>    print "".$t->toLocalisedHumanReadableDate()."";
>  }
>
> and make sure their stylesheets use the selector ".time" instead of
> "time", to guarantee everything is going to work correctly even with
> unexpected input values.
>
> So the restriction adds complexity (and bugs) to code that wants to be
> good and careful and generate valid markup.

They may have to do so if they reasonably expect their dates to cross
the 0 demarcation.  The intended uses of  will *not* be expected
to do so.  For example, someone writing a calendar app can safely
assume that any and all dates they have to deal with are within the
appropriate era.

~TJ

Re: [whatwg] Historic dates in HTML5

[James Graham]

Philip Taylor wrote:


and make sure their stylesheets use the selector ".time" instead of
"time", to guarantee everything is going to work correctly even with
unexpected input values.

So the restriction adds complexity (and bugs) to code that wants to be
good and careful and generate valid markup.



On the other hand the python datetime class doesn't seem to support 
years <= 0 at all so consuming software written in python would have to 
re-implement the whole datetime module, potentially causing 
incompatibilities with third party libraries that expect datetimes to 
have year >= 0. This seems like a great deal more effort than simply 
checking that dates are in the allowed range before serializing or 
consuming them in languages that do support years <= 0.

Re: [whatwg] Historic dates in HTML5

[Philip Taylor]

On Thu, Mar 5, 2009 at 11:33 AM, j...@eatyourgreens.org.uk
 wrote:
> [...]
> Bruce Lawson uses  to mark up the dates of blog posts in the HTML5
> version of his wordpress templates. Is this incorrect usage of HTML5? If
> not, how should HTML5 blog templates work when the blog is dated from 1665
> (http://pepysdiary.com) or 1894 (http://www.cosmicdiary1894.blogspot.com/)?

This reminds me of the issue I had with the old  syntax.

People write software that takes some input, and outputs some markup.
They want to guarantee that their markup will be valid and correctly
interpreted by consumers, regardless of the input. (In the 
case, the problem was when the input resulted in legitimate
alternative (non-description) alt text that started with "{" and ended
with "}", forcing the application to add complexity to make sure its
output won't be misinterpreted.)

In any situation where they use , they'd probably want to write
something like:

  print "".$t->toLocalisedHumanReadableDate()."";

But given HTML5's restrictions against BCE years, they'd actually have
to write something more like:

  if ($t->getYear() > 0) { # (be careful not to write ">= 0" here)
print "".$t->toLocalisedHumanReadableDate()."";
  } else {
print "".$t->toLocalisedHumanReadableDate()."";
  }

and make sure their stylesheets use the selector ".time" instead of
"time", to guarantee everything is going to work correctly even with
unexpected input values.

So the restriction adds complexity (and bugs) to code that wants to be
good and careful and generate valid markup.

-- 
Philip Taylor
exc...@gmail.com

Re: [whatwg] Historic dates in HTML5

[Henri Sivonen]

On Mar 5, 2009, at 13:50, Bruce Lawson wrote:

And if there is a limit on  a use case, it should be in the spec.  
There is nothing I can see in the editors draft that limits the use  
of .


I think that's a spec bug.

(I use it on my website to markup publication dates of blog entries  
and comments; why on earth wouldn't I?)


You wouldn't if there's no tangible benefit in sight, i.e. no known  
client app for consuming your markup in a useful way.


Henri is right: time is pretty much pointless in HTML5  
if it's not embraced by the microformats community, but why would  
they embrace it?


They might want to adopt it to avoid accessibility problems with the  
 design pattern:

http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml

It prevents them doing a lot of what they do - like fuzzy or ancient  
dates -  so what do they gain by adopting it?


Are hCalendar entries with fuzzy or ancient dates good for anything?

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] Historic dates in HTML5

[Henri Sivonen]

On Mar 5, 2009, at 13:33, j...@eatyourgreens.org.uk wrote:

Is  then like  in HTML 4? ie. intended for certain  
dates only, just as  may not be used to mark up all  
addresses?


Yes, in the sense that  is designed for contemporary secular  
civilian use cases. (If someone uses the (Common-Era) proleptic  
Gregorian calendar calendar for other use cases, (s)he gets a  
fortuitous free ride.)


In that case, the spec should be clear on correct and incorrect  
usage, with examples of both to guide authors.


Indeed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6536

Bruce Lawson uses  to mark up the dates of blog posts in the  
HTML5 version of his wordpress templates. Is this incorrect usage of  
HTML5?


It's not incorrect, as currently drafted, but it's most likely not  
useful.


If not, how should HTML5 blog templates work when the blog is dated  
from 1665 (http://pepysdiary.com) or 1894 (http://www.cosmicdiary1894.blogspot.com/)?


If a blogger backdates posts in a way that doesn't fit the (Common- 
Era) proleptic Gregorian calendar, (s)he shouldn't use . Note  
that currently http://www.cosmicdiary1894.blogspot.com/ shows the real  
posting date in Blogger's date field and the backdated date as text in  
a heading and neither has any kind of microformat markup.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

[whatwg] Historic dates in HTML5

[Bruce Lawson]

Henri Sivonen said  
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018687.html)


"The  element is meant as a replacement for the microformat
 design pattern in hCalendar (if the microformat community
embraces ; if not,  in pretty much pointless in HTML5).
The expected use cases of hCalendar are mainly transferring *future*
event entries from a Web page into an application like iCal."

If there's one thing that getting involved in specs of markup languages  
has taught me, it's that "expected use cases" don't matter. People always  
do other things.


And if there is a limit on  a use case, it should be in the spec. There is  
nothing I can see in the editors draft that limits the use of . (I  
use it on my website to markup publication dates of blog entries and  
comments; why on earth wouldn't I?)


What it does limit is the format: no "fuzzy dates" like "July 1897" for my  
great grandmother's birthday (no-one remembers the exact day) or the  
precise date of Charlemagne death "28 January 814"


Henri is right: time is pretty much pointless in HTML5 if  
it's not embraced by the microformats community, but why would they  
embrace it? It prevents them doing a lot of what they do - like fuzzy or  
ancient dates -  so what do they gain by adopting it?




--
Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)

Re: [whatwg] Historic dates in HTML5

[j...@eatyourgreens.org.uk]

Thanks Henri,

Is  then like  in HTML 4? ie. intended for certain dates
only, just as  may not be used to mark up all addresses? In that
case, the spec should be clear on correct and incorrect usage, with
examples of both to guide authors.

Bruce Lawson uses  to mark up the dates of blog posts in the HTML5
version of his wordpress templates. Is this incorrect usage of HTML5? If
not, how should HTML5 blog templates work when the blog is dated from 1665
(http://pepysdiary.com) or 1894 (http://www.cosmicdiary1894.blogspot.com/)?

Regards
Jim

Original Message:
-
From: Henri Sivonen hsivo...@iki.fi
Date: Thu, 5 Mar 2009 10:04:45 +0200
To: j...@eatyourgreens.org.uk, whatwg@lists.whatwg.org
Subject: Re: [whatwg] Historic dates in HTML5


On Mar 5, 2009, at 01:29, Jim O'Donnell wrote:

> Is there any suitable markup in HTML5 for dates in digitised  
> documents from museums, libraries and archives?

What would consuming software do with those dates?

The  element is meant as a replacement for the microformat  
 design pattern in hCalendar (if the microformat community  
embraces ; if not,  in pretty much pointless in HTML5).  
The expected use cases of hCalendar are mainly transferring *future*  
event entries from a Web page into an application like iCal.  
Conceivable, one might perhaps also want to support entries that  
encode the birthday (in the past) of a living person with an annual  
repeat.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/





mail2web - Check your email from the web at
http://link.mail2web.com/mail2web

Re: [whatwg] Historic dates in HTML5

[Henri Sivonen]

On Mar 5, 2009, at 01:29, Jim O'Donnell wrote:

Is there any suitable markup in HTML5 for dates in digitised  
documents from museums, libraries and archives?


What would consuming software do with those dates?

The  element is meant as a replacement for the microformat  
 design pattern in hCalendar (if the microformat community  
embraces ; if not,  in pretty much pointless in HTML5).  
The expected use cases of hCalendar are mainly transferring *future*  
event entries from a Web page into an application like iCal.  
Conceivable, one might perhaps also want to support entries that  
encode the birthday (in the past) of a living person with an annual  
repeat.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/