Re: [whatwg] summary/details - proposal
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] summary/details - proposal
On 7 April 2014 20:06, Ian Hickson i...@hixie.ch wrote: Should there be a particular need for an accessible name for the details control, ARIA can be used to set the name. But I must admit to not understanding why you would need that in practice, if the page is well written. (I find most pages that use accessible labels in situations such as this tend to be poorly written for non-AT users.) All controls are expected to have an accessible name and it is expected that the author is able to assign one. this is accessibility 101 across all platforms. Lack of an accessible name or a generic accessible name or an ambiguous accessible name causes issues for users. What's the mechanism by which the anonymous control for details can be assigned an accessible name? Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. avoiding unnecessary recourse to web component use is a reasonable and expected goal - built in vs bolt on accessibility is better. Having to use a web component to overcome the inability to make a html control usable without relying on CSS and Js and ARIA is unfortunate, and as you said yesterday once you're using custom components you've pretty much sacrificed the ability for the web to work without css and js, especially if you don't have a fallback element... http://krijnhoetmer.nl/irc-logs/whatwg/20140407#l-396 -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] summary/details - proposal
On Tue, Apr 8, 2014 at 5:25 AM, Steve Faulkner faulkner.st...@gmail.com wrote: avoiding unnecessary recourse to web component use is a reasonable and expected goal - built in vs bolt on accessibility is better. Having to use a web component to overcome the inability to make a html control usable without relying on CSS and Js and ARIA is unfortunate, and as you said yesterday 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? 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. I would strongly object to any suggestion that summary should only toggle details when you click on the disclosure triangle, unless you add some additional markup like label. That would be terrible UI. ~TJ
Re: [whatwg] summary/details - proposal
-- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 6 April 2014 05:11, Ian Hickson i...@hixie.ch wrote: On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. It also provides the best choice for users, large click area and focus ring, Its also simple for authors in the majority of use cases. while on Mac OSX only the disclosure triangle (approx 13X13px) itself is clickable and has a focus rectangle. details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, how so? with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? not to mention all the problems it would cause with the existing label definitions. may be making the details element a labelable control would be simpler, as its be definition an interactive control. would it cause problems for existing label definitions? details id=x summary label for=xFoo/label /summary ... /details -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
On Sun, 6 Apr 2014, Steve Faulkner wrote: On 6 April 2014 05:11, Ian Hickson i...@hixie.ch wrote: On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, how so? All that should be necessary is: details summary Foo /summary ... /details Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? If doing so matches the platform conventions, any non-interactive text in the summary would open the widget. in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
-- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 6 April 2014 21:08, Ian Hickson i...@hixie.ch wrote: On Sun, 6 Apr 2014, Steve Faulkner wrote: On 6 April 2014 05:11, Ian Hickson i...@hixie.ch wrote: On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed Not what I said, but the current implementations use of summary as the interactive element matches, the first example under usage patterns http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx#patterns details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, how so? All that should be necessary is: details summary Foo /summary ... /details Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. for the case details summary Foo input Bar /summary ... /details whats the disclosure label? what about? details summary labelinput Bar /label/summary ... /details in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. does this also extend to the author being able to provide an accessible name for the control? Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
On Mon, 7 Apr 2014, Steve Faulkner wrote: All that should be necessary is: details summary Foo /summary ... /details Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. for the case details summary Foo input Bar /summary ... /details whats the disclosure label? The text Foo, a text field, and the text Bar. If by disclosure label you mean the parts which, on certain platforms, when clicked, would toggle the open state, then that depends on the platform, but I would expect the Foo and Bar text to be good candidates, since they're otherwise inert. what about? details summary labelinput Bar /label/summary ... /details Here there's no non-interactive text, so there's no text to target. in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. does this also extend to the author being able to provide an accessible name for the control? Should there be a particular need for an accessible name for the details control, ARIA can be used to set the name. But I must admit to not understanding why you would need that in practice, if the page is well written. (I find most pages that use accessible labels in situations such as this tend to be poorly written for non-AT users.) Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] summary/details - proposal
note: bringing this to the whatwg list to elicit feedback from implementers and other interested parties that are not involved in the discussion at the W3C Currently the implementation(s) of summary/details elements do not match the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element In the spec, the details element is interactive content, the summary is not, its a summary, caption, or legend. in webkit/blink the summary element is the interactive element (when pressed it opens/closes the details element) This is good because it provides a large default hit region to activate the control example to try in chrome/safari/opera http://codepen.io/stevef/pen/CyauJ/ So as the spec/implementations are at odds, the implementations need to change to match the spec or the spec needs to change to match implementations or the spec needs to change to accommodate the positive aspects of the current implementations while allowing for other use cases An issue with current implementations is that when the summary element includes other interactive elements (as it is allowed to), clicking on them results in the details element being opened/closed (although this can be overcome via scripting). example to try in chrome/safari/opera http://codepen.io/stevef/pen/xjJiy/ Issues with the current spec text: The interactive part of the details element is the disclosure triangle ► which is supposed to be an anonymous control in the shadow DOM The summary itself is not interactive, so only the triangle provides the actionable control. the summary text which is effectively the label for control does not activate the control. There is no method provided to associate a label with the anonymous control that can (a) provide an increased hit region and (b) provide an explicitly associated label for the anonymous control. Given that what we want to provide for the use case of having controls inside the summary, after discussion around the issue[1], I have proposed the following: details summary id=x label for=xFoo/label /summary ... /details what this does is provide the author with the ability to add an explicit label (providing the acc name) to the details control which also increases the click region for improved accessibility/usability, while still allowing interactive content inside the summary element. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25140 feedback welcome! -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] summary/details - proposal
On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Given that what we want to provide for the use case of having controls inside the summary, after discussion around the issue, I have proposed the following: details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, not to mention all the problems it would cause with the existing label definitions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
