Web Captions 4 – Final Styling Recommendations
After exploring history, what formats the web natively supports, basic UX content principles, and what actually works cross-browser, it’s time to talk about my final caption styling recommendations.
What You Should Do
In Your VTT file
First, start with a VTT file. Make sure the text is accurate to the content presented. Make sure it stays on screen for the right words-per-minute check that Subtitle Edit can help provide for you.
And avoid positioning elements to the left or right at all costs, unless the content demands it. If you must, the only universal way to do so is to set position and alignment together (e.g. position:0 and align:start OR position:100 and align:end). You can follow the issue with this bug filed with the W3C working group for Timed Text. And finally, set line:98% on every bottom-aligned cue to maintain a universal look cross-browser.
You may add bold and italic within the text. I would steer away from underline, even though it works, as this is the web. Some may see it as a link.
Do not put any other visual style on or within the VTT. Do not rely on tag types, classes, or IDs to set any type of style.
And don’t forget to validate your VTT file.
In Your HTML
Never set your track’s srclang attribute to one that already exists. Safari will ignore all results but the first.
In Your CSS
Universally, all that can be set in CSS is the foreground text color and its attributes. The CSS value “inherit” is also not universally applied, so everything must be explicitly set on the ::cue itself. And finally, do not set the text color to anything darker than #aaaaaa. Mac browsers force a black background behind all text. Looks like you’re stuck with white-ish.
Additionally, the general standard for caption text is a ‘sans-serif’ family, so be careful deviating.
Do not embed the CSS in your VTT file.
Conclusion
There are a lot of limitations for designers, and some key use cases can’t even be met, like BBC and other European needs for colored speaker text.
But not all is bleak. Great tools like Subtitle Edit can really make the content lifting portion far easier.
There’s even more bugs that exist in every major browser (Chromium family, Firefox, and Safari), but at least in my cursory review, it seems many have stagnated for years. The great news is that the W3C committee, Mozilla, and Chrome have been pretty responsive so far as I’ve reached out. Safari, per usual, has yet to get back to me on browser bugs. So please get involved and promote the need if you’d like to see change here.
Hope you learned as much as I did in this series, and I’d love to hear what you’ve discovered. Feel free to drop me a line about what you’ve discovered.