I am confused about control groups and control group owners

[domenic]

The spec currently says:

Each focusable area belongs to a control group. Each control group has an owner.

And tells us basically that Documents and dialogs are control group owners. It then says:

Each control group owner object owns one control group (though that group might be empty).

I am not sure if the intent of this statement is that control groups are 1:1 with control group owners. If it is, then this needs to be clarified. I would like to work on a PR for that.

If they are not 1:1, then I am really lost, and could use an example.

@TakayoshiKochi, @Hixie, can you help me understand this?

[Hixie]

It sounds like it means they're 1:1, yes.

[TakayoshiKochi]

I'm also confused about "control group", too. You are not alone.
(sorry, the comment below become somewhat random notes of my understanding...)

My primary source of confusion is that what a "control group" is for is not clearly defined.
A "control group" is defined as a "certain" group, but what it means is scattered widely in the focus section.

I'd expect that "control group" would be used for scoping tabindex, but in 6.4.3 The tabindex attribute, "control group" isn't used at all.

Then in 6.4.5,

Each control group has a sequential focus navigation order, ...

So comparison of two tabindices make sense only when the two elements are in the same control group, but is not mentioned at all.

It's also hard for me to follow how the sequential focus navigation "hops" from one control group to another.

At the bottom of sequential focus navigation,
in sequential navigation search algorighm:

\2. If candidate is a browsing context container, then let new candidate be the result of running the sequential navigation search algorithm with candidate's nested browsing context as the first argument, direction as the second, and sequential as the third.

is probably the statement when a "hop" happens, but it doesn't use "control group" at all.
And at this point I was totally at a loss what control group is meant for.

I thought the "control group" was introduced to explain <dialog> in the spec, but
Chrome (the only browser that implements <dialog>) doesn't internally have any idea
about "control group" and does nothing special about focus navigation for <dialog> (yet?).

Maybe it was introduced for multiple frames in a document first, and later adapted for <dialog>?
I haven't dug the history of HTML spec yet.

[domenic]

@TakayoshiKochi I tried to clarify the situation in #747; would appreciate your review there. It seems like control groups are mainly used to distinguish things like multiple frames ("Document object that have browsing contexts") and also to make dialogs somehow top-level ("dialog elements that have an open attribute specified and that are being rendered"). I think the dialog part is about making sure that when you tab through an open, being-rendered dialog, when you hit the bottom of the dialog, you go back to the top.

So comparison of two tabindices make sense only when the two elements are in the same control group, but is not mentioned at all.

I think you are right that it would be good to mention the control group concept inside the section on tabindex. Right now it is implicit, since tabindex is used for sequential focus navigation, which is very dependent on the control group concept. I will add that to #747.

Upon actually going to do this, it seems like it is kind of redundant. It is hard to add such a note without just redefining what sequential focus navigation means. So it is better for people to just follow the link.

It's also hard for me to follow how the sequential focus navigation "hops" from one control group to another.

I think the passage you found is about the scenario <button>foo</button> <iframe src="foo.html"></iframe>: it is talking about how when you tab from the button, you then tab into the iframe. Here the <iframe> element is the browsing context container. The control group concept then gets used when that step 2 recursively calls the "sequential navigation search algorithm", where in step 1 "starting point is a browsing context" is now true. It tell us that we should look at the iframe's active document's primary control group, which is usually the document, but if there is a dialog up, then we should go into the dialog.

I thought the "control group" was introduced to explain <dialog> in the spec, but
Chrome (the only browser that implements <dialog>) doesn't internally have any idea
about "control group" and does nothing special about focus navigation for <dialog> (yet?).

Hmm, you are right. (http://jsbin.com/vekazimoje/edit?html,output to confirm.) I think the spec is intending that, even for non-modal dialogs, when the dialog is open you should only tab through the dialog's controls. The difference between non-modal and modal dialogs is that modal dialogs make everything else inert, so even if you explicitly focus another control outside the dialog (e.g. by clicking it with the mouse) nothing should happen with modal dialogs.

Do you think that is something Chrome is interested in implementing? Or should we get rid of that in the spec? It seems like a pretty reasonable design. But maybe it is better to use showModal() if you want to trap the sequential focus navigation?

[TakayoshiKochi]

Thanks for the clarification!

I was confused that "browsing context" and "control group owner object" could be the same.
<iframe> is the browsing context container, its contentWindow is the browsing context, and its countentDocument is the "control group owner object", am I correct?

Then the change in #744 looks good.

For <dialog>, a slightly modified version of yours http://jsbin.com/tojolefele/edit?html,output is
much confusing, as the tab navigation goes back and forth between <dialog> and document.
So yes, I think Chrome have to implement <dialog>'s control group as spec'ed.

[domenic]

I was confused that "browsing context" and "control group owner object" could be the same.
<iframe> is the browsing context container, its contentWindow is the browsing context, and its countentDocument is the "control group owner object", am I correct?

Yep!

For <dialog>, a slightly modified version of yours http://jsbin.com/tojolefele/edit?html,output is
much confusing, as the tab navigation goes back and forth between <dialog> and document.
So yes, I think Chrome have to implement <dialog>'s control group as spec'ed.

Cool, glad you think so :). Filed https://bugs.chromium.org/p/chromium/issues/detail?id=590745