Consider conformance guidance for dialogs which contain large blocks of text

[scottaohara]

Per the dialog initial focus proposal, this unresolved comment has been moved here for further discussion:

In particular, authors must not include large blocks of text directly in dialog elements, as this is likely to cause the dialog element itself to overflow. Instead, a scrollable container element should be used, inside the dialog, to contain this text.

@domenic:

It seems difficult to come up with an automated conformance-checker check for this. But I think it's still worth expressing, even if it's not something that can be automated.

cc @sideshowbarker for thoughts on conformance checker rules concerning this topic.

[Yay295]

Why not make the dialog element scrollable by default, with max width and height to the screen width and height? I see there's a note in that proposal to not do that, so maybe it's already been discussed, but a reason isn't stated in the proposal.

[domenic]

Regarding the question of which issues in #4184 (comment) should be considered blocking for writing up a spec of https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal#initial-dialog-focus-logic : I think we should come up with an opinion here, but it is a minor question and should not block writing up a spec PR, as it's just a question as to whether to include or not include a single sentence in that PR.

I am interested in the opinion of folks like @sideshowbarker and @zcorpan on whether the proposed conformance requirement in the OP would be useful.

[zcorpan]

I object to this proposal.

I think it is inappropriate for HTML to require things about the styling in general. Document conformance requirements in HTML do not and should not have a CSS dependency. On the theoretical purity level, CSS is optional, and therefore the conformance of an HTML document should not change depending on whether CSS is applied. On a more practical level, the styling can change over time or depend on various things such as the viewport size, preferences for light mode vs dark mode, preferences for reducing motion, support for certain CSS features, and so on.

Recommendations for how to make dialogs accessible, including styling, seems appropriate for WCAG or so.

I would be OK with non-normative styling suggestions in a note in HTML, though.

[sideshowbarker]

Since cases of document-conformance requirements that we can’t do automated checking for don’t need any support in conformance-checking tools, then from my point of view as HTML-checker maintainer, they’re just a no-op that I pay no attention to.

But in general from the point of view of trying to provide the right guidance for developers, I’m not very fond of adding requirements to the HTML spec that we can’t do automated checking for — because that leaves developers without any means to discover that they’re doing something that the spec formally states is non-conformant (except for those few developers who’ve happened to have read the spec).

So I think if we were to put wording about this for developers into the spec, it shouldn’t be normative — not even “should” — but would be better worded as a suggestion.

Recommendations for how to make dialogs accessible, including styling, seems appropriate for WCAG or so.

I was about to say the same thing. It seems like the WAI guides and tutorials are the place where developers already know and expect to find this kind of guidance — rather than in the HTML spec.

[scottaohara]

if anything is done in HTML, then it seems the following would be the way to go

I would be OK with non-normative styling suggestions in a note in HTML, though.

[josepharhar]

if anything is done in HTML, then it seems the following would be the way to go

I would be OK with non-normative styling suggestions in a note in HTML, though.

I'm adding a non-normative note with this text in the pr:
#8199

Another important aspect of user behavior is whether dialogs are scrollable or not. In some cases, overflow (and thus scrollability) cannot be avoided, e.g., when it is caused by the user's high text zoom settings. But in general, scrollable dialogs are not expected by users, and authors should attempt to avoid them. In particular, authors must not include large blocks of text directly in dialog elements, as this is likely to cause the dialog element itself to overflow. Instead, a scrollable container element should be used, inside the dialog, to contain this text.

I suppose that I might have to change it to not use "must" in order for it to be non-normative, but we can figure that out in the PR.