[selectors-4] additional resource state pseudo-classes for media elements · Issue #3821 · w3c/csswg-drafts (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Description

In §11 Resource State Pseudos we currently have the :playing and :paused pseudo-classes, which collectively address the use case of a custom "play/pause" media control which should appear as a play button or as a pause button depending on the current play state of the associated media element. A bunch of us (@beccahughes @mounirlamouri @padenot @jyavenard @eric-carlson @jernoble et al.) would like to address several related use cases with additional resource state pseudo-classes:

• Whether or not the media element is muted. Use case: styling a custom muted control. Proposal: mint a :muted pseudo-class.
• Whether or not the media element is currently stalled (see several paragraphs in the HTML spec starting at "The stall timeout is a"). Use case: changing the appearance of a loading progress indicator to indicate that loading is currently stalled. Proposal: mint a :stalled pseudo-class.
• Whether or not the media element is currently seeking. Use case: a custom seek control can reflect the case where a user is seeking using some other, UA-provided control. Proposal: mint a :seeking pseudo-class.

Currently, authors of custom media controls have to do some combination of UA-sniffing and other logic from script in order to handle these cases. Ideally, the appearance of such controls would be expressible in CSS, just as play state currently is.