Remove "control group" concept from HTML #3647

TakayoshiKochi · 2018-04-27T08:26:13Z

The control group concept existed to give special focus behavior to

elements, treating them on par with Documents in terms of allowing focus to shift inside of them. However, this was never implemented in user agents.

This change removes the control group concept, instead using Document
directly. This allows some simplifications, e.g. because the first
focusable area of a non-empty Document is always the Document's
viewport.

The change uncovered some areas of the spec that were potentially wrong
or unclear when considering focus around documents. We will follow up on
that in #3675. But for now we keep
the same algorithms, just without s.

Fixes #2171.

/interaction.html ( diff )
/interactive-elements.html ( diff )

As focus "control group" existed for explaining the behavior of `<dialog>` elements, but it has never implemented in UAs. This change mostly swaps "control group" with "document" where appropriate. And now `<dialog>` element cannot be a focusing target unless it has explicit tabindex.

domenic · 2018-04-30T20:06:32Z

source


   <li>

    <p>Let <var>control</var> be the first non-<span>inert</span> <span>focusable area</span> in
-    <var>subject</var>'s <span>control group</span> whose <span>DOM anchor</span> has an <code
+    <var>subject</var>'s descendants whose <span>DOM anchor</span> has an <code
    data-x="attr-fe-autofocus">autofocus</code> attribute specified.</p>


I think this should be rephrased to:

Let control be the first descendant element of subject, in tree order, that is not inert and has the autofocus attribute specified.

No need to involve focusable areas anymore.

domenic · 2018-04-30T20:06:53Z

source

    data-x="attr-fe-autofocus">autofocus</code> attribute specified.</p>

    <p>If there isn't one, then let <var>control</var> be the first non-<span>inert</span>
-    <span>focusable area</span> in <var>subject</var>'s <span>control group</span>.</p>
+    <span>focusable area</span> in <var>subject</var>'s descendants.</p>


Similarly:

... then let control be the first non-inert descendant element of subject, in tree order.

domenic

A few nits, but overall great work!! Very excited for this; thanks so much.

domenic · 2018-04-30T20:11:31Z

source

-  is <dfn>expressly inert</dfn> if it is <span>inert</span> and its nearest ancestor <span>control
-  group owner object</span> is not <span>inert</span>.</p>
+  is <dfn>expressly inert</dfn> if it is <span>inert</span> and its <code>Document</code> is not
+  <span>inert</span>.</p>

  <div class="example">


This example is now no longer accurate. I think it can be removed since the concept is simpler to understand now.

Removed this example <div> altogether.

domenic · 2018-04-30T20:12:24Z

source

-  <dfn>focused area of the control group</dfn>. Which control is so designated changes over time,
-  based on algorithms in this specification. If a <span>control group</span> is empty, it has no <span
-  data-x="focused area of the control group">focused area</span>.</p>
+  <p>One <span>focusable area</span> <span>in a document tree</span> is designated the <dfn>focused


I don't think we need to link "in a document tree" here since we're not using it as a predicate. (That is, we're not testing whether something is "in a document tree".)

I would instead just say "in each document tree" and link to "document tree".

Looks like there is no definition for the term "document tree", and "document tree" is exclusively used in a phrase "in a document tree" in the spec.

Does

One focusable area in each document is ...

without link from "document" look good?

domenic · 2018-04-30T20:12:51Z

source

-  data-x="focused area of the control group">focused area</span>.</p>
+  <p>One <span>focusable area</span> <span>in a document tree</span> is designated the <dfn>focused
+  area of the document</dfn>. Which control is so designated changes over time, based on algorithms
+  in this specification. If a <code>Document</code> has no <span>focusable area</span>, it has no


has no focusable area -> has no focusable areas

domenic · 2018-04-30T20:15:24Z

source

-  depth-first traversal of the box tree. <ref spec=CSS></p>
+  anchors</span>. <span data-x="focusable area">Focusable areas</span> with the same <span>DOM
+  anchor</span> in a <code>Document</code> are ordered relative to their CSS box's relative
+  positions in a pre-order, depth-first traversal of the box tree. <ref spec=CSS></p>


Pre-existing problem but maybe fix while you're here: box's -> boxes'

domenic · 2018-04-30T20:19:24Z

source

-    <var>candidate</var> be the designated <span>focused area of the control
-    group</span>.</p>
+    <p>Otherwise, let <var>candidate</var> be the designated <span>focused area of the
+    document</span>.</p>


This step is wrong if there is no focused area. In that case, we should leave it as the document.

If you want I would suggest restructuring this algorithm a bit to make things easier:

Let candidate be ...

While candidate's focused area is a browsing context container with..., set candidate to the activate document of...

If candidate has a focused area, set candidate to candidate's focused area.

Return candidate.

Good catch, and almost adopted your comment, except 2. (left the original "redo this step" phrasing).

domenic · 2018-04-30T20:21:33Z

source

@@ -73000,7 +72934,7 @@ END:VCARD</pre>
  </ol>

  <p>User agents must <span>immediately</span> run the <span>focusing steps</span> for a <span>focusable area</span>,
-  <code>dialog</code>, or <span>browsing context</span> <var>candidate</var> whenever the
+  or <span>browsing context</span> <var>candidate</var> whenever the


Remove the comma from the previous line now that there's only two items in the list.

domenic · 2018-04-30T20:22:45Z

source

-    (if the <span>control group owner object</span> is a <code>Document</code>, this will always be
-    a <span>viewport</span>).</p>
+    focus target</var> be the first <span>focusable area</span> of its <code>Document</code>,
+    this will always be a <span>viewport</span>).</p>


This should be simplified to just "then let new focus target be its Document's viewport".

Done. Also removed the closing parenthesis.

domenic · 2018-04-30T20:26:30Z

source


  <p class="example">For example, this might happen because an element is removed from its
  <code>Document</code>, or has a <code data-x="attr-hidden">hidden</code> attribute added. It might
  also happen to an <code>input</code> element when the element gets <span
  data-x="concept-fe-disabled">disabled</span>.</p>

-  <p class="example">In a <code>Document</code> without <code>dialog</code> elements, whose <span
-  data-x="focused area of the control group">focused area</span> is a <code>button</code> element,
+  <p class="example">In a <code>Document</code>, whose <span


Can remove the comma now.

Line breaking also seems off here; remember to break on spaces (even if the spaces are inside an attribute).

domenic · 2018-04-30T20:57:40Z

source

  relative to each other. The order in the <span>sequential focus navigation order</span> does not
-  have to be related to the order in the <span>control group</span> itself. If a <span>focusable area</span> is
-  omitted from the <span>sequential focus navigation order</span> of its <span>control group</span>, then
+  have to be related to the order in the <code>Document</code> itself. If a <span>focusable area</span> is


I would change "order" to "tree order" (and make it a link) since it's now about documents which have a well-defined concept of order.

domenic · 2018-04-30T21:00:34Z

source

    focus navigation order</span>.</p>

-    <p>The <dfn>home control group</dfn> is the <span>control group</span> to which <var>starting point</var> belongs.</p>
+    <p>The <dfn>home document</dfn> is the <code>document</code> to which <var>starting point</var> belongs.</p>


Capital "D"

TakayoshiKochi · 2018-05-07T07:27:54Z

Thanks for the review! I was OOO last week and am back again.
Except for places I added some reply comments, basically I adopted what you commented.
PTAL.

domenic · 2018-05-08T23:50:23Z

source


-  <p><dfn>Focus fixup rule</dfn>: When the designated <span data-x="focused area of the control


I realized that now we are only worrying about documents, the first focusable area is always the viewport. So I will push a commit that simplifies this.

domenic

I pushed a few small fixups; please take a look and tell me if they look right? If so we'll go ahead and merge this.

Proposed commit message:

Remove "control group" concept from the focus model

The control group concept existed to give special focus behavior to
<dialog> elements, treating them on par with Documents in terms of
allowing focus to shift inside of them. However, this was never
implemented in user agents.

This change removes the control group concept, instead using Document
directly. This allows some simplifications, e.g. because the first
focusable area of a non-empty Document is always the Document's
viewport.

The change uncovered some areas of the spec that were potentially wrong
or unclear when considering focus around documents. We will follow up on
that in https://github.com/whatwg/html/issues/3675. But for now we keep
the same algorithms, just without <dialog>s.

Fixes #2171.

TakayoshiKochi · 2018-05-11T10:45:42Z

Thanks!
I've looked at your changes and they look good.

I copied your commit message to the top message (with small tweaks like adding backticks
around dialog element), but I'm not sure it will be used as the git's commit message...

The PR whatwg#3647 removed "control group" concept, and most of them were converted to Document. The "control group" could be empty when e.g. no focusable element in a dialog element, but for a document without any focusable element, its viewport is still focusable. Remove sentences talking about such a non-existent Document condition.

The PR #3647 removed "control group" concept, and most of them were converted to Document. The "control group" could be empty when e.g. no focusable element in a dialog element, but for a document without any focusable element, its viewport is still focusable. Removes sentences talking about such a non-existent Document condition. Fixes #3675.

The PR whatwg#3647 removed "control group" concept, and most of them were converted to Document. The "control group" could be empty when e.g. no focusable element in a dialog element, but for a document without any focusable element, its viewport is still focusable. Removes sentences talking about such a non-existent Document condition. Fixes whatwg#3675.

It seems a remnant of control groups, which were removed in whatwg#3647. All uses are replaced with the concept of "inert". Also cleaning up "When a key event is to be routed in a top-level browsing context", which also seems to have remnants of when control groups allowed inert elements inside an inert dialog to be focusable. Fixes whatwg#7564.

TakayoshiKochi requested a review from domenic April 27, 2018 08:27

domenic reviewed Apr 30, 2018

View reviewed changes

domenic requested changes Apr 30, 2018

View reviewed changes

Address review comments.

99e9409

domenic mentioned this pull request May 8, 2018

Probably-wrong focus requirement #3675

Closed

domenic reviewed May 8, 2018

View reviewed changes

domenic added 3 commits May 8, 2018 19:59

Small tweaks

990d32f

Simplify focus fixup rule

172e2c3

Missed one tidy up

fb55814

domenic approved these changes May 9, 2018

View reviewed changes

domenic added topic: focus removal/deprecation Removing or deprecating a feature labels May 9, 2018

domenic merged commit 90a60b2 into whatwg:master May 14, 2018

TakayoshiKochi deleted the remove_control_group branch May 16, 2018 03:29

TakayoshiKochi mentioned this pull request Jul 5, 2018

Remove sentences about document with no focusable area #3798

Merged

scottaohara mentioned this pull request Jul 17, 2018

Review concept of control group w3c/html#1516

Closed

Loirooriol mentioned this pull request Feb 1, 2022

Remove concept of expressly inert? #7564

Closed

Loirooriol mentioned this pull request Feb 2, 2022

Remove concept of "expressly inert" #7565

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove "control group" concept from HTML #3647

Remove "control group" concept from HTML #3647

TakayoshiKochi commented Apr 27, 2018 •

edited by pr-preview bot

Loading

domenic Apr 30, 2018 •

edited

Loading

domenic Apr 30, 2018 •

edited

Loading

domenic left a comment

domenic Apr 30, 2018

TakayoshiKochi May 7, 2018

domenic Apr 30, 2018

TakayoshiKochi May 7, 2018 •

edited

Loading

domenic Apr 30, 2018

domenic Apr 30, 2018

domenic Apr 30, 2018

TakayoshiKochi May 7, 2018

domenic Apr 30, 2018

domenic Apr 30, 2018

TakayoshiKochi May 7, 2018

domenic Apr 30, 2018

domenic Apr 30, 2018

domenic Apr 30, 2018

TakayoshiKochi commented May 7, 2018

domenic May 8, 2018

domenic left a comment •

edited

Loading

TakayoshiKochi commented May 11, 2018


		<p><dfn>Focus fixup rule</dfn>: When the designated <span data-x="focused area of the control

Remove "control group" concept from HTML #3647

Remove "control group" concept from HTML #3647

Conversation

TakayoshiKochi commented Apr 27, 2018 • edited by pr-preview bot Loading

domenic Apr 30, 2018 • edited Loading

Choose a reason for hiding this comment

domenic Apr 30, 2018 • edited Loading

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TakayoshiKochi May 7, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TakayoshiKochi commented May 7, 2018

Choose a reason for hiding this comment

domenic left a comment • edited Loading

Choose a reason for hiding this comment

TakayoshiKochi commented May 11, 2018

TakayoshiKochi commented Apr 27, 2018 •

edited by pr-preview bot

Loading

domenic Apr 30, 2018 •

edited

Loading

domenic Apr 30, 2018 •

edited

Loading

TakayoshiKochi May 7, 2018 •

edited

Loading

domenic left a comment •

edited

Loading