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 time element is meant as a replacement for the microformat
abbr design pattern
Thanks Henri,
Is time then like address in HTML 4? ie. intended for certain dates
only, just as address 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 time to mark up the
Henri Sivonen said
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018687.html)
The time element is meant as a replacement for the microformat
abbr design pattern in hCalendar (if the microformat community
embraces time; if not, time in pretty much pointless in HTML5).
The
On Mar 5, 2009, at 13:33, j...@eatyourgreens.org.uk wrote:
Is time then like address in HTML 4? ie. intended for certain
dates only, just as address may not be used to mark up all
addresses?
Yes, in the sense that time is designed for contemporary secular
civilian use cases. (If someone
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 time.
I think that's a spec bug.
(I use it on my website to markup publication dates of blog entries
and
On Thu, Mar 5, 2009 at 11:33 AM, j...@eatyourgreens.org.uk
j...@eatyourgreens.org.uk wrote:
[...]
Bruce Lawson uses time 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
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 Thu, Mar 5, 2009 at 6:16 AM, Philip Taylor excors+wha...@gmail.com 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 time class=time
On Thu, Mar 5, 2009 at 12:56 PM, James Graham jgra...@opera.com 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
On Thu, Mar 5, 2009 at 12:56 PM, James Graham jgra...@opera.com 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
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.
On Wed, Mar 4, 2009 at 5:29 PM, Jim O'Donnell j...@eatyourgreens.org.uk 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
In message 10c0368b-e984-42a7-933f-b7cb6f1f2...@iki.fi, Henri Sivonen
hsivo...@iki.fi 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
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
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 - - :
p ... For these events to take place within a three week or so
period is simply impossible. The time
datetime=-0004-03-13eclipse/time
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
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
On Thu, Mar 5, 2009 at 3:02 PM, Drew Wilson atwil...@google.com 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
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
On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman micha...@google.com 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
On Thu, Mar 5, 2009 at 5:33 PM, Michael Nordman micha...@google.com wrote:
On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman micha...@google.com wrote:
Allowing cookie to be set would unfortunately create a synchronous
communication channel between the worker and the main window. This is
On Fri, 06 Mar 2009 10:35:19 +0900, Jonas Sicking jo...@sicking.cc 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
On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman micha...@google.com 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
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
On Thu, Mar 5, 2009 at 5:44 PM, Drew Wilson atwil...@google.com 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
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
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,
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
On Thu, Mar 5, 2009 at 5:40 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 06 Mar 2009 10:35:19 +0900, Jonas Sicking jo...@sicking.cc 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.
On Fri, 06 Mar 2009 12:56:43 +0900, Michael Nordman micha...@google.com
wrote:
On Thu, Mar 5, 2009 at 5:40 PM, Anne van Kesteren ann...@opera.com
wrote:
Yes, cookies are no longer exposed through XMLHttpRequest in any way
per the specification.
So am i to understand that cookies headers
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
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
32 matches
Mail list logo
