Re: [whatwg] summary/details - proposal

2014-04-10 Thread Steve Faulkner
On 8 April 2014 21:54, Tab Atkins Jr. jackalm...@gmail.com wrote:

 I still don't understand.  Do you think that what Hixie is saying
 (about clicking on non-interactive text in summary toggling the
 details) is wrong?


nope.



 The behavior that Hixie describes is roughly what implementations do
 today.  In Blink, clicking on any bare text in the summary toggles
 the details, while clicking on an input does not.  However, Blink
 current behavior with label is different - it basically ignores the
 presence of the label, as far as I can tell, and still toggles the
 details even if the label is redirecting the click to an input.


Implementations today have the summary element as the focusable/interactive
element.
this has several pros/cons what I am trying to achieve is to have the pros
defined as part of the feature.


I would strongly object to any suggestion that summary should only
 toggle details when you click on the disclosure triangle,


I cannot agree more, which is why I have brought up the issue here and
elsewhere. Hixie talks about platform conventions and UAs deciding,  and as
I have pointed out several times the OSX platform convention is just what
you describe. and as you say would be terrible UI.

unless you
 add some additional markup like label.  That would be terrible UI.


I would prefer that the summary element acted as the label the disclosure
triangle of the details element, thus providing a reasonable default click
area and focus are and source for the accessible name of the control. I see
a few issues, which is why I have suggested allowing the use of label (to
provide both a clickable area that can be assigned by the author and
provide an explicit method to assign an accessible name)

1. When the summary element also includes links or other controls each with
their own accessible name, providing an unambiguous accessible name for the
disclosure triangle becomes problematic.
2. I have observed that assigning an accessible name for a control in the
shadow DOM from the DOM is not possible.  Thus my question to the
list/hixie:

What's the mechanism by which the anonymous control for details can be
assigned an accessible name?




--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/


Re: [whatwg] input type=number for year input

2014-04-10 Thread Ian Hickson
On Wed, 19 Feb 2014, Michael[tm] Smith wrote:
 Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +:
  On Tue, 18 Feb 2014, Jonathan Watt wrote:
  
   I wonder if it would be that bad to have a 'year' type to compliment 
   the 'month' and 'day' types...
  
  This has come up a few times, but so far the use cases have not been 
  compelling enough. This is probably the most compelling use case, but 
  even here, I don't know that it's that compelling.
  
  I would be interested in hearing more about the locales where not 
  using separators even for four digits is bad/suboptimal. If it wasn't 
  for those, I would say that just not using separators for four-digit 
  numbers would be an easy and effective solution.
 
 The following info seems relevant -
 
   http://www.thepunctuationguide.com/comma.html#numbers
   Most authorities, including The Associated Press Stylebook and The Chicago
   Manual of Style, recommend a comma after the first digit of a four-digit
   number. The exceptions include years, page numbers, and street addresses.
 
 To me that appears to be a strong argument that formatting of years is 
 in fact clearly an exception, and that's compelling enough to warrant 
 having a type for them separate from the normal number type (in which 
 four-digit numbers would instead have a separator, to follow existing 
 longstanding conventions).

Interesting.

For street addresses, we are moving in the direction of larger fields not 
smaller fields, so I'm not too worried about that use case. (I do know one 
form that looks just for a street address number, but presumably it has to 
handle non-numeric data anyway, as in 23A.)

If that left just page numbers, I'd probably ignore it, since the use 
cases are pretty limited there. But years are clearly a major use case.

Doing further research along these lines, it seems that it's specifically 
page numbers and years _that are four digits long_ that are at issue, when 
it comes to English:

| MLA style is to use a comma in four-digit numbers except in page 
| numbers, line numbers, addresses, and years, unless the year has more 
| than four digits, such as 10,000 BCE.
 -- http://www.esc.edu/online-writing-center/resources/punctuation/commas/

Though some people say that applies to more than just years and page 
numbers:

| Use commas to separate groups of 3 numbers in numbers of 5 digits or 
| more unless decimals are used. The comma in a 4-digit number may be 
| omitted.
 -- http://mtdesk.com/Numbers

However, in other languages, as Karl showed, the pattern is different.

As I see it, we have two possible paths:

1. We consider this a stylistic issue, and we add something to CSS to make 
it possible to control the formatting of numbers in input type=number. 
Then, someone doing a page-number control in English can use CSS to make 
it not include commas in four-digit numbers but include numbers otherwise, 
and so forth.

2. We consider this a semantic issue, and we add one or more new input 
types to handle the new smenatics. For example, we add type=year and 
type=page-number.

We can also follow a combinations of both, providing a new control for 
the cases that need more than just style, and providing style for the 
cases that are just presentational.


On Wed, 19 Feb 2014, Jukka K. Korpela wrote:
 
 The point is that year numbers aren't really numbers in a normal 
 sense, any more than car plate numbers, credit card numbers, product 
 numbers, or social security numbers are. Surely they can be regarded as 
 numbers, but so can car plate numbers and the others.

On Wed, 19 Feb 2014, Smylers wrote:
 
 Except that years do actually form a sequence, and it's possible to 
 perform maths on them; for instances, subtracting one year from another 
 yields a duration, which is a meaningful quantity, whereas subtracting a 
 couple of credit card numbers is completely useless.

On Wed, 19 Feb 2014, Jukka K. Korpela wrote:
 
 Mathematically, you are right, but input types aren't based on general 
 properties of quantities but on practical classification of input data. 
 All the examples I gave, including year numbers, are normally input by 
 typing the digits - in contrast with, say, using a color picker, a data 
 picker, or a slider.

Your annual income, when enterested into an electronic tax form, is 
usually input by typing the digits, but it's definitely a number. I 
think the only way, in western locales, that years differ from other 
numbers is with respect to formatting, and that's not unique to years, as 
Mike pointed out (c.f. page numbers).


On Wed, 19 Feb 2014, Smylers wrote:
 
 There are situations where up/down arrows makes sense on years. For 
 instance, a chart of various baby names could have a box for the year 
 currently being displayed, and it's handy to be able to nudge that along 
 by a year at a time to see it change, without having to manually retype 
 the year. Or when displaying one year's tax return, with the ability to 
 display other