W3C home > Mailing lists > Public > public-html@w3.org > March 2009

Re: [whatwg] <time>

From: Leif Halvard Silli <lhs@malform.no>
Date: Mon, 16 Mar 2009 23:29:57 +0100
Message-ID: <49BED2E5.8080903@malform.no>
To: Mikko Rantalainen <mikko.rantalainen@peda.net>
CC: whatwg@lists.whatwg.org, public-html@w3.org
Mikko Rantalainen 2009-03-16 12.55:
> Leif Halvard Silli wrote:
>> Mikko Rantalainen 2009-03-13 11.33:
>>> Andy Mabbett wrote:
>>>> In message <CC3986D1-6DDC-4007-8BBA-42A5D4E398CA@eatyourgreens.org.uk>, 
>>>> Jim O'Donnell <jim@eatyourgreens.org.uk> writes
>> And <time> is also touted as an accessibilty feature. And this 
>> Proleptic Gregorian calendar is, I hear, supposed to - 
>> automatically - make everything good.
> 
> I thought that <time> 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.

Lachlan suggested that <time> could help screen readers pronouce 
the content as a date or time o'clock. [1] Even for graphical UAs 
it can be a useful separate time stylistically from the context. 
He also suggested @datetime as a help for clearing up ambiguously 
writteen dates/times. It helps to know that "this is meant as time".

>> 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 <time> 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.)

What is "rendering" in this regard? You assume "tooltip".  If 
author adds @title as well - will they then be displayed together 
- e.g. like Opera displays @title and @href in the same tooltip?

Proposal: Specify that, just as @title in the <abbr> element has a 
specific purpose, @title in <time> has the specific purpose of 
containing the bespoken time in an format and calendar relevant to 
the text. For example - with or without datetime:

"<time title="AD 995-07-29">Monday</time> Saint Olav died."
"<time datetime="0995-08-04" title="AD 995-07-29">Monday</time> 
Saint Olav died."

"ISO", "ISO time" or "ISO standard time" would be clearer than 
"standard calendar" and would make it selfevident that the date is 
not necessarily historically relevant.

Also, to make the purpose clear to authors - to help them 
understand if it is relevant to add @datetime, and to help them 
not make errors, it would be better if the attribute was renamed 
to for example isotime="". Authors should not just add @datetime 
(or even <time> itself) just because they *think* it is good, but 
because they *know* that it is good - for their purpose.

> If the author cannot convert the [whatever calendar] to Proleptic
> Gregorian calendar, then I do not see much point using the <time> markup
> at all. What's the point marking something as "time" if you don't have
> the time? Is there a real difference between "<time>unknown</time>" and ""?

If this is indeed supposed to be the sole purpose of <time>, then 
the draft should say that <time> is only relevant if authors wish 
to insert the ISO date/time.

>> 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 <time> markup?

That view was depending on the impression that @datetime is 
supposed to help clearing up ambiguously written dates/times.

The reason that the Gregorian calendar is unambiguous is because 
that calendar - along with its era - is known to the entire world 
- it isn't the format alone that makes you understand what 
2009-03-17 means.

Therefore it is also uknown what that 1500-01-01 means. Or, 
rather, to most persons dealing with European history, that date 
probably refers to a Julian date.

But as told, @title can be used for the historical date.

>> So for example, Andy's date above
>>
>>>>> <date calendar="Julian" value="1732-02-22">Feb. 11, 1731.</date>
>> could be noted like this:
>>
>> <date schema="11,1732" datetime="1731-02-11">Feb. 11, 1731.</date>
>>
>> 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?

If it is is made very clear that <time> with @datetime is only 
relevant to use if you're interested in the ISO time, then fine.

But of course the historical calendar date is important and useful 
  to have. E.g. if a text talks about some specific days in year 
1000 CE, and the author and the reader are interested in keeping 
track of the exact dates without typing them directly in the text. 
See the example above where I propose to use @title for this.

Further, the first step towards adding ISO dates is to date things 
according to the actual historical calendar used. Thenafter, that 
date can be mapped to the ISO date - by the author. To not have 
the  original calendar date available - if not in the text then in 
  @title or similar - will only hamper the conversion to ISO dates 
and also lead to many reader questions regarding the dating, if it 
is correct and so on.

Mikko Rantalainen 2009-03-16 14.59:
> 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 <time> 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).

This is the certain way to get authors *not* to use <time>.

But - of course - it is also good way to free authors from 
thinking of using an element that would make them focus on adding 
irrelevant data.  (Unless the author sees his purpose as helping 
Google in making a searchable world history or something like 
that. But even for that purpose, the historical calendar dates are 
necessary, as a first step, and for control - see above.)

[1] http://www.w3.org/mid/49B8F38A.7030801@lachy.id.au
[2] http://en.wikipedia.org/wiki/Japanese_era_name

Leif Halvard Silli
Received on Monday, 16 March 2009 22:30:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:43 UTC