Progressive enhancement of new html elements

[stubbornella]

TL;DR I propose that we make progressive enhancement a goal for components in open UI and track questions we have around PE in this bug.

NB: no need to bikeshed the HTML structures below, they aren't well thought out, they exist just to enable a more concrete discussion.

Use lists to do progressive enhancement and have shiny new components

It is important for adoption that these components follow a strategy of progressive enhancement. I believe in some ways we can rely on the browsers built-in parsing behavior to make that happen. For example most browsers (afaik) would correct the following HTML by inserting a UL around it:

<!-- browser inserts a UL -->
<li>item 1</li>
<li>item 1</li>
<li>item 1</li>
<!-- browser closes the UL -->

We can use that behavior to our advantage to achieve progressive enhancement. For example this carousel would be navigable in older browsers because they would treat it like a list:

<carousel>
  <li>item 1</li>
  <li>item 1</li>
  <li>item 1</li>
</carousel>

More components than you would expect turn out to have lists as an underlying structure. This can allow us to create declarative HTML that pushes the web forward, while still supporting older browsers.

Can we identify some of the most important progressive enhancement challenges in this bug?

Q: how can we ensure that headings are navigable in new elements?

<tabs>
  <tabslist>
    <li>tab 1</li> <!-- not selected tabs are essentially navigation to non-visible content -->
    <li>tab 2</li>
    <li selected>Tab 3</li> <!-- the currently selected tab functions as a heading for the visible content. How do we retain it's headingness for assistive tech? -->
  </tabslist>
  <content>
  </content>
</tabs>

Q: How do we ensure clickable elements are links for older browsers? e.g. in the tabs example, the li are links to the content below. Would this need a polyfill? Do we need a way of saying treat this li like an a?

Leonie and Brian quite likely have more to add here as they brought this issue to my attention. What other assistive tech issues need to be addressed?

[WebReflection]

not sure I am following but I wonder if everything is already covered by custom elements builtin extends:

<ul is="oui-carousel">
  <li>item 1</li>
  <li>item 1</li>
  <li>item 1</li>
</ul>

this is how I've been done progressive enhancement with Custom Elements since 2014, and it worked well down to IE8 and very old Mobile browsers, it works SSR, and it works via CSS too ... has this been considered? all browsers support Custom Elements v1 these days, and the builtin extend patch for WebKit/Safari is just ~1.3k

[bkardell]

I can offer that as someone who has implemented a lot of components over the years which didn't do this, and someone affected by/looking at some of the regrettable decisions we are still dealing with in standards that have gotten this wrong in a few ways in the past, I can appreciate how it is not probably our first intuition, but I like it. I am also willing to concede that because of that we don't probably have super great data to show that this would be as acceptable as I imagine.

A few of us have been trying to circle round and articulate in a clearer way what this really means since there are a lot of ways to make this not actually very progressive ( https://github.com/thepassle/generic-components/issues/38). There's no parser fixup right now for leaving out the list wrapper as far as I can see and leaving it out might be trouble for older browsers and AT as I don't think it would communicate as a group, but maybe @LJWatson can keep me honest there. But yeah, I am keen on exploring the basic idea of PE and otherwise good content. @WebReflection's way might also be a way to achieve the same, although I do feel like composition over inheritance here would be good and also perhaps more acceptable to folks who have rejected is. I think no one is keen to do another 'type' situation, but maybe this is different enough...

[gregwhitworth]

Would it be worth adding a PE section to the template? https://github.com/WICG/open-ui/blob/master/research/src/pages/component-spec-template.mdx

I think you've raised some good questions and will probably need to be discussed on a case-by-case basis even if holistically (eg: your list example if used in a component).

[chrisdholt]

not sure I am following but I wonder if everything is already covered by custom elements builtin extends:

<ul is="oui-carousel">
  <li>item 1</li>
  <li>item 1</li>
  <li>item 1</li>
</ul>

this is how I've been done progressive enhancement with Custom Elements since 2014, and it worked well down to IE8 and very old Mobile browsers, it works SSR, and it works via CSS too ... has this been considered? all browsers support Custom Elements v1 these days, and the builtin extend patch for WebKit/Safari is just ~1.3k

This may be the case but I think this gets way too far into a prescriptive implementation detail. In FAST we looked at using is but found that it didn't meet our requirements. For instance, I don't believe that Apple has any intent to implement support for is.

I'm for the principle here, but I'd prefer we try to not couple this goal to a specific implementation of custom elements.

[WebReflection]

In FAST we looked at using is but found that it didn't meet our requirements.

I've used builtin extends since v0 was out and it's been the best graceful enhancement experience I've ever dealt with, but maybe our use cases were different.

For instance, I don't believe that Apple has any intent to implement support for is.

But this has nothing to do with "not meeting requirements", right? I think these are two different topics, and I've simply suggested that the platform, and the standards, already have a solution for graceful enhancement that works even in terminal browsers, and the polyfill has been battle tested for the last 6 years, and its most recent version has no caveats at all, and it works extremely fast and well, and Apple is lucky enough to have best hardware out there, so the difference is unnoticeable (but I've tested the poly even in WPE and Raspberry Pi 2, to date I had zero issues whatsoever).

Anyway, I just wanted to bring up that we already have a way to graceful enhance, and anything that would produce a subpar result, in comparison, should likely be discarded, imho.

[chrisdholt]

@WebReflection I definitely appreciate your perspective and experience. To be more clear, I think that while your proposal is one way and perhaps the most elegant way of supporting this - prescribing a specific implementation of custom elements in order to meet "compliance" with Open UI would not meet the goals for Open UI as I understand them.

[WebReflection]

@chrisdholt this is the bit I don't fully understand:

prescribing a specific implementation of custom elements

Custom Elements V1 are spec'd with builtin extends, it's not a specific implementation, all browsers (but one) fully adopted what standards wrote.

Anyway, feel free to ignore my comment, I just keep finding people trying to solve something, in my experience, already solved, and proven to work for years.

Best luck with alternatives though, I'll happily watch this space to see progress :+1:

[matthewp]

My only concern is that making PE too hard of a requirement will possibly diverge the design in a direction that it might not go were it designed purely as a built-in. And so when we eventually (hopefully) go to make tabs a built-in element it will be rejected for those PE design considerations that don't apply. I'm curious if we can find a way to satisfy both.

[EisenbergEffect]

It might be worth separating progressive enhancement from accessibility.

WRT parser...every conversation I've ever been in with an implementor where the topic of changing the parser came up...that was almost an immediate no go. So, solutions that don't involve modifying the parser are likely to have a better shot.

[bkardell]

It might be worth separating progressive enhancement from accessibility.

They are kind of linked in the sense that a lot of content and patterns wind up not being very great for accessibility in an old browser or if your JavaScript fails. I appreciate, as I said, that that is not actually anyone's first intuition and might not be as important to many of the folks participating in open-ui that this remains true. I think it's more important when we get to standardizing something though that we be able to articulate... something here about why that is or isn't important.

[thepassle]

Depending a bit on what the goal here is (standardizing a tabs element, or creating an outline for developers implementing a tabs component), I'll share some of the thoughts I also posted in https://github.com/thepassle/generic-components/issues/38

I still think in regard of progressive enhancement (in the case of providing an outline for developers implementing a tabs component), the best bet is to go with something like:

<generic-tabs>
  <h2 slot="tab">John</h2>
  <div slot="panel">My name is John</div>
  <h2 slot="tab">Mark</h2>
  <div slot="panel">My name is Mark</div>
</generic-tabs>

• If no js: will gracefully fall back to regular headings/divs
• If js: 'enhance' and set correct aria roles/attrs etc once the component upgrades

The reason I think this is better than going with buttons for the tab controls is that if JS doesnt load, there'll be buttons that dont actually do anything and 'mislead' the user.

I do think there's something to be said for Zach's approach of falling back to anchors that link to an idref as PE, but I also remember somebody made a good argument about why that wouldnt be desirable but I forgot exactly what that argument was.

I do agree that it should be clear (as Dave mentioned on twitter) exactly what it is we're discussing though.

[bkardell]

I do think there's something to be said for Zach's approach of falling back to anchors that link to an idref as PE, but I also remember somebody made a good argument about why that wouldnt be desirable but I forgot exactly what that argument was.

The argument is (I think, this is part of why I wanted to sort it out in another issue first) captured in point 2 on your repo, unnatural content. That is, the content areas run together and become indistinguishable/unlabeled, so while it is interesting, the ToC analogy doesn't really hold up - people wouldn't naturally create or consume that content. You could, of course, fix that by adding more markup too but then there's more complexity you probably don't need too. Anyway, it would be good to try to articulate guidelines, I'm not 100% sure my own offering of guidelines in the other issue are the best, they're just the only attempt to articulate it that I am familiar with.

[gregwhitworth]

@stubbornella is the goal of this issue to talk about PE specific to tabs or PE in general, eg: add it to the template and ensure it's being considered? I'd like to not overload the issue but there's some solid discussion regarding tabs. Let me know and I'll fork the issue appropriately.

[thepassle]

@gregwhitworth Would it be possible to share the solid discussion regarding tabs you mentioned?

I feel like there are now multiple places where we're discussing, and im pretty sure we're gonna lose oversight at some point.

We should clarify what it is we're discussing, and where we're discussing it

[gregwhitworth]

We should clarify what it is we're discussing, and where we're discussing it

@thepassle yep that's why I asked @stubbornella for the primary goal of this thread. I took it to be a general question with an example but not necessarily trying to solve that problem. But maybe it was.

@gregwhitworth Would it be possible to share the solid discussion regarding tabs you mentioned?

Yours

[stubbornella]

It might be worth separating progressive enhancement from accessibility.

How did you imagine doing that?

WRT parser...solutions that don't involve modifying the parser are likely to have a better shot.

Fwiw, I wasn't suggesting changing the parser. I was suggesting taking advantage of their preexisting behavior to find a way to have a great HTML interface, but fall back to something kind of reasonable. The semantics of a list are correct for many components, like tabs, carousel, etc.

[stubbornella]

A built in component can use slots and aria roles under the hood, but I think it would be a poor choice if they were necessary to use a basic HTML component. They are too easy to get wrong, as evidenced by most design systems being inaccessible even when they try. So if we need is, aria roles, or slots in the Chrome implementation, that's fine, but there is no need to expose that in the HTML authors write. And, you definitely can't assume authors will choose to use web components.

[stubbornella]

As an example, if the browser knew about the <carousel> tag, it could manage its contents however it wants, no need to expose that complexity to the user. The whole point is components authors, especially designer developers, don't need to write JS to build with these components. That said, JS makes sense when there is customization that goes well beyond the use-cases the component is trying to solve.

How do we get to a place where the interface to these is just HTML and CSS?

[stubbornella]

Sorry, just seeing @gregwhitworth's request for the goal.

My goal was to discuss how to achieve reasonable backwards compat:

• Progressive enhancement in browsers that will not support new elements?
• Important aspects of "good basic markup" that we would need to achieve for these components to be navigable/sensible in old browsers.
• Assume HTML/CSS interface.
• How can we hide some of the complexities of aria etc so these are easier to use. ARIA by default in newer browsers. Great sensible HTML in older browsers.

If Open UI is the wrong place to discuss this, I'm happy to take it to a different forum?

[gregwhitworth]

If Open UI is the wrong place to discuss this, I'm happy to take it to a different forum?

I think this is the perfect place to have this discussion. This is why I think a PE section in the template is worthwhile because as @thepassle hit the nail on the head about PE impacts things:

Depending a bit on what the goal here is (standardizing a tabs element, or creating an outline for developers implementing a tabs component)

Technically we're doing both here as many of these will ship in component libs before they end up in the platform (if ever). I think prefacing the PE section in some way with a note that it only applies to non-browser implementors. Certain aspects become interesting such as the potential for anatomy changes and how we would want to handle that if there is indeed agreement that the anatomies should differ. I have yet to see a really compelling reason as to do this and I think it should be handled on a case-by-case basis and discuss how best to represent that. I would expect over time that this PE can be removed as browser catch up and implement it. Many of them early on however will and should leverage this.

I would prefer however that the anatomy's align as much as possible as I'd expect much of the reasoning to be sound in both a native solution and PE; so would prefer for the anatomy changing to be the exception rather than the rule.

[LJWatson]

@bkardell

There's no parser fixup right now for leaving out the list wrapper as far as I can see and leaving it out might be trouble for older browsers and AT as I don't think it would communicate as a group, but maybe @LJWatson can keep me honest there.

You're right, and some impromptu tests confirm that without a parent ul, ol, or dl element, the li are not recognised as a collection at least in Chrome/Firefox.

[LJWatson]

I think @thepassle's suggested fallback pattern for a set of tabpanels is a good one, and had suggested it in conversation with @bkardell, @jonathantneal and others.

To @bkardell's suggestion to find guidelines, the best I can come up with is:

Fall back to a pattern that enables the content to be consumed in a logical and meaningful way

Or:

Fall back to a pattern that has semantic meaning and logic in its own right.

For details/summary for example, a heading followed by a div would have fulfilled either of these guidelines.

They'd also be met by having multiples of the heading and div pattern as the fall back for a set of tabpanels.

I'm not a browser engineer but I believe that new elements that are not yet supported in a particular engine already fall back to some kind of HTML elements in order to be rendered. Likely div and/or span elements.

So I don't think we're inventing a wheel here, we're just looking at the benefits of making the wheel work better by choosing meaningful fall back elements instead of semantically neutral ones.

[prushforth]

PE as a design principle for new elements means, I think, one of two things:

• composition of new elements wrapping already-defined elements, such as is done with <picture><source><img src="fallback.jpg"></picture>, or
• inheritance of already-defined characteristics if the new semantics aren't understood: <img src="fallback.jpg" srcset="...">

In the case of maps in HTML, we favour using <img usemap="#themap"><map name="themap"><area></map> (inheritance) as a fallback.

It would be nice to be able to rely on custom elements as a fallback, but I'm not sure if that's been considered anywhere, and script as a fallback may not fly anyway.

The two HTML Design Principles that are relevant, I think, are Degrade Gracefully and Evolution not Revolution.

[gregwhitworth]

This was discussed in the January 07, 2021 meeting - here are the minutes: https://www.w3.org/2021/01/07-openui-minutes.html

[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.