Re: [whatwg] HTML 5: The l (line) element
On Wed, 23 Apr 2008, Christoph Päper wrote: Ian Hickson schrieb: On Wed, 23 Apr 2008, Christoph Päper wrote: there are probably worse compatibility issues with older specs and browsers than extra blank lines. Hopefully not in HTML5. :-) Isn't wrong numbering worse? HTML4 UA HTML5 UA ol reversed liThird1. Third 3. Third liSecond 2. Second 2. Second liFirst3. First 1. First /ol I don't think wrong numbering is especially serious, no. In important cases, you can always use value=. The difference is that this is a new attribute. Using br/br is something we can never do because there are pages that rely on the /br handling. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Expanding datetime
On Apr 24, 2008, at 10:58 , Henri Sivonen wrote: How do proleptic Gregorian dates before the Common Era fit into any of the use cases that states are used for in HTML? *dates* are used... -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Expanding datetime
Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? ...The Y10K problem can also be pushed back by this, but is of only theoretical importance. There are still 7992 years before we need to have a Y10K solution implemented. Thus we can safely leave it to to future generations to solve. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] tabindex= feedback
I've revamped the spec for tabindex= based on the feedback below. On Wed, 21 Mar 2007, Simon Pieters wrote: I think tabindex= has a number of problems: 1) Lacking a feature to scope tabindexes into local contexts, which I proposed[1] a while back, makes the feature rather useless for its intended purpose (which, AIUI, was to provide a means for the author to suggest a different tab order than the natural one, because he was using, say, form controls in a table where the navigation should go down through the columns rather than row for row). [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-August/007228.html Agreed. 2) Using tabindex=0 or -1 to indicate whether an element can have focus is arguably bogus IMHO. Whether something is focusable depends on the UA or the device. I don't see any reason why apps would use span tabindex=0 onclick onkeypress instead of just using links, form controls, or contenteditable= (depending on what you're doing). (If you'd do this because form controls are hard to style, then HTML isn't the place to address that problem.) While I agree in principle, it's clear that there is a demand for custom widgets, and since people are going to do it anyway, we might as well allow them to do it in an at least semi-accessible way. 3) The tab order should be up to the user. In Opera you can navigate in any direction you want using e.g. Shift+arrows, allowing you to freely navigate in tables for instance. The author shouldn't have any say about the tab order other than the source order. Agreed. From what I've seen, most authors who use tabindex use it out of a cargo cultish habit thinking it would aid accessibility because some outdated accessibility guidelines told them so. The result mostly being reducing keyboard usability by distorting the tab order, because the elements with tabindex receive focus before anything else on the page. These authors don't realise how tabindex actually works, but they feel good about having added it because they comply with the accessibility guidelines, yet they don't know that it in fact screws up the tab order because they don't browse with the keyboard. Indeed. It was pointed out on IRC that there might be valid use-cases for #2, e.g. making a canvas focusable for games with keyboard controls. Then that's ok with me, I don't have strong opinions on this either way, I just think existing elements should be used where possible instead of reinventing links or checkboxes with span tabindex or similar. Yup. However, for positive values of tabindex, I only see problems. The source order should be a powerful enough mechanism for authors to suggest a tab order of elements. I would love to see browsers treat all positive values for tabindex as equivalent to 0 (i.e., just make it focusable but don't change the tab order). I would also like to propose that positive values for tabindex be disallowed in HTML5 documents. I don't think it's a good idea to add a scoped tabindex feature (trying to address #1) as I proposed before. I've allowed positive values, but I've allowed user agents to ignore them (supporting them is only a should). On Tue, 20 Mar 2007, ddailey wrote: In a table, I think I agree. The user should know how to get around via UI conventions. In more abstract structures, the author may be able to provide useful hints through tab order. That's one reason I didn't outlaw it altogether. On Tue, 20 Mar 2007, Maciej Stachowiak wrote: Arbitrary elements accepting keyboard input (which is what focus is about) is just as important as arbitrary elements receiving mouse input. You even cited one of my examples below: consider a game implemented with canvas that uses keyboard controls. Obviously you want to be able to make canvas focusable in such cases. There are many analogous use cases, consider building compound controls with XBL that want to have their own keyboard navigation. I don't think there is any need to limit what elements can get keyboard input This seems reasonable. Shift+arrows are a completely separate issue from tab order. Indeed. HTML5 can also recommend not adding these attributes gratuitously. We could, I guess. Right now it doesn't give much author advice either way. Note that UAs do not even agree on what elements are focusable by default. In Safari, links and input type=button controls are not in the tab order, for instance, to match Macintosh UI conventions. The spec caters for this. Can input type=button controls be focused at all, on OS X? On Wed, 21 Mar 2007, Benjamin Hawkes-Lewis wrote: Dropping tabindex /might/ make sense if HTML5 was to be so feature complete that no-one would ever build a DHTML widget out of generic elements ever again. Is this likely to be the case? Because, if not, tabindex looks like part of a solution:
Re: [whatwg] tabindex= feedback
Safari has a preference that puts those elements in the tab order, and it allows you to get that effect on the fly by holding the option key down. Also, buttons (and links) can be focused at any time with JavaScript focus() calls. On Apr 24, 2008, at 2:47 AM, Ian Hickson wrote: Note that UAs do not even agree on what elements are focusable by default. In Safari, links and input type=button controls are not in the tab order, for instance, to match Macintosh UI conventions. The spec caters for this. Can input type=button controls be focused at all, on OS X?
Re: [whatwg] Expanding datetime
-Original Message- From: Lachlan Hunt [EMAIL PROTECTED] Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Adding one or two additional digits would also enable a closer match with the range of time values allowed in the DOM representation, and would need to be added at the same time as the ± is added.
Re: [whatwg] Expanding datetime
There's an historical precedent that argues in favor of expanding the datetime string. Many calendar utilities limit the date domain to the UNIX one. Thus, entering an anniversary for a wedding that occurred prior to 1970 is the kiss-of-death: there is no way to determine just which anniversary is involved (silver anniversary, paper, ceramic...). A small item? Not to the gift card and gift industries. So an apparently trivial, supposedly non-business limitation had a big effect. Whether or not providing a means to specify dates before the Gregorian Reform or before the beginning of the first millennium will have a business effect is difficult to determine. One thing that can be said is that the applications which would be enabled certainly won't exist if the facilities are not present. Currently, the extreme datetime values (as opposed to the strings) can be specified in Javascript. Producing the corresponding datetime strings from such values should be mandatory. That argues in favor of proper round trip handling: the conversion of extreme datetime strings should be available too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Cline Sent: Thursday, 2008 April 24 13:58 To: Lachlan Hunt Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Expanding datetime -Original Message- From: Lachlan Hunt [EMAIL PROTECTED] Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Adding one or two additional digits would also enable a closer match with the range of time values allowed in the DOM representation, and would need to be added at the same time as the ± is added.
[whatwg] Fwd: Expanding datetime
to list as well -- Forwarded message -- From: David Gerard [EMAIL PROTECTED] Date: 2008/4/24 Subject: Re: [whatwg] Expanding datetime To: WeBMartians [EMAIL PROTECTED] 2008/4/24 WeBMartians [EMAIL PROTECTED]: Whether or not providing a means to specify dates before the Gregorian Reform or before the beginning of the first millennium will have a business effect is difficult to determine. One thing that can be said is that the applications which would be enabled certainly won't exist if the facilities are not present. Currently, the extreme datetime values (as opposed to the strings) can be specified in Javascript. Producing the corresponding datetime strings from such values should be mandatory. That argues in favor of proper round trip handling: the conversion of extreme datetime strings should be available too. What's ODF do? They've dealt with this problem, surely. - d.
Re: [whatwg] Expanding datetime
Ernest Cline wrote: -Original Message- From: Lachlan Hunt [EMAIL PROTECTED] Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? No, I was just trying to emphasise the use cases that some of the datetime features have been included for. I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Please describe the authoring use cases that you are trying to solve and explain how and why authors or end users would benefit from having such dates marked up in a machine readable way, and why would it be in the interest of browser vendors to implement this feature? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Question about the PICS label in HTML5
Anne van Kesteren wrote: On Thu, 17 Apr 2008 11:06:46 +0200, Dan Brickley [EMAIL PROTECTED] wrote: http://wiki.whatwg.org/wiki/RelExtensions Erm, 'For the Status section to be changed to Accepted, the proposed keyword must have been through the Microformats process, and been approved by the Microformats community. ' Is that really so? That's the current proposal. I personally think a W3C Recommendation backing it should be enough as well. If these drafts are destined for W3C specs, then yes, please make that change to your process. Microformats.org should be one of several in-routes here. cheers, Dan -- http://danbri.org/
Re: [whatwg] Expanding datetime
Henri Sivonen: Date form widgets are meant for airline and hotel reservations What about, for instance, adjustable timelines at history websites or virtual skies at astronomic sites?
Re: [whatwg] Expanding datetime
On Fri, 25 Apr 2008 07:54:37 +0800, Christoph Päper [EMAIL PROTECTED] wrote: Henri Sivonen: Date form widgets are meant for airline and hotel reservations What about, for instance, adjustable timelines at history websites or virtual skies at astronomic sites? Hmmm. The ability to show continental drift using a timeline probably doesn't need a datetime (century is usually pretty fine-grained). But virtual skies are pretty important to historical as well as future stuff. There must be about half a billion people who would like to be able to recreate the night skies around Bethlehem in a period between say -0010-01-01 and 0004-01-01 to see if there is something interesting happening. There are various ecological things that are well-suited to timelines stretching back 2009 years. Urban planning and economics is another area that may use the ability to look at things 2009 years ago. Historical weather modelling is another - there are points in history where the date is actually relevant, in particular the ability to match up phenomena known to have occurred in order to synchronise dates calculated according to different and not entirely-known methods. As an historian, these seem useful things to be able to do. It would seem to me as a browser maker that this doesn't actually complicate life a whole lot (I may be wrong - I haven't thought hard about the implications yet). As a standards guy, I do not see that being able to do this would introduce any particular complications (beyond a few more test cases). I am inclined to think that the use cases justify the cost, at least enough to investigate further. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Expanding datetime
There are various ecological things that are well-suited to timelines stretching back 2009 years. Genealogy would seem to be another relatively popular use. -- Charles
