This is a document written using ReMarkable, a shorthand syntax for generating HTML.

{	"date"		:	200906191450,
	"updated"	:	200906231224,
	"licence"	:	"cc-by",
	"tags"		:	["web-dev", "code-is-art", "annoyances"]
}

<section>
# An Open Letter to Mozilla Regarding Their Use and Promotion of HTML5 Video #

Update:
=======
*Success!* Mozilla have <published a new article (//hacks.mozilla.org/2009/06/html5-video-fallbacks-markup/)> on <hacks.mozilla.org> describing HTML5 Video with fallbacks and even link to <Video for Everybody (/code/video_for_everybody)>!

---Even better news though is the actual use of Video for Everybody on a new page demonstrating “<What’s New in Firefox 3.5 (//mozilla.com/en-US/firefox/video/firefox-3.5.html)>”! This is a great stride ahead for sensible and forward-facing video embedding in websites.--- [well that didn’t last long]

I would like to thank Mozilla for their support and putting up with my ranting, and also all those who signed the letter and supported me on Twitter, OSNews and elsewhere on the ’Web.

							* * *

*Dear Mozilla*, _
The content of this letter is based upon <this blog post (//hacks.mozilla.org/2009/06/html5-video-fallbacks/)> at the <hacks.mozilla.org> initiative.

HTML5 video is coming, and a million web-developers up and down the ’Web will be soon looking for advice and sample code to make use of HTML5 video. Web-developers vary massively in skill and understanding of the open principles of web-development, promoted by yourselves via the <~Mozilla Manifesto~ (//mozilla.org/about/manifesto.en.html)>.

We cannot expect all developers to understand the knock-on effect of code snippets that they are copy-pasting from people’s sites. It is one thing to educate people with a piece of code, it is another to communicate effectively the principles behind a piece of code. Some developers do not care, and never will—that is a fact of life.

In presenting a JavaScript-only method for using HTML5 video, you are promoting to developers a number of major drawbacks, counter-intuitive to the points outlined in the ~Mozilla Manifesto~.

:: Accessibility
	Screen-readers may be presented with a hurdle by a JavaScript solution. Users may also be using browsers that
	developers are very unlikely testing in, who may inadvertedly break support by using JavaScript features that are
	either not present, or not compatible with JavaScript implementations in these browsers. Requiring JavaScript
	may also hinder use of <{WAI-ARIA} (//w3.org/WAI/intro/aria)>.

:: ``<video>`` is an element, not a JavaScript object
	In other blog posts you have promoted the ``<video>`` element as a glorified ``<img>`` element—being fundamentally
	a part of the document with all the same capabilities CSS-wise.
	Some <incredible examples (//zachstronaut.com/lab/isocube.html)> have been demonstrated that go well beyond what is
	possible with plugins.
	
	Just as you would never expect JavaScript to be required just to view an image (and bad code be responsible if so),
	the same should be true of video.

:: JavaScript still has no solid security model
	By requiring JavaScript, you are also requiring people to switch on JavaScript for sites that they may otherwise
	not trust. Viruses and malware have travelled far by hiding behind videos, and XSS attacks could be done by
	forcing people to enable JavaScript for a site so they can see a video.

:: Non-aggregatable, mashable
	The use of JavaScript promotes a traditional browser-centric model. As a document format, HTML goes beyond just
	the traditional ‘web-browser’ and may be parsed in many ways and environments outside of the traditional browser.
	
	RSS aggregators (particularly web-based ones) may not execute JavaScript as a safety measure,
	thus preventing the user from seeing the content.
	
	Robots and spiders also would not be able to spider HTML5 video content if it is only present with JavaScript.
	That alone could prevent all kinds of innovation that we cannot yet conceive. What if a TV station could be
	created using nothing but ``<video>`` tags found on the ’Web? Requiring JavaScript to see ``<video>`` largely puts
	a stop to mash-ups wanting to pull video from the ’Web.


A Solution Has Been Presented
=============================
A solution for using HTML5 video with fallbacks for Adobe Flash, QuickTime and Windows Media Player that works on a wide range of browsers without the need for JavaScript has been developed, it’s called “<Video for Everybody (/code/video_for_everybody)>”.

|	The market is made up of more OSes, browsers and processor architectures than it was five years ago.
|	More people (especially geeks) are browsing with AdBlock / NoScript / FlashBlock than ever before.
|	We can no longer just assume people are going to have Flash and are allowing you to use it.
|
|	The same rules apply to video. If my platform / device / browser of choice cannot see your video, or you do not
|	offer me the means to download the video to view offline, then I don’t see whatever it is you’ve got to show me.
|
| Kroc Camen: <“Video for Everybody” (/code/video_for_everybody)>

It helps web-developers promote HTML5 video as an equal citizen alongside Flash and QuickTime. The necessary playback is chosen automatically based on browser / operating system capabilities, all without JavaScript. If the video is not able to play within the browser helpful fallback text is displayed to offer the users a means of downloading the video file, or how to get the video to play in the webpage by installing an HTML5-capable browser, Flash or QuickTime.

This means that it is almost impossible for the user to not be able to view the video—one way or another—and they are not hindered from viewing the content by bad design decisions such as requiring JavaScript to use a native HTML tag.


What You Can Do
===============
I ask you to please do the following:

:: Remove the content of that blog post and replace it with new content that covers two main factors:
	1.	How to insert HTML5 video using HTML and providing levels of fallback for legacy systems
	
	2.	Why providing good fallback options / text is so important to a range of users and devices, and therefore
		why JavaScript should only be used to enhance a solution rather than be a requirement

:: Adopt HTML5 video (with fallbacks) across all Mozilla branded blogs, sites and ’Web properties, unilaterally
	I personally don’t have Flash installed, it is—after all—an optional install, and I don’t like what it does to my
	computer. It seems counter to the work you are doing providing HTML5 video in your browser that I cannot see your
	<own announcements (//blog.mozilla.com/addons/2009/06/10/introducing-add-on-collections/)>.
	
	I believe Mozilla need to make a company-wide (and community-wide) commitment to using HTML5 video in all of their
	ventures—past, present and future.


							* * *

*Signed:* _
(the undersigned)

•	Kroc Camen—((<camendesign.com>—HTML5 web-developer, _publicus defensor_))
•	John Drinkwater—((<johndrinkwater.name>—Open Web Cheerleader))
•	Thom Holwerda—((<Cogs Can Think (//cogscanthink.blogsome.com/)>—OSNews Managing Editor))
•	Carlos Martins—((<abertoatedemadrugada.com>—Web Developper / Programmer / Blogger))
•	Brad Cooper—((<willworkforart.net>—{{UX|User Experience}} / Interface Designer))
•	Nick Stevens—((<twitter.com/nickstevens>—Web Designer / Developer))
•	Mike Laughton—((<libdmtx.org>—Occasional Web Developer))
•	Jordan Spencer Cunningham—((<ipfsquared.wordpress.com>—Author / OSNews Editor / Upstanding Blogger))
•	Antoni Grzymala—((<antoni@grzymala.info>—Systems Administrator and integrator with a special focus on accessibility))
•	Kurtis Nusbaum—((<klnusbaum@gmail.com>—Web Designer / Programmer / Trilinos Developer / Blogger))
•	Neil Santos—((<dpi.sourceforge.net>—Head code monkey and mad tinkerer for Qool Media))
•	Justin Burris—((<prxi.net>—Interested in mobile devices, web interfaces, AI, OSs and programming languages))
•	Evert Mouw—((<animamundi.eu>—part-time system administrator, student of medical informatics and political science))
•	Ricardo Governa—((<ricardo.governa.net>—New Technologies / Media / Telecommunications Consultant))
•	Torbjørn Vik Lunde—((<twitter.com/torbjornlunde>—Graphic Designer / Web Designer))
•	Morgan Johnson—((<morgan@kf4ytr.com>—Occasional Web Developer))
•	Witold Krakowski—((<wkrakowski@gmail.com>—System Administrator and occasional web developer))
•	Fernando Medina—((<tunicaragua.com>—Operate a retail site with need for video))
•	Dave Snowdon—((<davesnowdon.com>—Professional web developer))
•	Xavier Mouton-Dubosc—((<dascritch.net>—Freelance Web Developer))
•	Nikolai Lifanov—((<lifanov.com>—Network Administrator))
•	Vince Tingey—((<michaelsmith.ubc.ca>—Sysadmin at the Michael Smith Laboratories, UBC, BC, Canada))
•	Marcin Szewczyk, Wodny—((<wodny.org>—C/C++ programmer, network admin, OSS fan and occasional web developer))
•	Leandro Guimarães—((<dutras.blogspot.com>—Data Admin, PostgreSQL community member, free software supporter))
•	Georgi Ivanov—((<netage.bg>—Web Developer))
•	Andrew Pam—((<sericyb.com.au>—Software Developer, researcher and Open Source advocate))
•	C. Williams—((<penquincoder@gmail.com>—System Admin / Web Developer))
•	Ville Koskinen—((<vrkosk@iki.fi>—Bioinformatics software engineer))
•	Ross McDonald—((Professional Web Developer working with open technologies, all cross platform))
•	Andy Elvey—((Analyst / Programmer and Intranet [_sic_] report-writer))
•	Kristian Meier—((Web application developer and web security analyst))
•	Rei Kagetsuki—((Software and Hardware Design and Development))
•	Anthony Harris—((Novice web developer and game designer))
•	Kiefer O. Hicks—((bleeding edge web programmer))
•	Loris Cuoghi—((Occasional Web developer))
•	Fernando Scandolo—((Web app developer))
•	Markus Ingalsuo
•	Kirby Dunsmore
•	Robert Watkins
•	L.J. Boatwright
•	Ryan Quinn
•	Steven Rowat

</section>