- It's consistent with how we output images
- CSS can override attributes, but not style="" statements.
|Use JS to transfer audio width from attribute to style||mediawiki/extensions/TimedMediaHandler||master||+7 -4|
|Synchronize allowed attributes for <audio> with Parsoid/TimedMediaHandler||mediawiki/core||master||+2 -1|
|Use <audio> elements for rendering audio files||mediawiki/services/parsoid||master||+40 -11|
|Output width and height attribs for <video>||mediawiki/extensions/TimedMediaHandler||master||+29 -25|
|Duplicate||None||T91574 Image for Audio Clip Resizes|
|Open||Feature||None||T64673 VisualEditor: Be able to set a non-image multi-paged item's display page (page=) in the media dialog|
|Open||None||T104237 Show nicer previews of complex (timed, paged, …) media inside VisualEditor|
|Resolved||cscott||T56844 Image / media handling (tracking)|
|Duplicate||None||T63769 Flow: Parsoid HTML for videos doesn't work|
|Resolved||None||T74912 Flow: Score vorbis content doesn't roundtrip (html/wikitext) properly|
|Resolved||Arlolra||T64270 Support video and audio content|
|Open||None||T133673 Add width/height attributes to the <audio><video> tag|
To me, this is stuck on the issue of <audio> and <video> tags and dimensions and what this will mean for Parsoid and VE. By default, an <audio> has an inherent size, but no width and height attributes (because it is not a "replaced element") . This means <audio> requires CSS to specify it's dimensions, and <video> can use CSS and/or attributes.
This really complicates things for Parsoid and VE, since our audio players have configurable width (but a fixed height). We will we have disjunct settings for dimensions between audio/video files, or unify it and just use CSS ? Or use both ?
I thought you had a suggestion just to use <video> for both at one point?
From my perspective, the goal is that Parsoid output should display "pretty close to correct" on a modern HTML5 browser with no special JS (that is, wikipedia-specific options may be missing, but all media settings that *can* be represented in standard HTML5 are), and should be "readable" with no special CSS -- that is, we already implement the "float left/right" and other image properties via specific classes applied to images, but the images don't *disappear* or not render if you don't load the MW CSS, they just aren't placed correctly.
So, trying to apply that general rule to the <audio>/<video> question, one option is to use actual width and height attributes on <audio>, which HTML5 ought to just ignore. This is "readable" w/o CSS, but it doesn't display "pretty close to correct" on pure HTML5 -- you'd need some JS thunk to transfer the width and height attributes to actual CSS width/height.
So using a <video> element for audio -- assuming that the HTML5 allows this and does the sensible thing -- seems preferable, since then you get correct height/width of the player in standard HTML5 without requiring any special JS magic. Sure, you give up a little bit of semantic information, but you could recapture that by looking at the media type of the embedded file.
In discussions today, we decided to go with <video> for everything, including audio, and use typeof="mw:Audio" to indicate audio files (since the viewer displays slightly different UI for audio vs video).