Open FluorescentHallucinogen opened 3 years ago
Would you want to discuss this at the telcon? Is there anything to resolve on here specifically?
- style player
See related: https://github.com/WICG/controls-list/issues/5 about styling controls specifically.
@Malvoz this is perfect thank you and this also sounds great @FluorescentHallucinogen.
A few things here - Open UI is more than happy to investigate any of these ideas. That said, it requires someone to champion the effort. The video and audio elements you're actually in a good starting position in that much of the API's defined actually standardized much of the parts since you invoke them. @Malvoz @FluorescentHallucinogen either of you want to take on the task of beginning to build out a research and proposal page? There are enough major video players that a solid anatomy and behavior set could be defined.
This then could begin to solve aspects of your issues by denoting that there should be new attributes or psuedo elements (eg: removing the download button).
Ironically, I've referenced the media elements as somewhat low-hanging fruit as you either get ALL controls or none of them when you may just want to change out a sub-menu rather than rebuild the entire thing.
Do we have any research on this area? Do any design systems include
either of you want to take on the task of beginning to build out a research and proposal page?
@gregwhitworth I don't see myself finding the time to dive into this anytime soon, unfortunately.
https://github.com/WICG/open-ui/issues/213#issue-730662606
- add controls
One of the challenges is adding custom controls that integrate well with the native controls. For example avoiding overlapping default controls (a low-level primitive may be derived from discussions such as discourse@WICG: Position an element relatively to another element from anywhere in the DOM), or responding to a responsive UI where (some of the) controls may be hidden behind a collapsed menu at certain sizes.
Another reason why developers may choose not to use native media elements is because they're not doing too well in the accessibility department, see the assessment by @svinkle at https://scottvinkle.me/blogs/blog/how-accessible-is-the-html-video-player.
Another reason why developers may choose not to use native media elements is because they're not doing too well in the accessibility department, see the assessment by @svinkle at https://scottvinkle.me/blogs/blog/how-accessible-is-the-html-video-player.
Thanks for sharing this. @svinkle did you file bugs on the browser vendors for these?
One of the challenges is adding custom controls that integrate well with the native controls.
This is one of the key aspects of Open UI, is to ensure that the native controls are defined/standardized (also this will also solve many of the issues identified there since there will be a concrete UI doc to follow) to ensure that they are extensible and solve the majority of usecases.
I don't see myself finding the time to dive into this anytime soon, unfortunately.
That's understandable, we all are in similar boats and thus end up in this scenario where we have to pick and choose the items we spend our time on.
It seems all my pain points as a regular developer I've described in the first comment: https://github.com/WICG/open-ui/issues/213#issue-730662606.
Things like adding the srclang
and label
attrubutes to the <source>
element require changes in the HTML spec.
Also, I have some crazy ideas like adding new <tracklist>
HTML element and exposing "Cast" button for Presentation API and "VR" button (see https://crbug.com/605200) to native player. But I'm not sure is it out of scope of this project or not.
I think the good idea is to ask developers of third-party players what is missing in the native <video>
and <audio>
players.
@sampotts Do you have anything to add? This is related to what we discussed recently in Slack. Why did you start working on Plyr?
It'd be nice if media elements supported tiny screen/element sizes without compromising usability. For example, default controls may be hidden from the user if there isn't enough space (taking video
in Chrome as an example):
@sampotts Do you have anything to add? This is related to what we discussed recently in Slack. Why did you start working on Plyr?
Hey 👋
Without going into too much detail, at the time (2013 or so) there were a handful of options for custom video and audio players; mainly video.js and mediaelement. Both were using strange markup at the time - things like <span>
for buttons, <div>
s for progress, no <input type="range">
, missing ARIA, etc. Also, the styling out of the box didn't suit my needs. I originally built Plyr for myself as I need to use something in a project and wanted a nice looking player that had a small footprint - it started out as 3kb "minzipped"! It's now up there with the big players if GitHub stars are anything to go by 🤷🏼♂️.
It would have been great to been able to style up the native players somehow and then extend the functionality rather than the design as well. Adding an extra layer on top of the players only makes for a fragile solution as I'm sure we all know. I can only imagine the politics that goes on between vendors but the dream would be to have a standard player implementation (with features such as speed, language, looping, etc) that can be easily customized via CSS using the shadow DOM like other elements such as <input type="range">
. I know the styling is not what's being discussed here though.
I'd love to work with browser vendors on this although I'm sure they have folks looking after that side of things.
Oh, i would love to see a standardized UI for the video element!
I quite like the native UI better then full custumized UI and not having to rebuild every single control with js, html and css just so you can add that missing quality, language & subtitle picker, and when someone mention <tracklist>
i also thought about prev/next/first/last/shuffle.
I could give you a hole list of custom controls for why you would want to go all custom (as i have built a own player with cast support)
Re https://github.com/WICG/open-ui/issues/213#issuecomment-761208580:
- [ ] copy video adress at specific time
A similar suggestion was made in https://github.com/whatwg/html/issues/6323. Edit: well, the capability to share the copied video address at a specific time was suggested.
Recently @beaufortfrancois has finally implemented native controls for playback speed of <video>
and <audio>
elements in Chromium! 🥳
See https://twitter.com/quicksave2k/status/1415638025183371265.
@beaufortfrancois What about implementing native controls for other things like loop
and etc. from https://github.com/openui/open-ui/issues/213#issue-730662606?
Which native controls are you thinking about? Loop for instance is already part of the context menu.
@beaufortfrancois
Loop for instance is already part of the context menu.
Oh, I've checked on Android and haven't found "Loop" item. Also I haven't found "Picture and picture" as well as your new "Show all controls" that available on desktop.
Any plans to bring it on Android?
The second problem is that "Loop" feature is hidden behind context menu. Users need to right-click or long-tap on the video to find it.
What about to expose it as a button (maybe as a part of 3-dot menu since this is not such an often needed feature)?
The third problem is that on Android the <audio>
element has no context menu (long tap on the audio player just doesn't work).
@beaufortfrancois
Which native controls are you thinking about?
UI for switching sources (e.g. audio sources in different languages, video sources in different resolutions/formats).
E.g. Safari <video>
player has UI for switching audio tracks e.g. when playing HLS stream with multiple audio.
<video
controls
src="https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8"
type="application/x-mpegURL">
</video>
Surprisingly, Chrome for Android can play HLS streams natively too!
But Chrome <video>
player has no UI for switching audio tracks. :(
And for some reason Chrome on desktop doesn't support HLS. :(
BTW, another pain point for developers is the playback of HLS (HTTP Live Streaming) and MPD (MPEG-DASH) streams.
It would be really great if browsers supported playback of HLS and MPD natively on all platforms without the need for libraries like hls.js
and dash.js
. Something like this:
<video
controls
src="https://bitmovin-a.akamaihd.net/content/sintel/sintel.mpd">
</video>
@beaufortfrancois cc.
Adding to the list of wants, transcripts for media elements: https://github.com/whatwg/html/issues/7499.
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.
From what I saw, most developers prefer third-party players (video.js, Plyr, etc.) over native
<video>
and<audio>
elements for two reasons:Off the top of my head:
The speed of the audio/video playback can be set only via
playbackRate
property:document.getElementById('player').playbackRate = 0.5
. Why not to expose it as UI control?Whether the audio/video should start playing over again when it's finished can be set only via
loop
property:document.getElementById('player').loop = true
or vialoop
attribute:<video src="test.webm" loop>
. Why not to expose it as UI control?There's no UI for switching sources (e.g. audio sources in different languages, video sources in different resolutions).
The
<source>
element has nosrclang
andlabel
attrubutes unlike<track>
element. You can't do something like: