You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’m using progressive enhancement and setting the ARIA role of an element dynamically only if JavaScript is on/loaded and styling the component basd on those ARIA roles.
Specifically, I’m creating a Svelte version of Heydon Pickering’s inclusive tabbed interface component. This is a progressively-enhanced tab component that renders as a list of links and sections and is progressively enhanced into a tab interface.
The CSS uses [role="tablist"], etc., selectors that apply only if the component is displaying as a tab panel (and not as a regular list of links and sections).
Another option would be to have a separate :scoped() function that specifically has this behaviour.
So the following code:
:scoped([role="tablist"]) {
padding:0;
}
Would generate:
.s-QrjSjQiqMQoF[role="tablist"]
In other words, :scoped() would mean “always include this rule as a scoped rule.”
Workarounds
The obvious workaround is to use global styles for this. However, this removes the advantage of using scoped styles in Svelte for progressively-enhanced components and it doesn’t have to be an either/or decision.
How important is this feature to you
It would definitely be nice to have first-class support for progressively-enhanced components. Especially when the only thing standing in the way is the presence or absence of a single space character :)
I’m happy to write this up as an RFC but I wanted to create an issue first to see (a) if there is a way to do this that I haven’t considered and (b) whether this is something you’d consider implementing.Update: See note about the existing pull request from @tanhauhau, above.
The text was updated successfully, but these errors were encountered:
@Conduitry Yep, different use case but same issue. Sorry, I did do a search beforehand but missed it somehow. Please feel free to close this if you’d like to track it with the other.
Use case
I’m using progressive enhancement and setting the ARIA role of an element dynamically only if JavaScript is on/loaded and styling the component basd on those ARIA roles.
Specifically, I’m creating a Svelte version of Heydon Pickering’s inclusive tabbed interface component. This is a progressively-enhanced tab component that renders as a list of links and sections and is progressively enhanced into a tab interface.
The CSS uses
[role="tablist"]
, etc., selectors that apply only if the component is displaying as a tab panel (and not as a regular list of links and sections).e.g., (work-in-progress) https://github.com/aral/heydons-accessible-tabs-in-svelte/blob/main/src/lib/TabbedInterface/TabList.svelte
The problem
The styles are flagged as unused and not included.
The closest I’ve been able to come to generating the CSS I need is:
But that generates (e.g.):
Whereas what I need is a compound rule:
(The only difference is the lack of the space separator, making it a compound selector).
When I try to remove the space between * and :global() in hopes it would create a scoped compound rule, I get the following error:
Proposed solution
It would make it possible to create progressively enhanced inclusive components if there was a way to create CSS rules that were:
One way to achieve this would be to enable
:global()
to create compound selectors.So the following code:
Would generate:
(Note the lack of space between * and
:global()
and the compound selector in the resulting CSS.)Update: Looks like @tanhauhau has already implemented this in this PR: #6223 (HT @Conduitry)
Another option would be to have a separate
:scoped()
function that specifically has this behaviour.So the following code:
Would generate:
In other words,
:scoped()
would mean “always include this rule as a scoped rule.”Workarounds
The obvious workaround is to use global styles for this. However, this removes the advantage of using scoped styles in Svelte for progressively-enhanced components and it doesn’t have to be an either/or decision.
How important is this feature to you
It would definitely be nice to have first-class support for progressively-enhanced components. Especially when the only thing standing in the way is the presence or absence of a single space character :)
I’m happy to write this up as an RFC but I wanted to create an issue first to see (a) if there is a way to do this that I haven’t considered and (b) whether this is something you’d consider implementing.Update: See note about the existing pull request from @tanhauhau, above.The text was updated successfully, but these errors were encountered: