[Brainstorm] Declarative responsive markup

[gregwhitworth]

While discussing issue #559 there was a recognition that panelsets is raising an interesting pattern that has existed on the platform since its inception that a developer will want to possible change not only the visual representation but the markup as well. @jonathantneal raised a scenario that users engage with consistently that is similar in navigation when real-estate changes normally between that of desktop and mobile form factors. This can be seen across the web, here is just one such example using ESPN:

Narrow viewport:

Wider viewport:

These types of scenarios may not only change the visual layout but modify the DOM as well as behavior do to these DOM modifications.

This will be achieved today by utilizing Javascript with the matchMedia API and then making the necessary DOM modifications. That said, most templating languages these days handle these types of solutions somewhat declaratively through if/else directives. Here is one example using Nunjucks:

{% if foo.bar == 5 %}
      You've exceeded the amount, you currently have {{foo.barr}} items in your cart.
{% endif %} 

One can then imagine the web platform not doing a 1:1 to full access to all JS vars but evaluations akin to what can be done in CSS such as:

<if media=(max-width: 600px)>
         <!-- MOBILE MARKUP -->
    </endif>

There is precedent for this to an extent with regards to the picture and video elements handling of selection of media assets based on dimensions using the sizes attribute. I'd prefer to not necessarily go this exact same path but lean on learnings from how the industry does this today.

This is meant to be an exploratory issue, not something that we're actively proposing so opinions and ideas are welcome.

[matthewp]

The solution presented here is just equivalent to a .mobile class that toggles display: none with a media query, so nothing that can't be done in regular CSS. To make it something more than that you'd want the mobile markup to be inside of a <template>. This way it can contain side-effectual custom elements that trigger things like API requests that you do not want in the non-mobile layout. That's something you couldn't achieve with CSS.

I think this idea is dipping dangerously close into templating, which is a much bigger issue (and IMO a dead-end in HTML).

[gregwhitworth]

I think this idea is dipping dangerously close into templating, which is a much bigger issue (and IMO a dead-end in HTML).

That is the point of the thread is to entertain if it's something we may want to introduce. If it's already been considered and killed, would be good to have that linked if you know of such a discussion

The solution presented here is just equivalent to a .mobile class that toggles display: none with a media query, so nothing that can't be done in regular CSS. To make it something more than that you'd want the mobile markup to be inside of a <template>. This way it can contain side-effectual custom elements that trigger things like API requests that you do not want in the non-mobile layout. That's something you couldn't achieve with CSS.

This is actually the point of the issue, unsure what I can clarify in the issue to denote this. Yes I can place both markups on the page of course and display: none the variant that I don't want but then both have to be parsed, structured, events placed, potentially fired, etc. Granted that's why this is exploratory only because the ROI may not be worth it.

[zcorpan]

Does Declarative Shadow DOM handle this use case? https://github.com/whatwg/html/pull/5465

[bkardell]

If it's already been considered and killed, would be good to have that linked if you know of such a discussion

There are so many somehow related to templating, depending on your definition and where you draw the line. https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md is one you might find links to and discussion iterations on, for example. But - that said, there is something of a problem here in that if you squint at it just right - everything is 'just templating' of some kind because the DOM tree can be serialized. Like, is react and js and state management of live elements "templating", or is templating string in, string out - etc.

It's possible that someday we may achieve primitives necessary to do lots more things in a way that is more like this - it's also possible that things like container queries opens a lot of possibilities to not change the DOM, but change the relevant DOM in a manner more like the OP suggests. Or, maybe toggles provide similar opportunities that even have something to do with interactions. Perhaps we can achieve some of these with panelset affordances. Idk, tbh I think attempting to generalize too far here with one specific idea might be premature. When I wrote the first things about spicy sections I tried to do that too and we backed off. Maybe there is value in the mere exercise but I think we have to be careful about trying to boil the ocean - it's not likely to work.

[matthewp]

That is the point of the thread is to entertain if it's something we may want to introduce. If it's already been considered and killed, would be good to have that linked if you know of such a discussion

I don't mean to discourage the discussion, just pointing out that it is within the realm of templating.

The problem with adding templating piece-meal is that you still need to use some other library/framework for templating everything else. So consider a world where this feature exists and you can conditionally inject a template in HTML. Well, templating libraries can do that too, and I'm already using that library since HTML doesn't inject values into text content, or set class names or attributes, etc. So why would I use the HTML version of conditional rendering and not the library version of it?

This is actually the point of the issue, unsure what I can clarify in the issue to denote this.

The opening thread doesn't mention there being a <template> involved, so if that's part of the idea then I'd add that.

[bkardell]

I'd like to suggest that we talk about drawing a line around particular use cases and then deciding if they are on their own worth some kind of answer that might be conceptually also handleable a different way in the future (and maybe why it makes sense to do that, which I believe it might). That is, it seems to me there is a pretty big spectrum here from, well, basically react in the browser to something more like "this should 'overflow' a particular way under certain conditions which grants it common simple UI affordances". The latter is I believe interesting and fits the web very well - tbh, even some kinds of popup seem like they would fit that model. I'm unsure how we design that in a way that is useful and flexible enough to account for many use cases without getting dragged further down that road tho.

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.