Skip to content

2026 Web Components Next Steps

Jump to bottom Edit New page
Manuel Rego edited this page Jul 15, 2026 · 1 revision

WEH 2026 - Web Components Next Steps

OpaqueRange

OpaqueRange: https://chromestatus.com/feature/6297362687066112

The speaker (Rniwa) opens the discussion and invites people to suggest topics.

How to use the shadow DOM? and opaque range? the speaker explains a proposal ... we want the opaque range as the new API... available from the selection object... and make it work with the shadow DOM

(Do we have a session-specific Matrix? Where do we post comments?)

So the opaque range allows to address the selection without input or text area to find spans. There is an explainer... The proposal is to expand the regular range and then map it to specific locations in DOM, but the mapping is not exposed to external customers. Any questions?

Olli: Is there something accessibility-related about them? Yes, one interesting thing about the selection in the shadow DOM is that browsers allow ... We could consider adding some attachShadow

I think in theory the user select to create ranges? how you prevent selection

Emilio: We have user-select: contain in the spec

Anne: We need a controller for Opaque Ranges

Ryosuke: OpaqueRange controller that user creates, and from that you create one OpaqueRange or multiple

Anne: One controller per range. Just one controller that can set both start and end I'd imagine

Ryosuke: Thinking about the case where, it's unclear to me what happens if you need to make a selection that crosses the shadow boundary. You have to combine the OpaqueRange and pass it to the outside world

Olli: In selection, API would need to support OpaqueRange, and multiple ranges, that's coming hopefully

Anne: That case seems tricky, not sure how we expose the opaque... like if you call getSelection() and user made a selection that starts before the shadow tree and ends inside, I'd expect the public range that we expose is one that compose the entire host, cannot do that granularity; maybe 2 ranges underneath one for the light tree and another for the shadow tree

Ryosuke: The case where OpaqueRange comes, is when the outside of the component has no access. If you already have OpaqueRange, how you expose that, how you combine the outside world API with the internal component. Imagine that you have a date range component, start date and end date, you can have the selection, each of the day month and date could be elements, they have OpaqueRange, and they export that somehow.

Anne: We would have all those methods that return range objects in the component object.

Ryosuke: All this OpaqueRange thing is to have uniform way to access the selection object.

Anne: Not sure how this would work

Olli: This was initially for highlight API, similar to selection not the same

Keith: Caret position rect, and getboundingclientrect

Anne: Don't think anyone has tried to make that work yet, the selection part

Ryosuke: Maybe OpaqueRange we don't need ability to convert from one to another. That's kind of weird, offset is a subcomponent, you no longer have the availability to merge.

Anne: OpaqueRange is for part of your component you have to...

Ryosuke: Maybe that would be ok for an initial version, maybe extend later for more complex conversions.

Olli: Looking back to the question about a11y, is everything here that might be problematic here from the a11y POV. Does a11y handle selection in some special way, some notifications about changing selection

Luke: Some screenreaders can do quite complicated text manipulation within them, I don't know how is the interface with this, I guess provided standard browser selection system in the browser, I think that would be ok. Just get the flat tree. If they are crossing shadow roots that might be a problem.

Ryosuke: Current design proposal for OpaqueRange, we have a controller that creates a single OpaqueRange, allow to set start and end; and we expose to the outside world. If you have nested elements then we pass through the opaque ranges, and we maintain some identifiers for them.

Keith: Can we use that a function to construct the OpaqueRange? Create the intermediary object creates a lot of work to getting access.

Anne: We need to be able to update them.

Keith: It feels like a lot control, it'd be a bad idea to have the IDL that just sets it, but that what we need inside some encapsulated runners. That does not sound we need controller

Anne: That's what we do with ... Promises have 2 methods that you can do something like that, you have to use quite a lot of methods to control the full range. You need to set the public start/end, but also internal start node and offset and end node and end offset.

Keith: Those are part of range right?

Anne: That might work

Ryosuke: Another thing I want to ask, are we envisioning the things that get a bounding rect, would be browser computation, or the components would have permissions, as that seems to be the point of the API

Anne: OpaqueRange for me would be live ranges, but internal data would be hidden, the browser would be able to do all the operations, the tree won't be accesible to the component, but to the browser. If the component exposes that selection, then the user of the component could pass that OpaqueRange to Highlight API for example.

Luke: Paint thing could be something behind the scenes.

Anne: Arbitrary thing would require a separated design, not sure how useful that would be. Would require more layers of abstraction. If your component was completely canvas based, that would be more involved. Do the simple thing for input and textarea, slightly more involved so it also work for arbritary nodes and not only text nodes.

Anne: If HTML-in-canvas is a thing we could allow that too.

Keith: ...

Luke: Is an issue where you execute JS, there can be potential issues?

Anne: Not sure just having getters, not understand how this would work for highlighting something in a canvas.

Keith: Using underline range

Anne: You need a super abstract range for this

Keith: The paint range is effectivily providing the underline information, for the text node case, the reason to have the OpaqueRange is because we don't expose the shadow tree, they'd have another underlying range. That's the conceptual design, having something that overrides these methods.

Ryosuke: Anne's point each web API that takes OpaqueRange input, needs its own fallback. Highlight API no longer will know where to put the highlight.

Keith: My interpretation, is that any of the API would have the privilege to extract the underlying range. Custom highlights could do that.

Anne: Your design we still talk about a live range. The change is that instead of the getters returning an internal value that is previously set, they run some JS. Seems pretty novel but might be ok.

Ryosuke: That won't allow you to override the behavior of getClient.

Anne: It would no, a different API shape for the controller.

Keith: ...

Ryosuke: If you did that, the highlight API would change, you have to reuse the entire range, no internal mapping to override those methods.

Anne: For highlight you need a new callback, and you have to run JS.

Ryosuke: In the canvas text, you need to let the JS run and do what's needed.

Anne: I don't think we need solve that, as nobody has asked for. The thing people have asked for is making a highlight range opaque.

Ryosuke: It looks we have a good design here. Do we have any Microsoft folks here?

Luke: They'll be in the WHATNOT call next, so we can talk about this.

Ryosuke: People from Microsoft were very interested in the text inputs. They might be happy with the idea we came up with.

Accessibility

referenceTarget explainer

Ryosuke: What people need and want in web components next? One thing was a11y, I think referenceTarget addressed that issue, what else.

Olli: We need referenceTarget version 2, we only have 1

Luke: I think people have been happy with that

Alice: Don't know if you meant the, the more than one target, ok yeah. Version 2 and there's another thing wich is attribute forwarding, the version 2 is arbitrary more fine grained and more targeted to shadow root. One thing is the active descentant and ARIA text computation are the main examples, and another quite vague, active descentant for ARIA text computation. The level 2 attribute forwarding, you might need to pay to some attention to ... a thing about element behavior on form submission, some examples, in those examples there were many cases where you also need attribute forwarding as well as reference target forwarding. We need at the very least reference target at the host, delegating. Related problem when you want to apply ARIA attributes to the target element.

Luke: The platform behavior stuff has been discussed for web components, likewise think that maybe it's up for solutions that could be provided, maybe it makes sense other behaviors. Like Form submission buttons.

Keith: We'll discuss later at WHATWG, they asked us to refrain discussions until later. The other big topic is style sharing.

Style sharing

Noam: ... from Microsoft has been working on this for a while. Try to review it on different proposals. The problem ... Every time you update the text the style need to be reapplied, not efficient. One can use URL but also can have inline style elements ...

Noam: Suggested solution is to have a specifier attribute, but the problem with it is ...

Ryosuke: Topic is to share styles between different custom element instances

Noam: sharing style in package is interesting

Keith: Why link or style element is not sufficient?

Noam: You can't mutate the style

Keith: But the second style is effectively cached

Noam: Two elements loading the same styles, mutating style nodes does not affect other instances

Emilio: We don't want to encourage people to mutate CSSOM that way, most new CSSOM APIs are designed against that, not sure this is problem people are getting

Ryosuke: Skeptical that this is a major use case people are thinking. We need to be clear what problem we are solving here. We need to understand why people would want to share stylesheet objects.

Keith: This is coming from lit, there are server side rendering, they can skip subsequent serialization, duplicating the same stylesheet thounsands of time afffects performance. Performance for serialization, and then ergonomic issue.

Anne: It ends up using the global module map that suppose to be encapsulating elements, doesn't look great

Noam: The main driver is the performance, than ergonomics. Is the problem fortified enough?

Ryosuke: yes

Noam: Special blob URL that is a hash of the content. de facto global but unguessable.

Ryosuke: Not great ergonomic

Noam: Requires server control, but CSP and integrity already does that. You can add an import map to use a regular name

Brian: seems to solve the problem of mutability

Keith: we need to serialize and deserialize adopted style sheets, seems like implementation tradeoffs, why do we need adopted style sheets for this? don't understand why it's not possible today, putting stuff into module graph. Some encaptulation is undesirable in web components

Anne: It's not strictly an encapsulation concern, but that it has to use global thing is weird, while the other part can't use it.

Keith: If you iterate module graph can you get unguessable names?

Noam: Two different custom elements using the same name globally ... Custom elements can do that

Keith: libraries can't sync without having a constant releases

Anne: How do you prevent two different coopperating parties not collide?

Ryosuke: in module graph there no scope but names

Luke: Can it have some type assertion

Noam: Could use package instead of unguessable names, quite an involved design

Ryosuke: Any other form or approach? Encapsulation for each component but still allowed to share styles

Anne: Could be a registry, and pull styles from there.

Noam: Each custom element would have a CSS specific import map, and export from there rather than globally

Keith: No mechanism right now that script registries being serialized. We need some global registries somewhere

Anne: It's not enforced, people would use simple identifiers

Keith: We seem to solve the problem but we are moving problems to somewhere else.

Ryosuke: Sharing styles between unrelated elements would require global map

Keith: yes

Ryosuke: If you inherit one component from another and they have different name then it won't work

Keith: Oppositions of module map is about encapsulation, and pushing people want to break it.

Luke: Why do we need to let people make unguessable name rather than providing a mechanism

Ryosuke: HTML only has tag name, we would need more namespaces. Like XML namespaces. If you want to share styles in pure HTML form then we need global mapping. For encapsulation we shouldn't do that though. Opposing needs are here.

Noam: Ok with breaking capsulation, but accidentally breaking it is a big problem. Because why do we have a module in that case

Ryosuke: Module graph is already a namespace map. who's requesting this

Noam: Dupliated CSS being a problem

Keith: Microsoft is driving it. There is a desire to use module mapping

Ryosuke: end of the time, next step?

Noam: check between suggested solutions

https://www.webengineshackfest.org/

Add a custom sidebar

Clone this wiki locally