Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add section about when to draw or not a focus ring #6523

Closed
wants to merge 1 commit into from
Closed

Add section about when to draw or not a focus ring #6523

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions source
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -74349,6 +74349,42 @@ END:VCARD</pre>
<pre><code class="html">&lt;div contenteditable autofocus&gt;Edit &lt;strong>me!&lt;/strong>&lt;div></code></pre>
</div>

<h4>Focus rings</h4>

<p>User agents should <dfn>indicate focus</dfn>, such as by drawing a focus ring and matching
<code>:focus-visible</code>, on the currently focused element in the following situations:</p>

<ul>
<li><p>If the user has expressed a preference (such as via a system preference or a browser
setting) to always see a visible focus indicator. (Another option may be for the user agent to
show its own focus indicator regardless of author styles.)</p></li>

<li>
<p>If the currently focused element is a <i>text control</i>, an <span>editing host</span> or
an <span>editable</span> element.</p>

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds very mobile centric way of defining things. I don't think it would appropriate define a normative text based on examples.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alice what do you think about removing the parenthetical?

Copy link

@robdodson robdodson Mar 24, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thinking about this a bit more... I think we originally included that example because just saying something supports keyboard input can be kind of vague. For example, you can press spacebar to click a button, but we don't want buttons to have a focus ring unless interacted with via keyboard.

Really I think we meant "the control expects you to type some characters" which is why we provided that virtual keyboard example. I'm curious if folks have any idea on how best to express that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback.

Good point, this is not very normative text, so I'm going to give a try to a different way to describe this (this is similar to another place on the HTML spec):

If the currently focused element is a text control, an editing host or an editable element.

For the purpose of this point, a text control is a textarea element or an input element whose type attribute is in one of the Date, Local Date and Time, Email, Number, Password, Search, Tel, Text, Time, URL, or Week, states.

I'm going to upload a new version using this text and also updating a little bit the rest (as there was another point referring to "the focused element does not support keyboard input" which is not very clear either.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can explicitly enumerate a set of input types like that. In some OS, for example, type=date may not be keyboard typable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been testing the behavior of different browsers on different platforms.

<select> is a special one. It shows a focus ring in mobile in all browsers in all platforms (iOS and Android), and also shows it on desktop (except on Firefox where it doesn't show it on desktop; and on Chromium that hides it while the pop-up is open, but shows it once you've selected the element). Maybe an option could be to include select on this list and change Firefox behavior on desktop.

Apart from that, things that <input type="date">, despite you cannot use them with the keyboard on mobile, they show a focus ring in both iOS and Android (Chromium and Firefox) while you're selecting the date. Though maybe that's not intentional, but it's the current behavior.

So one option could be to include <select> on the explicit list of things.

Another option I see is to use some open definition, like "the element supports keyboard input" and let browsers decide what to do depending on the platform. Dunno if something like that would be acceptable for normative text.

Any other idea or suggestion is welcomed, as I'm running out of ideas about how to define this thing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if we revise for that case in a generic way "If the control accepts keyboard input such that it would paint typed characters to the screen, or acts as a proxy to selecting from a list of options" is a way to split the difference here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've followed @emilio suggestion on the last version.

So it mentions text control, editing host or editable element.
Defines that text controls are textarea and input with types: email, password, search, text and url.
And then adds "The user agent may draw a focus ring in other elements".

Could that be good enough?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rniwa wdyt?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I understand the ramifications from this spec text, I'm wondering why this text was added at all. The idea of non-editable controls not getting focus ring in WebKit comes from the fact they don't get the focus in the first place, not just the drawing of the focus ring.

<p>For the purpose of this point, a <i>text control</i> is a <code>textarea</code> element or
an <code>input</code> element whose <code data-x="attr-input-type">type</code> attribute is in
one of the
<span data-x="attr-input-type-email">Email</span>,
<span data-x="attr-input-type-password">Password</span>,
<span data-x="attr-input-type-search">Search</span>,
<span data-x="attr-input-type-text">Text</span>, or
<span data-x="attr-input-type-url">URL</span>
states.</p>

<p>The user agent may draw a focus ring in other elements.</p>
</li>

<li><p>If the user interacts with the page via keyboard or some other non-pointing device,
<span>indicate focus</span>. (This means keyboard usage may change whether the focus ring is
drawn even if focus isn't affected).</p></li>

<li><p>If a script caused focus to be set, and the previous time the <span>focus update
steps</span> have been run <var>focus trigger</var> was not "<code
data-x="">click</code>".</p></li>
</ul>



<h3>Assigning keyboard shortcuts</h3>
Expand Down