Re: [whatwg] time element feedback
On Tue, 31 Aug 2010, Martin Janecke wrote: (1) There's the example of relative date phrases that refer to an absolute date. For example: time datetime='2009'Last year/time's temperature was above average. What's the use case here? What problem is this solving that isn't solved by just writing this?: span title=2009Last year/span's temperature was above average. Before we add features to HTML, we follow the steps described here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F I am not aware of any use cases or problems here (steps 1 and 2). (2) There's the example of dates written in a local format that is not widely understood anywhere else in the world. For example: time datetime='2010'平22年/time saw no major earthquakes in Japan. Besides, time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. Most examples given in the Wiki are use cases for this. Of course not only Japanese would profit but anyone who uses a different calendar from the Gregorian one. This specific use case I agree has merit; as I've said before, though, we should wait to see if the similar features already in the spec gain traction with implementors and authors before adding yet more features here. The danger otherwise is that we overload implementors with too many new features, and they don't support any of them. On Mon, 9 Aug 2010, Tantek Çelik wrote: HTML5 provides mechanisms for both semantically inputting datetime values (via the 6 new datetimeinput types), and semantically outputting datetime values (via the newtime element). However, the types/granularities of dates and times that are supported do not match up on input vs output, and they should. Why? From a design, learning/teaching perspective, it is much better if they are made to match up, that is if every type/granularity of datetime that can be entered can also be semantically marked up (and vice versa). Why? This would be intuitive – at least to me – and I assume to others as well. It's less complicated if there are less differences, it's less to keep in mind. Supporting different date formats for both will most likely lead to more incorrect usage than in case of matching date format support. I think one can argue similarly that things are less complicated when there are fewer features. I'm not sure that either is more compelling than the other. Given that we can complete the pattern once we have implementation experience, though, that seems like the best bet on the short term. It would also be nice to have a year state forinput, as it has more use cases than week, and it would allow combining with the month state for e.g. credit card info. Can you show me a page that has a special control for year input, rather than just a regular text input? Here are results of a quick research: The Bank of Canada (select) http://www.bankofcanada.ca/en/rates/exchform.html (I am aware that this usage would not be replaced by a year only input, still it shows that not all people think text-only suits best for year input.) Japanese year converter (select) http://www.allcalendars.net/JapaneseYearConverter.php Kitco charts (select, input type=checkbox) http://www.kitco.com/charts/historicalgold.html Especially note the YEARLY GOLD CHARTS section. It seems to me that HTML already satisfies their use cases completely here, without needing any new features. This is in contrast to date pickers, where authors have frequently found that HTML does _not_ satisfy their use cases, to the point of them using JS libraries to have custom date pickers. On Tue, 31 Aug 2010, Martin Janecke wrote: I understand that it's not good to implement features that won't be used by anyone in the end. Nevertheless I am worried that this could lead to a chicken or the egg dilemma, i.e. HTML waits for CSS to implement styling (year-only) dates and CSS waits for HTML implementing year-only-dates before making them stylable? HTML isn't waiting for CSS to make the first move -- HTML has already gone a step beyond what CSS supports here. Now we have to make sure we also support this in CSS, before adding even more to HTML. Generally when technologies work together like this they leap-frog each other, roughly in sync with implementations. This ensures that the whole platform doesn't ever get too far ahead of implementations, and it ensure that we don't go too far into the weeds with a bad idea before stopping. The remainder of this thread discussed the pros and cons of having time localise times. This issue will be decided by the market one way or the other; it's not clear to me that we can make progress on it here. -- Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] time element feedback
Am 31.08.2010 22:21 schrieb Martin Janecke: Am 31.08.10 21:40, schrieb Aryeh Gregor: On Tue, Aug 31, 2010 at 5:25 AM, Martin Janeckewhatwg@kaor.in wrote: Besides,time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. I would say the opposite. If they can read the English news article, they'll necessarily know what 2010 means. But they might not be able to read Japanese. Maybe they're borrowing a Japanese person's computer, for example, or maybe the browser's idea of the user language is otherwise wrong. Also, content that behaves differently based on the browser settings of the viewer is confusing and can cause hard-to-debug problems. Users will think that the author of that British article actually wrote out a Japanese date, and be completely at a loss to explain why. Even if they can actually understand the date, the incongruity will look like a bug. It could be outright misleading if there are two year display formats that look the same but actually have different meaning. A plain year number in Arabic numerals like 2010 could refer to any number of totally different year-numbering conventions, and the only way to tell them apart currently is the page's context. Having the browser change the number to some convention that doesn't match its surroundings makes it impossible to guess the convention. And finally, it just looks weird. I would find it extremely strange to have all dates on pages I'm reading replaced with Hebrew dates, even though I understand those just fine. I wouldn't want that at all, and I find it hard to believe that many actual users do in real life. Basically, any kind of attempt to have browsers localize dates that are actually displayed in content is a terrible idea, and the spec should remove all mention of any such thing. I'm pretty sure I've said all this before, though. I understand your point, the situation you describe would be unfavorable indeed. However, there's no need to make this unfavorable. The localized display of times and dates can be realized via tooltips for example, as it is often seen with abbreviations in texts. The localized date doesn't have to be a replacement for the original date string but can be a helpful, explaining addition. This is a nice idea, but localisation should then be based on the language of the context of the time element, not based on the browser language: html lang=de body pDie Party ist time datetime=2010-09-01heute/time./p /body /html The tooltip might then display 1. September 2010 in German - independent from the computer or browser language. As Aryeh stated, displaying a Japanese or English date here on the computer in an internet café would be highly disturbing - even in a tooltip. Localisation should not mess around with the content unless explicitly triggered by the author. -- Markus
Re: [whatwg] time element feedback
Aryeh Gregor writes: On Tue, Aug 31, 2010 at 3:53 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: I think localisation does have a valid use though. Consider a page written in English with the date 01/12/2010. Is that date the 1st December, or the 12th January? The only clue might be the spelling of certain words in the document, but even then, the most popular office software in use at the moment defaults to American spelling for its spell-check feature, even if bought in England, which leads to words being spelt wrong and giving the reader no good clue as to what the date might be. Localisation in this case would mean that I could read the document and easily figure out what the date was. What do expect the browser to do in this case? Flip it to 12/01/2010 if appropriate, ... would make things much worse, because now rather than having to guess whether the *page* is using American or British convention (usually not too hard), you have to guess what convention your *browser* thinks is right (and it might be someone else's computer, a public computer, . . .). Even so, that still doesn't help. You _also_ have to know whether the author just wrote the date in text or used the time element, in order to know whether your browser has already localized the date for you. Which, in general, an author will have no way of knowing. Smylers -- http://twitter.com/Smylers2
Re: [whatwg] time element feedback
On Tue, Aug 31, 2010 at 4:19 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: Because as I mentioned, content authors tend to be quite lazy, and leave default settings on. So lots of English people end up using American spelling, and American date formatting, because that's what their software does by default. I could find you 10 people who didn't know how to change this setting in MSWord for every one you found who did. However, I think readers should be given the choice still with this. If the content authors don't want their precious dates to be read as dates, then don't mark them up as such. A date should be something that can be understood by a variety of media, including search engines, screen readers, even as part of a web snippet that seems to be a popular thing at the moment. If it's in an ambiguous format then there's no point it even being marked up as a date at all. I don't follow what you're saying. How does this relate to auto-rewriting dates according to user preference? I don't think I said anything about marking up dates, beyond that they should not be rewritten according to user preference. On Tue, Aug 31, 2010 at 4:21 PM, Martin Janecke whatwg@kaor.in wrote: However, there's no need to make this unfavorable. The localized display of times and dates can be realized via tooltips for example, as it is often seen with abbreviations in texts. The localized date doesn't have to be a replacement for the original date string but can be a helpful, explaining addition. In principle, I guess that would be harmless. But returning to the original point of this discussion, the question is whether time2010/time should be allowed. I don't think the browser could add a localized tooltip is a good use-case here, because it's not obvious why users would actually want the browser to do so, and it's not obvious that any implementer would be interested in making their browser do so. Furthermore, browsers should not force a localized version upon their users. Users should be able to configure their prefered format, just as they can set a preferred language or a default charset. This assumes that users actually choose their browser settings. In practice, most users have no idea how to reconfigure their browser; they probably don't want to even if they do know how; they often use other people's browsers; and if they did reconfigure the browser, it might have been by mistake or long ago. So you can't assume that the browser configuration actually reflects what the user wants. (This is the basic idea behind programs that try to minimize configurability, like Chrome, or indeed most Google products.) On Wed, Sep 1, 2010 at 10:37 AM, Smylers smyl...@stripey.com wrote: Even so, that still doesn't help. You _also_ have to know whether the author just wrote the date in text or used the time element, in order to know whether your browser has already localized the date for you. Right, I forgot that point. So it's really just hopeless to try rewriting dates like 12/1/2010.
Re: [whatwg] time element feedback
On Tue, Aug 31, 2010 at 5:25 AM, Martin Janecke whatwg@kaor.in wrote: Besides, time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. I would say the opposite. If they can read the English news article, they'll necessarily know what 2010 means. But they might not be able to read Japanese. Maybe they're borrowing a Japanese person's computer, for example, or maybe the browser's idea of the user language is otherwise wrong. Also, content that behaves differently based on the browser settings of the viewer is confusing and can cause hard-to-debug problems. Users will think that the author of that British article actually wrote out a Japanese date, and be completely at a loss to explain why. Even if they can actually understand the date, the incongruity will look like a bug. It could be outright misleading if there are two year display formats that look the same but actually have different meaning. A plain year number in Arabic numerals like 2010 could refer to any number of totally different year-numbering conventions, and the only way to tell them apart currently is the page's context. Having the browser change the number to some convention that doesn't match its surroundings makes it impossible to guess the convention. And finally, it just looks weird. I would find it extremely strange to have all dates on pages I'm reading replaced with Hebrew dates, even though I understand those just fine. I wouldn't want that at all, and I find it hard to believe that many actual users do in real life. Basically, any kind of attempt to have browsers localize dates that are actually displayed in content is a terrible idea, and the spec should remove all mention of any such thing. I'm pretty sure I've said all this before, though.
Re: [whatwg] time element feedback
On Tue, 2010-08-31 at 15:40 -0400, Aryeh Gregor wrote: On Tue, Aug 31, 2010 at 5:25 AM, Martin Janecke whatwg@kaor.in wrote: Besides, time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. I would say the opposite. If they can read the English news article, they'll necessarily know what 2010 means. But they might not be able to read Japanese. Maybe they're borrowing a Japanese person's computer, for example, or maybe the browser's idea of the user language is otherwise wrong. Also, content that behaves differently based on the browser settings of the viewer is confusing and can cause hard-to-debug problems. Users will think that the author of that British article actually wrote out a Japanese date, and be completely at a loss to explain why. Even if they can actually understand the date, the incongruity will look like a bug. It could be outright misleading if there are two year display formats that look the same but actually have different meaning. A plain year number in Arabic numerals like 2010 could refer to any number of totally different year-numbering conventions, and the only way to tell them apart currently is the page's context. Having the browser change the number to some convention that doesn't match its surroundings makes it impossible to guess the convention. And finally, it just looks weird. I would find it extremely strange to have all dates on pages I'm reading replaced with Hebrew dates, even though I understand those just fine. I wouldn't want that at all, and I find it hard to believe that many actual users do in real life. Basically, any kind of attempt to have browsers localize dates that are actually displayed in content is a terrible idea, and the spec should remove all mention of any such thing. I'm pretty sure I've said all this before, though. I think localisation does have a valid use though. Consider a page written in English with the date 01/12/2010. Is that date the 1st December, or the 12th January? The only clue might be the spelling of certain words in the document, but even then, the most popular office software in use at the moment defaults to American spelling for its spell-check feature, even if bought in England, which leads to words being spelt wrong and giving the reader no good clue as to what the date might be. Localisation in this case would mean that I could read the document and easily figure out what the date was. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] time element feedback
On Tue, Aug 31, 2010 at 3:53 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: I think localisation does have a valid use though. Consider a page written in English with the date 01/12/2010. Is that date the 1st December, or the 12th January? The only clue might be the spelling of certain words in the document, but even then, the most popular office software in use at the moment defaults to American spelling for its spell-check feature, even if bought in England, which leads to words being spelt wrong and giving the reader no good clue as to what the date might be. Localisation in this case would mean that I could read the document and easily figure out what the date was. What do expect the browser to do in this case? Flip it to 12/01/2010 if appropriate, or rephrase it like January 12, 2010 (or December 1, 2010)? The former would make things much worse, because now rather than having to guess whether the *page* is using American or British convention (usually not too hard), you have to guess what convention your *browser* thinks is right (and it might be someone else's computer, a public computer, . . .). If the author wants the latter effect, on the other hand, why don't they just write out the date that way to begin with, since they aren't actually looking for it to vary between viewers?
Re: [whatwg] time element feedback
Am 31.08.10 21:40, schrieb Aryeh Gregor: On Tue, Aug 31, 2010 at 5:25 AM, Martin Janeckewhatwg@kaor.in wrote: Besides,time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. I would say the opposite. If they can read the English news article, they'll necessarily know what 2010 means. But they might not be able to read Japanese. Maybe they're borrowing a Japanese person's computer, for example, or maybe the browser's idea of the user language is otherwise wrong. Also, content that behaves differently based on the browser settings of the viewer is confusing and can cause hard-to-debug problems. Users will think that the author of that British article actually wrote out a Japanese date, and be completely at a loss to explain why. Even if they can actually understand the date, the incongruity will look like a bug. It could be outright misleading if there are two year display formats that look the same but actually have different meaning. A plain year number in Arabic numerals like 2010 could refer to any number of totally different year-numbering conventions, and the only way to tell them apart currently is the page's context. Having the browser change the number to some convention that doesn't match its surroundings makes it impossible to guess the convention. And finally, it just looks weird. I would find it extremely strange to have all dates on pages I'm reading replaced with Hebrew dates, even though I understand those just fine. I wouldn't want that at all, and I find it hard to believe that many actual users do in real life. Basically, any kind of attempt to have browsers localize dates that are actually displayed in content is a terrible idea, and the spec should remove all mention of any such thing. I'm pretty sure I've said all this before, though. I understand your point, the situation you describe would be unfavorable indeed. However, there's no need to make this unfavorable. The localized display of times and dates can be realized via tooltips for example, as it is often seen with abbreviations in texts. The localized date doesn't have to be a replacement for the original date string but can be a helpful, explaining addition. Furthermore, browsers should not force a localized version upon their users. Users should be able to configure their prefered format, just as they can set a preferred language or a default charset.
Re: [whatwg] time element feedback
On Tue, 2010-08-31 at 16:09 -0400, Aryeh Gregor wrote: On Tue, Aug 31, 2010 at 3:53 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: I think localisation does have a valid use though. Consider a page written in English with the date 01/12/2010. Is that date the 1st December, or the 12th January? The only clue might be the spelling of certain words in the document, but even then, the most popular office software in use at the moment defaults to American spelling for its spell-check feature, even if bought in England, which leads to words being spelt wrong and giving the reader no good clue as to what the date might be. Localisation in this case would mean that I could read the document and easily figure out what the date was. What do expect the browser to do in this case? Flip it to 12/01/2010 if appropriate, or rephrase it like January 12, 2010 (or December 1, 2010)? The former would make things much worse, because now rather than having to guess whether the *page* is using American or British convention (usually not too hard), you have to guess what convention your *browser* thinks is right (and it might be someone else's computer, a public computer, . . .). If the author wants the latter effect, on the other hand, why don't they just write out the date that way to begin with, since they aren't actually looking for it to vary between viewers? Because as I mentioned, content authors tend to be quite lazy, and leave default settings on. So lots of English people end up using American spelling, and American date formatting, because that's what their software does by default. I could find you 10 people who didn't know how to change this setting in MSWord for every one you found who did. However, I think readers should be given the choice still with this. If the content authors don't want their precious dates to be read as dates, then don't mark them up as such. A date should be something that can be understood by a variety of media, including search engines, screen readers, even as part of a web snippet that seems to be a popular thing at the moment. If it's in an ambiguous format then there's no point it even being marked up as a date at all. Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] time element feedback
On Sat, 7 Aug 2010, Tantek �~Gelik wrote: the new time element is very useful for absolute dates and times, but omits several useful granularity levels, in particular for dates. The following additional date granularities would be useful, and are fairly straightforward to incorporate into the spec (and implementations): * year only: * year-month only: -MM (also corresponds to output form of input type=month) * year-week only: -WNN (also corresponds to output form of input type=week) * month-day only: --MM-DD (common birthdays without year use case) http://wiki.whatwg.org/wiki/Time#Date_granularity As far as I can tell, none of these are use cases for timeYEAR/time, as opposed to just YEAR. (But it's hard to tell, because the wiki page is very brief and doesn't even use full sentences.) On Mon, 9 Aug 2010, Tantek �~Gelik wrote: HTML5 provides mechanisms for both semantically inputting datetime values (via the 6 new datetime input types), and semantically outputting datetime values (via the new time element). However, the types/granularities of dates and times that are supported do not match up on input vs output, and they should. Why? From a design, learning/teaching perspective, it is much better if they are made to match up, that is if every type/granularity of datetime that can be entered can also be semantically marked up (and vice versa). Why? It would be great if you could add your +1 accordingly to allowing time to markup just a year: http://wiki.whatwg.org/wiki/Time#year_only Note that I completely ignore volume of feedback and only look at the actual arguments presented. +1s and -1s have no effect on the spec. On Tue, 10 Aug 2010, Tantek �~Gelik wrote: We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location). This experience yielded the microformats adoption of the DRY principle - don't repeat yourself - in application to (meta)dataformat designs and techniques. The time element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element). You don't have to give content in the element. In fact it's basically only allowed for fallback for legacy UAs. 1. composite nested time elements. In short, instead of this (actual example derived from markup of blog post HTML5 watch[1] by Jeremy Keith) time class=published datetime=2009-12-13T17:43:29 Sunday, December 13th, 2009 5:43pm /time We want to be able to do this: time class=published time datetime=2009-12-13Sunday, December 13th, 2009/time time datetime=17:43:295:43pm/time /time and have the parent time element composite a complete datetime from the child time elements with separate date and time. There's just as much hidden metadata and a ton more markup. That seems like a loss to me. Why not just do: time pubdate datetime=2009-12-13T17:43:29Z/time ...which means the same thing and has no hidden metadata? (Modulo timezone issues; note that floating datetimes aren't allowed with time currently.) 2. am pm and coarser time parsing Summary: by permitting am pm and coarser time values, many more instances of time markup can be minimized to in-content only (not requiring a datetime attribute) and thus reduce many DRY violations. In short, instead of this (actual example derived from markup of blog post HTML5 watch by Jeremy Keith, with nested time elements per previous proposal) time class=published time datetime=2009-12-13Sunday, December 13th, 2009/time time datetime=17:43:295:43pm/time /time We want to be able to do this: time class=published time datetime=2009-12-13Sunday, December 13th, 2009/time time5:43pm/time /time It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction. This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5. Again, just use a single time with no content and put all the data in the datetime= attribute. On Wed, 11 Aug 2010, Tantek �~Gelik wrote: The first markup example in section 4.6.9 needs updating: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element Current Example and text: === snip === div
