Categories
Media

Responding to Charity Navigator’s DA on the Humane Society of the United States

I was sent a link to a story and asked if it was true. The story noted that Charity Navigator, the charity watch dog group, had attached a Donor Advisory to the Humane Society of the United State’s listing, specifically because of the lawsuits related to the Ringling Brothers circus.

I was astonished. A donor advisory because of a single Endangered Species Act lawsuit? Many nonprofits are involved in lawsuits as they work to achieve the goals that are part of their underlying mission. I have a hefty annual PACER (federal court document system) fee because of the documents I download for the numerous environmental and animal welfare cases I follow—and I’m only following a tiny fraction of the cases I’d really like to follow.

Was the Donor Advisory given because the animal welfare groups lost the case? I would hope not, because penalizing nonprofits for taking a chance in court would have a chilling effect on their ability to do their work.

Was the Advisory given, then, because they also entered into a settlement for attorney fees? That seems to be more likely, especially considering the hefty size of the attorney fee settlement ($15 million). However, that a single incident related to a single court case would override 60 years of history in the Charity Navigator’s decision seemed both capricious and arbitrary. If civil lawsuits were not part of the arsenal of the organization, or if HSUS was in the habit of losing these cases and having to pay hefty attorney fees on a regular basis, then I think it would give most people pause before donating—but a single instance? Frankly, my first reaction was, “Well, aren’t you the precious.”

Charity Navigator also referenced the fact that Ringling Brothers filed a counter-lawsuit against the animal welfare organizations based on RICO—the Racketeering law. The reference to RICO does sound serious, if it weren’t for the fact that because of the RICO law’s overly loose design, and due to the Supreme Court’s over-reliance on the “intent” of Congress when passing the law, RICO’s purpose has been badly muddied over the years. Now, rather than go after the Mafia or sophisticated white-collar criminal networks, RICO has become a highly tempting tool in corporate America’s tool belt, especially after the recent findings in the Chevron RICO lawsuit related to the earlier lawsuit brought by poor Ecuadorians against the oil company for environmental damage to their lands.

Regardless, neither lawsuit—the original Endangered Species Act lawsuit brought by the animal welfare groups (not including HSUS), or the RICO case—ever reached a decision on the merits. The former was dismissed because of lack of standing, and the second never went to trial. As part of the attorney fee settlement, Feld Entertainment (parent company for the circus) agreed to dismiss the RICO lawsuit. The fact that the corporation filed a complaint should be seen as irrelevant and not figure into any agency’s determination of whether the organizations involved are sound or not. Not unless Charity Navigator believes that all one has to do is file a complaint in court and it’s automatically taken as true.

Charity Navigator noted the reasons why the Judge dismissed the ESA case for lack of standing, though the agency’s understanding of the legal documents and associated time line of all the events are equally confused and inaccurate. For one, the agency stated that Feld filed the RICO lawsuit after the ESA case was decided. Feld originally filed the RICO lawsuit in 2007 when Judge Sullivan denied the company’s request to amend its answer and assert a RICO counter-claim. The new lawsuit was stayed until the ESA case was decided in 2009, and Feld amended its original complaint in 2010, when the RICO case started up again.

I wanted to pull out part of the memorandum Judge Sullivan wrote in 2007 when he rejected Feld Entertainment’s request to amend their answer (leading to the RICO lawsuit). It relates to Feld’s implication that the animal welfare groups were involved in a complex and corrupt scheme to pay their co-plaintiff, Tom Rider that the company lawyers claimed they didn’t know about until 2006.

Finally, the Court cannot ignore the fact that defendant has been aware that plaintiff Tom Rider has been receiving payments from the plaintiff organizations for more than two years. Although defendant alleges an “elaborate cover-up” that prevented it from becoming “fully aware of the extent, mechanics, and purpose of the payment scheme until at least June 30, 2006,” Def.’s Mot. to Amend at 4, such a statement ignores the evidence in this case that was available to defendant before June 30, 2006 and does not excuse defendant’s delay from June 30 forward. Plaintiffs’ counsel admitted in open court on September 16, 2005 that the plaintiff organizations provided grants to Tom Rider to “speak out about what really happened” when he worked at the circus.

In other words, Feld’s lawyers found out about the “elaborate scheme” to fund Tom Rider, because the animal welfare groups mentioned funding Tom Rider during a court hearing in 2005.

As for that funding, it is true that the animal welfare groups paid Tom Rider about $190,000 over close to ten years. However, what isn’t noted is that some of that “money” wasn’t money at all. Rider was given a computer, a cell phone to keep in contact with the groups, a used van so he could travel around the country speaking out about the trial and his experiences with the circus, and various other goods. The groups also provided IRS forms for years 2000 through 2006 for Rider. When I added up the income for these years, it came to $152,176.00. However, after all of Tom Rider’s expenses were deducted, over the seven years he “took home” a total of $12,582, for an average of $149.78 a month. That’s to pay for all of his personal expenses—including a cheap dark blue polyester suit and equally cheap white shirt and tie he wore to the trial. (Tom Rider must have stood out for the plainness of his garb when next to Feld Entertainment’s $825.00 an hour DC lawyers during the trial.)

Among the small selection of oddly one-sided court documents that Charity Navigator linked, another was the Judge Sullivan decision denying the animal welfare group’s motion to dismiss the RICO case. What stands out in this document is a reference to the original Judge Sullivan decision, specifically a comment about the Rider funding:

The Court further found that the ESA plaintiffs had been “less than forthcoming about the extent of the payments to Mr. Rider.”

I compare this statement with Sullivan’s statement I quoted earlier, wherein Sullivan denied Feld’s request to amend its complaint because of the supposed underhanded and secret funding—an assertion that Sullivan rejected in 2007. The newer constradictory 2009 statement was just one of the many inconsistencies in Judge Sullivan’s decisions over the years related to these two cases.

But the last issue that Charity Navigator seemed to fixate on was Feld’s attempt to get confidential donor lists from the animal welfare groups. I’ve written about this request, and my great disappointment in Judge Facciola’s decision to grant the request.

Nothing will ever convince me this wasn’t a bad decision, with the potential to set an extremely bad precedent. Even when the discovery was limited primarily to those people who attended a single event, it’s appalling that a confidential donor lists can be given to a corporation who represents everything the donors loath and disdain—and a corporation with a particularly bad record when it comes to dealing with animal welfare groups and other people—not to mention its abysmal record when it comes to its animal acts.

The animal welfare groups settled because when you have a billionaire throwing $825.00 an hour lawyers at a case, and said billionaire doesn’t care how much it costs to win, it didn’t make sense to continue fighting a fight that was already stacked against them. When Judge Sullivan ruled on the ESA case, he should have recused himself in the RICO case, because to rule favorably for the animal welfare groups in the RICO case would be to say he was inherently mistaken in many of his assertions in the ESA case. When he turned the case over to the Magistrate Judge, Judge Facciola should have exercised independent thinking rather than just continue to parrot Judge Sullivan. In light of this judicial bias, and the fact that the groups would continue to spend way too much money fighting a lawsuit that the other side would deliberately stretch out as long as it possibly could, keeping up the fight was a lose-lose situation.

Top all that with the threat to the anonymity of their donors, and the groups settled. Point of fact, if they settled specifically to protect their donors, more power to them. They should be commended for doing so, not punished.

What’s ironic is in my original posts on the donor list request, I noted that if the animal welfare groups had to give these lists out, it would most likely impact on their ratings in sites such as Charity Navigator. Never in my wildest dreams did I expect that Charity Navigator would give a donor advisory to the groups just because a judge ordered that the list be provided, not that they were provided. The groups had planned on appealing this ruling before they settled, and frankly, I think they had a good chance of winning the appeal. But the very fact that a no longer existing possibility of an event is enough to trigger a donor advisory leaves me to wonder how many more innocent nonprofits will be labeled with a donor advisory just because someone sent in a newspaper article about the possibility of an event?

Kenneth Feld’s $825.00 an hour lead attorney, John Simpson, was recently interviewed for a legal publication. In it, he spoke about the donor list;

They didn’t want a situation where I’m taking the deposition of some donor asking — if you knew they were going to take this money to pay a witness, would you have given this donation?” Simpson said. “I don’t think they wanted that kind of discovery to take place. Some people might have made the donation anyway. But most of these people would have said — no, I wouldn’t have done that. And you would have been in the middle of their donor relations and potentially cutting off their donations in the future.”

In actuality, the one fund raiser that was at issue in the donor list request did specifically state that the money was for the lawsuit, and other requests for funds specifically stated the money was for Tom Rider’s media campaign. In addition, there is a legitimate concern about what would happen to individuals put into an intimidating situation by a high priced, DC powerhouse attorney. Mr. Simpson has a way of asking questions in depositions, and then subsequently paraphrasing the responses so that even the most innocent and naive utteranceseems dark, and dastardly. It was unfortunate that Judge Sullivan allowed his scarcely concealed disdain for Tom Rider to lead him to basically accept whatever Feld’s lawyers said, even though the animal welfare groups presented solid arguments in defense.

Lastly, Charity Navigator linked an article in the Washington Examiner, as if this was further evidence of good reasoning for the donor advisory. Might as well link Fox News as a character reference for the EPA, or The Daily Caller as a reasoned source of news for President Obama.

Just because something shows up in a publication online does not make what’s stated truth, or even reliable opinion. That a charity watch dog would link a publication known for its political and social bias, as some form of justification for a decision only undermines its own credibility. Yes, the HSUS and the FFA are involved in lawsuits with a couple of insurance companies regarding their liability coverage. As noted, though, it’s common for insurance companies to deny claims of liability when it comes to litigation fees. Kenneth Feld, himself, is involved in a lawsuit with his insurance company about it not wanting to pay those $825.00 an hour fees for Feld’s attorneys in the lawsuit with his sister.

However, there were several insurance companies involved with the groups and this court case. One way or another most, if not all, of the attorney fee settlement will be paid by one or more insurance companies.

An interesting side note about the insurance company lawsuits is the fact that the Humane Society’s lawsuit is being handled in federal court, while the Fund For Animals lawsuit is being managed in the Maryland state court system. This disproves one Feld Entertainment claim that HSUS and FFA are one organization (and hence, justifying Feld’s dragging HSUS into the lawsuit). The reason for the lawsuit split is that FFA is a Maryland corporation, while HSUS is not, and the insurance company was able to argue that it could move the HSUS case to the federal level because of jurisdictional diversity. Nothing more succinctly demonstrates that FFA and HSUS are not the same corporate organization. Yet HSUS has received a donor advisory for a lawsuit it was never involved in. FFA was involved in the ESA suit, but not HSUS.

There is so much to this case, too much to cover in a single writing, but I did want to touch on the major points given by Charity Navigator in its donor advisory. Will the advisory hurt an organization like HSUS? Unlikely. The Humane Society of the United States is one of the older, more established, and largest animal welfare organizations in the country. Its charity ratings to this point have been excellent. A reputable organization like the BBB lists it as an accredited charity, and one only has to do a quick search online to see that it is currently involved in many different animal welfare efforts across the country—from rescuing animals in North Carolina to defending American burros. If people donate or not to the organization it won’t be because of Charity Navigator’s listing, because most people wouldn’t need Charity Navigator to learn more about the HSUS.

But such donor advisories could negatively impact on lesser known, smaller charities. I hope that when Charity Navigator issues such a drastic warning from this day on, it does so based on a foundation that is a little less arbitrary, and much less capricious, than the one they used for HSUS and the other animal welfare groups involved in this court case.

Categories
Media Specs

Mozilla reluctantly embracing H.264

Recovered from the Wayback Machine.

Interesting doings this week on the HTML5 video front.

Brendan Eich of Mozilla has stated the organization will now provide native support for H.264. In Video, Mobile, and the Open Web (also cross-posted at his personal web site), Eich writes:

What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile.

Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance.

Douglas Perry in Tom’s Guide writes:

For Google, Mozilla’s complaint is a dent for the credibility of the Chrome strategy and the pro-open source campaign. If Mozilla drops WebM entirely, WebM is practically dead. Firefox isn’t significant in market share on mobile devices, but it is the 25 percent wild card on the desktop. Google will only be able to help WebM survive with the support of Mozilla, which gives Google/Mozilla about 55 percent of the total browser market (according to StatCounter). Without Mozilla, WebM drops to 30 percent and H.264 rises to 70 percent of the market.

On her blog, Mitchell Baker writes:

For the past few years we have focused our codec efforts on the latter part of this sentence. We’ve declined to adopt a technology that improves user experience in the hopes this will bring greater user sovereignty. Not many would try this strategy, but we did. Brendan’s piece details why our current approach of not supporting encumbered codec formats hasn’t worked, and why today’s approach regarding existing encumbered formats is even less likely to work in the future.

Andreas Gal, director of Mozilla research, sums it up:

Google pledged many things they didn’t follow through with and our users and our project are paying the price. H.264 wont go away. Holding out just a little longer buys us exactly nothing.

Google has only its self to blame if (when) WebM follows Betamax and HDD into tech oblivion.

Categories
Media Specs

Notes from writing HTML5 Media

Recovered from the Wayback Machine.

This last weekend I finished my latest book for O’Reilly: HTML5 Media. This is one of O’Reilly’s shorter books (about 100 pages), primarily focused at the eBook market, though you can get a hard copy with print-on-demand.

The book focuses on the HTML5 audio and video elements. I cover how to use the elements in a web page and go into detail on the attributes for each element, as well as cover video and audio codec support. I also devote a couple of chapters on developing with both elements, including how to create a custom control, as well as integrating the media elements with the canvas element and SVG.

In one chapter, I touch on the newest media element API functionality including the brand new and unimplemented media controllers and support for multiple audio, video, and text tracks. Though no browser currently provides support for captions/subtitles, I also explain how to use JavaScript libraries and SRT or WebVTT files to add captions and subtitles to videos.

I enjoyed working on this book. I enjoyed worked with the media elements, though I’m more partial to the video element. Working on the book was also a learning experience—even, at times, an eyebrow raising experience. I thought I would share with you all some of the notes I wrote while working on the book.

WebVTT versus TTML

The WHATWG group started working on a subtitle/caption format based on SRT (SubRip) text format. The original name was WebSRT, but it was recently renamed to WebVTT. The LeanBack Player web site provides a good review of WebVTT.

WebVTT is a pretty basic format, consisting of line numbers, timelines, and text with formatting options. There are plans to add additional capabilities, but what we have now should meet most needs.

There’s been interest in bringing WebVTT over to the W3C. However, the W3C already has a timed text specification, TTML. TTML is an XML based format that is more sophisticated than WebVTT, but also more complicated to use.

I covered WebVTT in the book in detail, but only briefly mentioned TTML. The reason I didn’t spend time with TTML is because of existing support and the industry movement away from XML.

None of the various JavaScript libraries I tested that provided some caption/subtitle support worked with TTML. They worked with SRT or WebVTT, but none that I tried worked with TTML.

Additionally, TTML is an XML format. Now, XML might have been the approach to take a half dozen years ago, when most everything at the W3C was heading in an XML direction. In the last several years, though, we’ve seen the popularity of the RDF/XML serialization fade in favor of Turtle or RDFa, and XHTML2 abandoned in favor of HTML5. SVG is still holding on, but now there’s rumblings of an API that will generate SVG or canvas API calls, and basically hide most of the XMLness of SVG from view. I vaguely remember reading something somewhere that the folks working on TTML were even thinking of creating a JSON version of the spec.

Whether intended or by accident, there is a subtle but noticeable shift away from XML in the W3C. At the same time, there is a strong core of support for XML formats in the W3C. Between both seemingly contradictory paths, I’m thinking we should just skip the interim pain and anguish of yet another format war, and go right to the end point. So I covered SRT and WebVTT and only mentioned TTML in passing.

Protecting the Users from the Big Bad Web Developers

I like HTML5 video and audio, I really do. I had a great deal of fun writing this book. However, despite my affection for these elements I must also admit to some irritation with their design and implementation. (Well, other than the fact that an entire block of the specification changed mysteriously one night, requiring a sudden and unexpected re-write in one of my chapters.)

The part about the HTML5 media elements I like the least is the seeming level of distrust directed at web page authors and developers.

For instance, if you’re creating a custom control and remove the controls attribute, you may think you then have complete control over the media playback. You don’t, though—at least, not in most browsers.

In the section of the HTML5 spec related to the media element’s user interface, implementors are advised to provide playback control in some manner regardless of whether the controls attribute is present or not:

Even when the attribute is absent, however, user agents may provide controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), but such features should not interfere with the page’s normal rendering. For example, such features could be exposed in the media element’s context menu.

If you right mouse click on a video element in Firefox, you’re given the options to play or pause the video, mute the volume, play the video in fullscreen, show or hide the controls, as well as save the video or play the video by itself in another page. Chrome provides options to play, pause, or mute the video, as well as show or hide the controls, open the video in another tab, or save the video. Opera’s context menu options are similar to Chrome’s, minus the option to open the video in a new tab. IE10 provides play, pause, mute options, the ability to save the video, and the ability to control playback speed. Safari is the only browser that doesn’t provide context menu options to control the video. At least, not yet.

There is absolutely no way to directly control what does or does not display in the context menu that the browser provides. There is no way to control some of the actions that people can take in the context menu, such as preventing the fullscreen display of the video, if you don’t want it played fullscreen.

If you’re providing custom controls for the video, you have to account for the fact that the video playback is being managed by the context menu as well as your controls. One of my examples in the book provides a video playback control that consists of separate buttons for play, pause, and stop. These controls are disabled based on what action the user takes. It seems like a simple act to just disable and enable the appropriate buttons at the same time you play or pause the video, but you actually have to capture two sets of events: the click events from the buttons, and the play and pause event from the video.

Of course, the amount of extra code to do something like enable and disable buttons based on playback is trivial. But what isn’t trivial is controlling which options are made available to the user. If, for whatever reason, you don’t want the video to be played fullscreen, there is absolutely no way to prevent this from happening with Firefox.

The only way to prevent the context menu from displaying for the video is to provide a transparent div overlay for the video, so that the context menu reflects the div element, not the video. That or turn the video element’s display off, and play the video by redrawing it into a canvas element—a case of overkill, just to be able to control video playback.

The conflict between the context menu and customization isn’t the only web developer/author restriction.

There are the times when the web page author wants the audio or video to begin automatically when the page loads. The media elements do provide attributes for this: autoplay and loop. To ensure automatic playback, the author removes the controls attribute, adds autoplay and possibly loop, and when the page loads, the media element begins playing. The web page author can also remove the audio element completely from display so all that’s left is the sound. The video element is, of course, left displayed, but the control UI should not be showing. We can’t control the context menu options, but at least the control UI isn’t displaying. Well, not unless scripting is disabled, that is.

If the user has scripting disabled, the control UI is automatically re-displayed with the media element—even if you don’t want it to be displayed. If scripting is disabled, you cannot control the visibility of the control UI. According to the HTML5 specification:

If the attribute is present, or if scripting is disabled for the media element, then the user agent should expose a user interface to the user.

I’ve been told by members of the HTML WG that “should” in this context is equivalent to “must”. The two terms are not the same, but I gather that they become one in HTML5 land.

Currently, only Opera provides a visual control UI when scripting is disabled. Firefox doesn’t display a visual control UI when scripting is disabled regardless of whether the controls attribute is present or not. Safari, Chrome, and IE currently do not display the control UI. If “should” is equivalent to “must”, then Firefox, Safari, Chrome, and IE are all in error in their handling of disabled scripting and the media elements. I imagine bugs will be filed, if they haven’t already been filed, and these browsers will also automatically add the control UI when scripting is disabled.

I hear people cheering. You’re cheering, aren’t you? You’re all insanely happy with the power given the end user with the HTML5 video and audio elements.

Most of us remember those times when we opened a web page and some horrid music was blaring, or a video automatically plays with some idiot in a suit talking about his constipation. If we’re at work, we keep our machines permanently muted, lest something embarrassing blare out at an inopportune moment. If screen readers are not sophisticated enough to automatically lower background sound when a page is opened, the background sound competes badly with the reader.

Automatic audio, bad. Automatic video, bad.

I also imagine most of you have forgotten your visits to sites where you expected music or a video to play, and how much you enjoyed a well crafted multimedia experience.

Consider sites devoted to movies. Currently the last of the Harry Potter movies, the latest Transformer, and the new Spielberg Super 8 are playing in movie theaters. All three movies have their own web sites. If you open all three movie sites, you’ll find extensive use of both audio and video media.

The Harry Potter site opens with a preview of the movie with its own custom control that automatically starts playing as soon as it is sufficiently loaded. Among the options not provided with this video are the ability to open the movie out of context of the frame, such as opening the video in fullscreen. At most you can start or stop the video, choose a different video format, or skip the video and go to the site offerings.

The site offerings page has audio playing in the background. In addition, the bottom of the page features an animated video of owls. You can do nothing to stop either.

The Transformer movie site also provides background sound, as well as a video that begins to play automatically and loops continuously in the splash page. When you enter the site, another video plays continuously in the background of the page. Again, sound is used. There is very little about the site that is text-based: it’s all eye and ear candy.

The Super 8 movie site provides an automatically playing trailer with its own control. The page also has background audio when the trailer is finished. One of the sections of the site is the Editing Room. This page features a video playing automatically in an old 8mm style. Once this video if finished, rows of film are displayed. You can click a control that opens another video, again in super 8 style, providing a back story for the movie. You’re provided with controls to play the video and mute the sound.

None of these movie sites provide a context menu for their videos, other than what you would expect to see with a Flash movie. None of the sites allowed you to open the videos in fullscreen or play in a separate tab, because the videos are part of an integrated whole. The sites don’t allow you to switch off audio that I can see. I realize that automatically playing audio can be irritating for some, and can play havoc with screen readers, but again, none of this is unexpected for a movie site.

These types of sites will never be created using HTML5— not because HTML5 isn’t capable of creating most of the effects, but because HTML5 deliberately circumvents finer control over the video element. Can you imagine what would happen with the Transformer site with scripting disabled? The browser would then automatically plunk the control UI over the video in the page, which would ruin the overall effect the page creator was trying to make.

The unfortunate consequence of making HTML5 video and audio unattractive for these sites is that once they start using Flash for one component of the site, they continue to use Flash for every component of the sites. If you open these pages and use a screen reader such as NVDA, the only sound you’ll get is the background audio because every last bit of the site is in Flash: the text, the menus, all of it.

We want these sites to consider using HTML5 instead of just Flash, because if they do, the sites will end up being more accessible rather than less. Yes, even if the HTML5 media elements don’t have a control UI, and audio and video are played automatically. If we want to convince people to use something other than Flash, we need to ensure they have the same level of control that they had with Flash. Currently, the HTML5 video and audio elements do not provide this level of control.

HTML Media and Security

During the recent brouhaha related to WebGL security, the HTML5 editor, Ian Hickson, discovered that the video element, as it was currently defined, would not allow the cross-domain access that the img element provides. In other words, if the video you linked in with the src attribute was not from the same domain as your web page, the video wouldn’t play. This restriction was lifted, and the video (and track) resources are now treated the same as image resources.

However, one of the safety features related to cross-domain resource access was the concept of canvas tainting. If the image or video drawn into a canvas element is from another domain, the canvas is marked as tainted (the origin-clean flag is set to false). When the canvas is tainted, the toDataURLgetDataImage, and measureText methods generate a security exception. You couldn’t circumvent the same-origin restriction by using Ajax, either, because it would not allow cross-domain resource access.

Of course, much of this has changed because of the WebGL security issues. Originally WebGL was limited to using only same-origin image access for canvas textures, but a more recent version of the specification allowed for cross-domain image access. WebGL developers wanted to add images (and potentially video) from other domains as textures for their 3D creations. Unfortunately, when the WebGL specification and implementations enabled cross-domain image access, they also opened up a security violation: the WebGL could be manipulated in such a way as to create a “data leak”, giving the web pages access to actual image (and video) data.

In order to allow WebGL to proceed without having to tackle the functionality causing the data leak (I’m told a daunting task), the WebGL community requested and received a new attribute that can be added to the img, audio, and video elements in HTML5crossorigin. This attribute allows same-origin privileges with cross domain resources, as long as the resource server concurs with this use. This is a concept known as Cross-Origin Resource Sharing, or CORS.

CORS is another specification in work at the W3C. It originated as a way for web developers to access cross-domain resources using XMLHttpRequest (Ajax). The concept has since been expanded to include workarounds for the same-origin security restrictions in other uses, including the newest related to canvas tainting.

It sounds all peaches and cream except that there are issues related to the concept, especially when accessing image and video data from cloud services such as Amazon’s AWS or centralized image systems, such as Flickr. For CORS and the crossorigin attribute to work, these services must be willing to support CORS. The WebGL and other developers assumed the sites would be more than willing to do so. However, I know that Amazon has already expressed reservation about supporting CORS, and I wouldn’t be surprised if there wasn’t some reluctance on the part of other services.

I also had reservations about the breathlessly quick addition of crossorigin to HTML5, starting with the unanswered question, “What would WebGL had done if HTML5 was too far along in the recommendation track to add this change?” I still have concerns about quickly adding in functionality that routes around security protocols because another specification needs to have this functionality because of a security violation. I’ve long been a fan of 3D effort on the web, beginning with the earlier VRML and continuing with my interest in WebGL (I covered it in my Painting the Web book). However, I’m even more of a fan of web security. That and a stable specification. What would have happened if WebGL had made this request after HTML5 had progressed to candidate recommendation status?

Yes, I am a stick in the mud. I like stable specifications and secure web pages. I’m just old fashioned that way.

Anyway, for those wanting to integrate HTML5 video and canvas element, be aware of this very new functionality. You won’t find it included in the HTML5 Last Call document, you’ll only find it in the HTML5 editor’s draft.

Codec Support

You would expect to find tables with audio and video browser container/codec support littering the internet, and you do. The only problem is, none of the tables seem to agree.

Trying to determine exactly what container/codec each browser supports is actually a pain in the butt. I’m sure each and every browser has a page somewhere that explicitly lists what it supports in all possible environments. Wherever these pages are, though, must be one of the better kept web secrets.

It’s not as if there’s a simple yes/no answer to audio or video codec. After all, if you use the HTMLMediaElement’s canPlayType method with various audio or video codecs, you’ll either get a “maybe”, “probably”, or an empty string. Maybe and probably are not normally viewed as decisive words. It also doesn’t help when Chrome answers either maybe or probably to everything.

Then there are the quirks.

Firefox and Chrome only like uncompressed WAV files. Opera and Safari don’t seem to mind compressed WAV files. Technically, though, all four browsers “support” WAV.

Both these statements are true: only Safari supports AAC; Safari, Chrome, and IE support AAC.

If you use a tool such as the Free MP3/Wma/Ogg Converter (http://www.freemp3wmaconverter.com/), you’re given an option to convert your sound file to several different formats, including AAC and M4A. Many people will tell you AAC and M4A are one in the same. Well, yes and no.

The AAC option creates an AAC file that is packaged in a streaming format called Audio Data Transport System (ADTS). The M4A option is an AAC file that’s packaged in MPEG-4. Since Safari can play whatever QuickTime can play on a system, and QuickTime can play the ADTS AAC file, the AAC file only plays in Safari. Chrome and IE can also play the AAC file, but only if it’s wrapped in the MPEG-4 container, which Safari also supports.

But wait…there’s more!

No, no. I’m just joshing you.

Well, there really is more but I don’t want to be cruel.

The confusion about support is further exacerbated by the politics surrounding container/codec support. Yes, Chrome supports MP4. No, Chrome does not support MP4. Yes, Ogg is the open source community’s fair haired child. No, WebM is the open source community’s fair haired child … they just don’t know it yet. Speaking of WebM, yes, WebM is a video container/codec, but it’s also an audio container/codec—just leave out the video track.

Remember when everything was going to be Ogg and life was simpler?

Anyway, to add to the audio/video container/codec noise on the internet, my own versions of browser/codec support for the HTML5 audio and video elements.

Are they accurate? Sure. Why not.

What day is it?

Popular HTML5 audio container/codec support by browser
Container/Codec IE Firefox Chrome Safari Opera
WAV(PCM) No *Yes *Yes Yes Yes
MP3 Yes No Yes Yes No
Ogg Vorbis No Yes Yes No Yes
MPEG-4 AAC Yes No Yes Yes No
WebM Vorbis No Yes Yes No Yes

*Make darn sure the WAV file is uncompressed

Popular HTML5 video container/codec support by browser
Container/Codecs IE Firefox Chrome Safari Opera
MP4+H.264+AAC Yes No *No Yes No
Ogg+Theora+Vorbis No Yes Yes No Yes
WebM+V8+Vorbis No Yes Yes No Yes

*Google has announced that Chrome will not support H.264. However, there are faint traces of support—ghosts if you will—still left in Chrome.

Official HTML5 Video Mascot

The official HTML5 video mascot is ….

Big Buck Bunny!

Categories
HTML5 Media Specs

CNet story on HTML5

Stephen Shankland of CNet published an article, Growing pains afflict HTML5 standardization. He sent me an interview email and quoted a small portion of the response. I believe he quoted me fairly. However, I wanted to publish the entire interview, so you can see the material not included.

—begin interview—

> –What are Hickson’s shortcomings?

The issue is less about one individual’s shortcomings and more about a single individual given what amounts to dictatorial powers (a phrase Ian has himself used) about what is, or is not, in HTML5. Ian is a very capable person, but he believes that the best, quickest way to create a specification is if one person makes all the decisions about what is in a specification. Ian also has strong, rather inflexible, opinions about the future of the web, and the future of HTML. One person with such strong, inflexible opinions, and with virtually unlimited control over the HTML5 specification contents, is not a good thing.

Ian also has had little exposure to web communities outside of the browser developer community. In fact, he believes that the Implementers, as he calls them, should have final say in all aspects of HTML5. Yet there are groups of people–web developers and designers, tool and application builders, folks concerned about accessibility, eBook creators and authors, and so on–just as impacted by what happens to HTML5 as the browser developers. Many from these communities have had to fight, sometimes for years, to add even the simplest modification to the HTML5 specification.

The situation is made worse because there are two versions of the HTML5 specification: the one at the W3C, which I think of as the official version, and a “shadow” version at the WhatWG. If Ian’s opinion is overridden in the W3C HTML Working Group, he’ll reluctantly make the change in the W3C version of the specification, but leave the text unchanged in the WhatWG version.

The existence of both documents confuses the web community about which document _is_ the HTML5 specification. When the specifications were the same, this wasn’t as much of a problem. Now that there are several significant differences between the specs, though, the existence of both is a very serious issue.

> –What’s the best way to rectify the situation?

In my opinion, the HTML5 specification would be vastly improved if there were a small team of experienced specification editors, rather than one single person given such unlimited control. I’m not sure, though, if Ian would be willing to work with a team, or to give up any editorial control in the specification. He may choose to quit, instead.

There was also an early Working Group decision to give both Ian and another person editing powers over the HTML5 specification, and this earlier decision has been used as a barricade against the idea of bringing in new editors. However, the other individual who was once involved with HTML5, quit sometime ago. His quitting should have opened the door to adding new editors.

You’re a writer. You know how important it is to have others review your material—to catch typos or fix awkward or confusing phrases; to question assumptions you’ve made, or whether your opinion may be overly influencing how you perceive an event.

This type of collaboration is just as important in a specification. More so, because the fewer people with actual authoring capability in the specification, the more likely personal bias has undue influence, and the fewer needs of the community are met.

> –Is there still a role for the WHATWG? If it were to disappear tomorrow, what would happen to HTML5 development?

The WhatWG is an unusual group. It gives the appearance of being egalitarian because anyone can subscribe to the WhatWG email list and make suggestions about the WhatWG documents. However, actual membership in the WhatWG was by invitation, and includes a small handful of people, some of whom have quit working with the WhatWG years ago. Yes, anyone in the WhatWG email lists can make a suggestion, but only if they manage to convince Ian of the worth of the modification does it get incorporated into to the specification.

Ian can supposedly be overridden by the small, closed group of actual WhatWG members, but again: many of this group have quit working with the WhatWG, and the rest, well, their interests aren’t necessarily the same interests of many in the web community.

At this time, I believe that the existence of the WhatWG does more harm than good. Its existence has fractured the community interested in HTML5, leading to the contentiousness that has dogged the HTML5 effort. The existence of duplicate documents in both the W3C and the WhatWG confuses the web community. That the WhatWG documents now differ from the W3C documents, further exacerbates the problem.

If the WhatWG were to disappear tomorrow, work on the HTML5 specification would continue. I believe that, after the initial shake up, work would progress on the HTML5 specification more rapidly. If there is only one group of people working on the HTML5 specification, and only one document, people would have to work through their differences. There wouldn’t be an ‘escape route’ for a subset of the people, and there would no longer be “the WhatWG” folks, and the “W3C folks”. It would be just people, working on HTML5.

> –Has the W3C truly shouldered the burden of HTML5 standardization?

In my opinion, once references to the WhatWG email lists, documents, issues database, FAQ, and so on are removed from the W3C HTML5 specification, and the W3C truly accepts ownership of the specification, then the organization will have fully shouldered the burden of HTML5 standardization.

> –What are some specific examples of HTML features that you felt Hickson handled poorly?

First, I want to mention some of the HTML5 features I believe Ian has handled well in the spec. He worked to standardize the browser object model, to develop audio and video elements that can support multiple codecs, incorporated SVG and MathML into HTML, helped clarify some items left ambiguous in HTML4, and a host of other good work.

The thing is, though, Ian agreed with most of these items. When he agrees with you, he can be very efficient. Even if he disagrees with you, but he personally likes and respects you, he’ll be more amenable to listening to your feedback.

However, if he doesn’t agree with you, and you’re not part of the group with which he surrounds himself, he can be extremely obstinate about modifying the HTML5 specification. To the point of absurdity at times.

Case in point is how Microdata came about. A couple of years back, the RDFa community wanted to incorporate modifications into HTML5 so that RDFa could be used in HTML, as well as XHTML. We were asked to provide use cases, and we did; a significant number of use cases, probably more than has been provided for any other aspect of HTML5.

Ian responded to the use cases and requirements not by agreeing, and adding support for RDfa; not by saying no, RDFa shouldn’t be incorporated directly into the HTML5 specification. What he did, instead, was invent an entirely new way of handling inline metadata called Microdata. He had added Microdata to the HTML5 specification without once counter-proposing it as an alternative, and without _any_ discussion within the community (WhatWG or W3C). Ian didn’t like RDFa, therefore Ian created something new.

Eventually the RDFa community realized that incorporating RDFa directly into the HTML5 was unnecessary and added to what is an overly large document. A member of the community, Manu Sporny, created a separate document that discusses how to incorporate RDFa into HTML5, which is on a separate publication track.

Several folks in the W3C HTML WG suggested that Microdata also isn’t an essential component of the HTML5 specification, and should be split into a separate document. Not eliminated, just split off. Ian disagreed.

Eventually we ended up having to go to a poll and get a co-chair decision to split Microdata into a separate specification. However, if you look at the WhatWG version of the HTML5 document, Microdata is still incorporated.

This is an example of a major change in the spec that was not handled well by Ian, and is still not being handled well by Ian.

Another instance of an HTML feature I felt has been handled extremely poorly is a single attribute that has been under discussion for over three years: the table summary attribute.

The table summary attribute is a way for people to provide a helpful description of a complex HTML table so that those people using assistive devices, such as screen readers, could better understand how to navigate through the table. It is optional, and should only be used with complex tables.

Ian felt that the attribute was used incorrectly, and therefore he deprecated it (or, in HTML5 terms, made it “obsolete but conforming”). Many in the accessibility community protested because, in their opinion, there is no other way to incorporate this useful information so that it would be available to those using screen readers or screen magnifiers, without it also being exposed to those not using these devices (and who didn’t need this information, because they could actually see the table).

Instead, Ian added a convoluted section to the table element that describes numerous ways that people could incorporate text into their content so that this information is provided without having to use the summary attribute, because, in Ian’s opinion, the summary attribute has not been used correctly and is therefore harmful. However, it is not within the scope of the HTML specification to tell people what they should use in text surrounding HTML tables. It is also not within the scope of the HTML specification to tell people how to use elements, if such usage isn’t coached in such a way that the usage is a requirement for validity. An HTML specification is not a user guide.

For three years the debate on this simple little attribute has been ongoing without resolution. It’s still a pending issue in the W3C issues database. It’s still waiting resolution.

Three years. One single attribute. Tell me something: wouldn’t a reasonable person decide at some point that perhaps if the accessibility community really wants this item so badly, that it should be kept in the HTML5 specification as a valid, conforming attribute? With an understanding that the accessibility community then has an obligation to ensure it’s used correctly in the future?

At what point in time in three years did this item go beyond reason?

> Sorry, one more–since I’m not a technical expert, could you try to boil down the hidden attribute technology issue?

The hidden attribute originated as an attribute named irrelevant. It was created as a way to mark “irrelevant” web page elements that are not meant to be displayed by the user agents. Why not displayed? Because when the element is marked with the irrelevant attribute, it’s not relevant at that time. It was renamed to hidden because a) people were confused at the irrelevant concept, and b) many people can’t spell the word.

The hidden attribute functions exactly the same as setting the CSS display property to “none” for an element. Whatever element is so marked is removed from the page flow, and is not rendered by any user agent (browser, screen reader, or otherwise). To display the element, you have to use JavaScript, just as you do with the CSS display property.

Where the hidden attribute supposedly differs from the CSS display property is that there is “semantics” associated with the hidden attribute, not associated with the CSS display property. The hidden attribute marks “irrelevant material”. Yet what is irrelevant about page content that is still active? According to the spec:

“Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.”

Truly irrelevant page contents should be created and added to the web page when needed, and removed from the page when no longer needed. That’s the way you handle “irrelevant page contents”.

In effect, there are no semantics associated with the hidden attribute. Its use is purely for presentational purposes. And since we decided long ago that we’re not going to tightly integrate presentation with structure in HTML, not only is hidden redundant, its existence is counter to 15 years of hard work to eliminate such tight integration.

–end of interview

I don’t necessarily agree with Shankland that the issues are minor. I also don’t agree with anyone who says that the browser companies are the only parties that matter when it comes to HTML.

True, the browser companies can be a major roadblock if they decide not to implement a feature. At the same time, though, it’s essential to take into consideration the needs of the entire web community, not just the browser companies.

The current HTML5 situation is little different than an IT group in a company telling the end users that they, the IT group, will decide what gets implemented and when, and the users should just shut up, and be happy to get what they get.

Categories
Media Money

Frugal music

This week, I realized that my older first generation, fifth generation video ipod only has about enough room for a few hundred songs. In the years since I bought the device, I’ve managed to add an additional 15 GB of music to the already extensive collection of music from previously purchased CDs. And I’ve increased the repertoire of music I own, and can pick from any number of genres to listen to on a given day: from rock and roll, to new age, classical, jazz, folk, reggae, blues, swing, instrumental, show tunes, and even opera. And I don’t like opera.

Best of all, I didn’t have to go broke getting the music, nor do I have stacks of plastic CD cases littering the hallway. As I discuss in The Frugal Algorithm, there are many musical options for the frugal now available.