Re: noted 3 issues re: time/data (was Re: minutes for HTML WG f2f, 2011-11-04, part 1)

Hi,

I'd like to oppose the intention to drop the pubdate attribute from the
time element. Whilst like some other of the HTML5 elements and attributes,
it's probably currently not being used for anything useful just yet, I can
see situations where it would be useful to automatically know which time
element on a particular page is the published date.

Say for example there was a page with a list of tour or event dates. This
could of course consist of any number of time elements, each containing the
specific date and time of a concert or event. In amongst all of these time
elements, is also the publish time/date of the page itself and surely it
would be useful to be able to distinguish that one, quickly, from amongst
all the others?

Similarly when returning search results would it not be more appropriate
for the most recent (and therefore relevant) results to be returned, and
the pubdate attribute could contribute to this as it could be used to
determine which of the pages are the more recent. Google touch on this
usefulness themselves on their blog:
http://googleblog.blogspot.com/2011/11/giving-you-fresher-more-recent-search.html

Regards,

Ian

On 15 November 2011 01:30, Sam Ruby <rubys@intertwingly.net> wrote:

> On 11/14/2011 05:44 PM, Peter Winnberg wrote:
>
>> 2011/11/14 Sam Ruby<rubys@intertwingly.net>:
>>
>>> The current state of these proposals is that they have less detail in the
>>> "Proposal Details" section than we normally require.  This is not a
>>> problem
>>> if there is no contention.  So the way I would like to proceed is to:
>>>
>>> 1) Open up three issues per the above, and so so before this week's
>>> telecon.
>>>
>>> 2) Immediately issue a Call for Consensus on all three proposals.
>>>
>>> 3) Close by Amicable Consensus any issues for which we don't get pushback
>>> sufficient to convince the chairs that there will likely be a counter
>>> proposal.
>>>
>>> 4) Proceed with a normal call for consensus on whatever issues remain (if
>>> any).
>>>
>>> Does anybody object to proceeding in this fashion?
>>>
>>> - Sam Ruby
>>>
>>
>> Not really an objection but a question. I’ll start looking into
>> creating a counter proposal to the data element proposal (if so, it
>> will be my first so I am sure I’ll need some guidance). Instead of a
>> new element this counter proposal would suggest how a new attribute
>> for holding machine readable data on the span element (and maybe other
>> elements) could work.
>>
>> If this counter proposal would suggest that this new attribute should
>> replace the datetime attribute on the time element (I have not made up
>> my mind if this a good idea or not yet) should that be a separate
>> counter proposal or could that be a part of the counter proposal to
>> the data element?
>>
>
> What would it take for you to decide?  My intent isn't to rush anybody,
> but to see if we can avoid any unnecessary work.  For example, if there is
> nobody who wishes to defend the pubdate attribute then that issue need not
> be discussed further.
>
> Given the issues that Tantek has outlined, it looks like you might want to
> object to up to two of the change proposals that he has produced: the one
> for the time element and that introduces the data element.
>
> Of course even better than submitting a counter proposal would be to see
> if you and (in this case) Tantek can work together to produce a common
> proposal that you can both live with.
>
> My recommendation: if you aren't sure on a particular aspect, it probably
> isn't worth objecting on that aspect.
>
>  - Peter Winnberg
>>
>
> - Sam Ruby
>
>


-- 
ian devlin
w: www.iandevlin.com
e: ian@iandevlin.com
t: iandevlin <http://www.twitter.com/iandevlin>
skype: idevlin