w3ctag/gaps

What are the big unmet user needs of the web platform?

Web Platform Gaps

What are the big unmet user needs of the web platform?

Content in Issues.

gaps's Issues

SVG images should be able to utilize local resources

Currently, SVG images ¹ are not allowed to link to any other resources, even when these resources are same origin, which severely cripples them across several areas.

Pain points

Fonts

This is probably the biggest issue today.

SVG images cannot reference any web fonts, so any text is limited to system fonts. This is now even more restrictive than in the past, as Apple has excluded user-installed fonts from font matching, which restricts SVG images to preinstalled system fonts.

In practice, authors result in the following workarounds, both with severe downsides for end-users:

1. Using a vector graphics application to "convert fonts to outlines", i.e. convert each flyph to a <path>. Sometimes there is textual fallback, but usually not.
2. Embedding the entire web font into the SVG as a data URI. This is a real example from a D2 diagram:

Both of these workarounds are wasteful wrt bandwidth, which is particularly harmful to users in developing countries, and the first creates a serious accessibility issue. The 2nd workaround privileges languages with certain scripts more than others (e.g. East Asian fonts tend to be way too large for 2 to be viable).

Duplication galore

• Stylesheets: SVG images cannot reference stylesheets, so they have no access to the page’s design tokens (colors, fonts, etc.). In practice authors have to duplicate these in the SVG and maintain multiple sources of truth.
• Other SVGs: They cannot reference other SVGs via the <use> element so simple variations, such as a different color (e.g. a dark mode version), a modifier (e.g. a + icon at the bottom right) duplicate the entire graphic.

Potential solutions

At the very least, linking to resources in the same origin should be safe, and already solves a swath of use cases. Ideally there should also be an opt-in of some sort for external ones, so that use cases like downloading diagrams can just work. Hopefully CORS can be reused, so we don’t have to introduce yet another mechanism.

Specifically for fonts, another solution could be to bring SVG fonts back, and redesign them around the use case of making converting text to outlines less problematic (which is essentially what PDF does, I think?). It is far more palatable to convert glyphs to outlines once rather than every time the glyph is used, and it completely resolves the accessibility issues. This may be worth it on its own, to make it possible to create self-contained SVG images with custom fonts.

Footnotes

1. Meaning SVG files used in image contexts, such as CSS images, or HTML’s <img> element. ↩

IDREF attributes are fragile and painful to use

(An earlier version of this was posted in whatwg/html#10143)

Pain points

Many HTML attributes need to reference one or more HTML elements in the document. This includes:

• for, in <label> and <output>
• list in <input>
• A host of ARIA attributes (e.g. aria-describedby, aria-labelledby, aria-activedescendant, aria-controls, aria-details, aria-flowto, aria-owns etc.)
• Popovers (popovertarget)
• Invokers (invoketarget)
• the new anchor attribute
• This is also a frequent need in author web components as well.

Currently, the only way to specify such references is to give these elements ids (if they don't already have them) and use these ids to link to them in these attributes.

This is problematic in several ways:

• Friction: It creates high friction for authoring HTML, especially when not using tooling to generate it. Authors then need to devise globally unique ids for elements that wouldn't otherwise have one and manually do the linking.
• Fragility: It introduces a host of error conditions. It is a common authoring mistake to change an id and forgetting to change the id references to it, pasting a chunk of HTML and forgetting to edit all the references, or ending up with broken references due to accidental duplicate ids.
• Inconsistency: We typically give web component authors the advice to follow HTML precedent. However in this case precedent has such poor ergonomics that WC authors have to invent their own referencing mechanisms, coming up with wildly inconsistent solutions because they are forced to choose between ergonomics and consistency with the web platform.
• Since ids are scoped to shadow trees, linking to elements across shadow boundaries is impossible. Cross-root ARIA is largely still an open question. There are many proposals, but all target it as an isolated problem and most involve high degrees of complexity.

This is a very common author pain point around ARIA, and authors are pretty vocal about it: DX-related complaints were the 3rd biggest a11y complaint in the preliminary State of HTML results. It especially hurts a11y, since the effects of broken references in the a11y tree are not always obvious, and the more effort it takes to make HTML accessible, the less likely authors are to do it. While for <label> this is somewhat mitigated by the option to make the association implicitly by nesting the form control within the <label>, for the other cases there is no similar option. New features like popovers, invokers, or the anchor attribute exacerbate the problem further.

The IDL attributes for these are also inconsistent:

• element.htmlFor returns a string, corresponding to the textual value of the for attribute. The actual element can be accessed via element.control.
• element.list returns the actual <datalist> element linked. The string value is only accessible via getAttribute().
• popoverTargetElement returns the element popovertarget corresponds to. The string value is only accessible via getAttribute().
• ariaDescribedByElements returns the elements aria-describedby corresponds to (and similar for other ARIA attributes). The string value is only accessible via getAttribute().

Potential solutions

• Being able to link to elements in a way that is relative to the element the attribute is specified on would solve most of these issues, and make writing ARIA much more pleasant. I’ve discussed several ideas here. A selector-based solution could potentially address some cross-root ARIA use cases too, as long as the element is exposed via part.
• Every element reference attribute should not just have an IDL attribute that reflects its value, but also an IDL attribute for getting/setting the referenced element(s).

Some considerations are:

• Backwards compat, if changing the syntax of existing attributes.
• The migration path for authors. It would introduce an undesirable cliff, if using a relative reference suddenly requires changing all of their existing absolute references. The more substantial the edit required, the sharper the cliff.
• Not all use cases require relative references, so ideally the syntax should allow mixing the two. While a11y-related use cases tend to primarily need relative references, attributes like list need both (e.g. a "country" field would need to autocomplete to the same list of countries everywhere).