- From: Simon Pieters via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Oct 2018 09:07:36 +0000
- To: public-css-archive@w3.org
zcorpan has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-forms] Allow making <button> a real inline == Use cases & requests from web developers == * https://twitter.com/ned/status/1051798190951940096 > button { display: inline; } should work. > Yes, I want to make buttons that wrap lines like a normal inline elements, but retain the semantics and accessibility of a button. > that's the point: it should be able to just flow its contents, it's crucial for action items inserted in text as pseudolinks. For now we have to hack around with `<span role=button tabindex=0 onkeydown=handleEnterOrSpace(event) onclick=handleClick(event)>` or just use `<a href=#>` * https://twitter.com/micahgodbolt/status/1047218367432544257 > So, what if you have some long text in a paragraph where on click, it performs an action (not an href) > > You'd use a `<button>` right? > > Okay, then how would you make that button LOOK like text in a paragraph. > > https://codepen.io/micahgodbolt/pen/zmrxQd * https://www.scottohara.me/blog/2018/10/03/unbutton-buttons.html This post discusses the problem, and explores styling buttons with `display: contents` but notes that it loses the ability to receive keyboard focus and there's no accessibility node so it's not exposed as a button to screen readers. Defining layout model for buttons == In https://github.com/whatwg/html/issues/4081 I'm working on specifying the layout model that buttons use. Currently my working draft for this is part of https://docs.google.com/document/d/1FE5YIoirPKxYbbnMd8kS6w39M8bzLTl5tf4wwOxR1wc/edit?usp=sharing In particular, buttons have an inner anonymous box that is a block formatting context, and I think this is the cause of the inability to make buttons be inline. Proposal == One way to solve this could be to add a pseudo-element to target the anonymous box, so that web developers can set it to 'display: inilne'. The button would still be focusable and be exposed the same in the accessibility tree. Thoughts? cc @tkent-google @MatsPalmgren @hober @FremyCompany Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3226 using your GitHub account
Received on Friday, 19 October 2018 09:07:42 UTC