CSS `@config`

at-config.md

This is a bit of controversial idea that has been lingering in the back of my mind. Basically, I’ve seen the need for authors to configure some things on a page, and it would be nice if they could do that from within CSS.

For example, MPA View Transitions we discussed yesterday, or other things that typically now go into a meta tag in the markup. Beyond VTs, I am thinking of the switch to control the viewport resizing behavior when the virtual keyboard gets shown (see https://drafts.csswg.org/css-viewport/#interactive-widget-section)

I haven’t thought this entirely through (insert chuckle by some of you here) but am thinking of an @config at-rule for that. In it you could put some things like the interactive-widget configuration.

@config {
  interactive-widget: resize-viewport;
}

To make it a bit more controversial – because why not? – maybe it could also be extended to include some global rendering settings/switches? I am thinking of things like being able to choose the type of scrollbars, change where PosFixed should be laid out against, or maybe even crazy things like disabling margin collapsing entirely (:evil:)?

@config {
  scrollbar-type: overlay;
  margin-collapse: off; 
  view-transitions: same-page, same-origin;
  interactive-widget: resize-viewport;
  fixed-pos: layout-viewport;
  …
}

There of course should be some requirements concerning this at-rule. Most values in it should only be set once, and cannot be changed on the fly. For example, you don’t want to change the scrollbar type during the lifetime of a page. Some descriptors in it otoh might be eligible to being changed. I am thinking of the view transitions settings. For that to work the at-rule would need to be able to cascade.

I know something similar has been suggested in the past. There’s a @css3 entry in the FAQ on the wiki – https://wiki.csswg.org/faq#versioning-css-fixing-design-mistakes

It was discarded at the time, but I think this might work in todays browsers;

• It is not an all or nothing opt-in, but allows you to cherry pick what you want to change.
• We have at-rule(), which allows you to sniff out support.

On the downside, I do definitely see that things like changing margin collapsing would but a burden on devs, as they would need to maintain two code paths for quite some time.

And yes, I totally expect this to get shot down but sometimes we need a controversial thing on the agenda, no?