Categories
Mozilla Web Development

About HTML5 Boilerplate

I wanted to take a few minutes to discuss HTML5 Boilerplate, a template that’s rapidly going around the web development community. I’ve had a few email threads and chats about this recently and thought I’d just put all my thoughts together in one place now.

I’ll start by saying it’s not a bad template. It’s actually quite good and encompasses many best practices as well as incorporates fixes for many common problems (clearfix, pngfix). What I’d like to make note of is that it’s not really bringing you HTML5 and lots of what it does has nothing to do with HTML5.

Not Really HTML5

For starters you’re not really getting HTML5. HTML5 Boilerplate uses JavaScript library called Modernizr. As their website explains:

Modernizr does not add missing functionality to browsers; instead, it detects native availability of features and offers you a way to maintain a fine level of control over your site regardless of a browser’s capabilities.

It also lets you apply styles to the new semantic HTML5 elements like <header/>, <footer/> <section/>.

What don’t you get? Well for starters you’re missing <canvas/> and <video/>. Other than tag elements you’re also missing things like Gelocation, Drag&Drop, web storage, MathML, async attribute on <script/> to name a few. SVG?

Pretty much all the headliners in the HTML5 spec aren’t included. Some like <canvas/> could be helped by way of explorercanvas, but that’s not in there by default.

HTML5 Boilerplate also makes reference to things like Access-Control which still doesn’t work in older browsers. They also suggest setting mimetypes for HTML5 video. This isn’t by any means bad, but hardly makes <video/> useful to everyone. Browsers are still pretty fragmented between webm, ogg, and h.264 (mp4). Then you have older versions that support none of these.

Using gzip on ttf,otf,eot files seems to be a good idea. WOFF however are compressed and correctly excluded.

WTF Does This Have To Do With HTML5?

There are lots of things that I would consider best-practices, but would hardly consider to be HTML5. For example pngfix for IE6, .clearfix, apple-touch-icon, console.log wrapper being the most obvious.

Setting far-future cache times are good, and disabling Etag is a good idea, assuming you rename the file every time it updates. But what does this have to do with HTML5? Is this even practical for everyone?

Then there is some interesting css work like inline print block. There are also a couple of nice usability fixes that I like. Regardless, they are just good design and UX. Not HTML5.

As for the graceful degradation and mobile optimization… that’s design and css. There is no reason why any HTML4 or XHTML site couldn’t do that today. Most choose not to do so in favor of serving different content (including ads) to different devices.

Options -MultiViews… grumble. I’m not particularly fond of it, but again if it works for you, I wouldn’t push you away from it.

Removing www… I hate this one. In my experience the only people who insist upon this have never dealt with websites with high volume and had the requirement of using a CDN by way of a CNAME in front of your site (your domain must be an A record). What is the real benefit here other than some sort of URL ascetics? I’ll let you in on a little secret: The IP address for this blog is hardly maximizing feng shui.

Best Practices != HTML5

Many of these things are best practices. Some of these depend on your application. Most of these aren’t HTML5.

Lets just clarify that HTML5 is not about disabling MultiViews getting rid of the Etag header and being able to style <section/> elements. HTML5 is more than that.

Your ability to use HTML5 still depends on widespread adoption of modern browsers like the latest and upcoming versions of Firefox, Chrome, Safari, Opera, and even IE 9.

Again, HTML5 Boilerplate is not a bad starting point. My point is you’re not really getting as much as it initially sounds like. It’s a bunch of fixes you likely already have in your toolkit already assembled. If that’s helpful: great. But don’t think your missing out on a new era of the Internet by not adopting it. Most good web developers have done these things for a long time now.

Categories
Mozilla

Filing Good Bugs

Writing good bugs is important when dealing with software development. I deal with several Bugzilla installations meaning I’ve got some experience with both good and bad bug reports. While the specifics may vary based on the product your submitting a bug report for these basics rules will make life easier for everyone. In many cases will even help things get resolved quicker.

Bugs that are easy to triage, sort and sift are easier to take care of than those that are cryptic and require more investigation. If you want your issue to be addressed promptly make sure you facilitate the process by writing a good bug report. It’s not difficult and doesn’t require much technical know how, it just requires being explicit yet concise. If more information is needed a developer can request it and explain how to capture it.

Summary

A good summary is explicit yet brief. Upon reading it the purpose is clear and little is left to question. Here are several poor summaries, and the ideal way to submit them:

Bad: “add me to planet”
Good: “add john doe to planet.mozilla.org”. There’s no ambiguity there. Just reading the subject I can distinguish it from others in the queue.

Bad: “site crashes browser”
Good: “visiting a video permalink page crashes IE6”. Less ambiguity just make sure to add the url to the bug.

Bad: “javascript error”
Good: “Contact form has a javascript error in Chrome”. Again less ambiguity is key.

Description

Descriptions should ideally be front loaded with the important information. If it’s a bug report and not a request it should be followed by steps to reproduce including what you see, and what you expect to see. Reference attachments as appropriate (screenshots can be helpful).

Bad: “Visiting a video permalink page crashes IE6.”
Good: “Upon visiting a video permalink page in IE6 the video automatically starts playing. About 10 seconds into the ad the browser crashes. I am able to reproduce this consistently at the following link: http://domain.tld/…”.

Bad: “Contact form shows a JS error, can’t submit.”
Good: “When attempting to submit the contact form [http:/doman.tld/…] in IE 7 I get a “object expected” error and it refuses to continue.”

Always include URL’s when applicable or examples on ways to reproduce the error when possible. It’s hard to act upon “several pages” when your site has over a half million pages.

Attachments

Screenshots, traces, debug logs, mockups are generally helpful. As a rule make try to use browser-readable formats when possible. JPEG, GIF, PNG for images, txt, or if you must PDF for documents. Having to open PowerPoint or Word to view your screenshot isn’t cool. It makes people avoid what would be helpful information. Explanations on what you’re seeing and expect to see are also helpful for when it’s not obvious to someone else.

Severity/Priority

Always try to use restraint when setting the severity or priority on a bug. Unless it’s truly a show stopper avoid using the most severe status. Generally speaking most “normal” or a P3 (on a P1 – P5 priority scale). Remember The Boy Who Cried Wolf.

Version

If you know the version, please specify it. It helps when several versions of a product are still floating around.

Product/Component

I put this toward the bottom for a reason. Making a best guess is the most you can generally do. Just be sure to read the entire list before deciding as the best option may be beyond the one you’ve already found.

Following these simple guidelines can go a long way to making sure bugs get resolved quicker.

Categories
Internet Mozilla Security

Protecting Photo Privacy Via Browsers

Browsers can do more to protect users from inadvertently violating their own privacy. The NY Times today had an article about a topic that has been discussed in various circles several times now. The existence of geotagging data in photos. Many cameras, in particular smart phones like the iPhone can tag photos with GPS data. This is pretty handy for various purposes including organizing photos at a later date, iPhoto for example does a pretty nice job of it. Most photo applications however don’t make this information very visible, as a result many users don’t even know it exists, others simply forget.

What the problem looks like

The data, embedded in a photo looks something like this:

GPSLatitude                    : 57.64911
GPSLongitude                   : 10.40744
GPSPosition                    : 57.64911 10.40744

Which I could map.

Proposal

I propose that browsers need to have a content policy for when users upload images that can better protect them from uploading information they may not even realize. Here’s what I’m imagining:

The first time a user attempts to upload a photo that has EXIF or XMP data containing location they are prompted if they want it stripped from the image they are uploading. The original file remains unharmed, just the uploaded version won’t have the data. They can also choose to have the browser remember their preference to prevent being prompted in the future. They can revise their choice in the preferences window later if they want. This isn’t to different from how popups are handled. I thnk that per-site policy might be too confusing and not warranted, but perhaps I’m wrong.

Warning users about hidden information they may be revealing is a worthwhile effort. It’s only a matter of time before someone uses a “contest” or some other form of social engineering to solicit pictures that may reveal location data for users. Evildoers always find creative ways to exploit people.

Caveat

There are a notable caveat to this approach. The most notable is that flash uploaders would bypass this security measure though individual uploaders could do it themselves, or Adobe could do it, but I don’t think that’s enough of a turnoff to this approach. The same caveat applied to “private browsing” in browsers.

Prior Work

As far as I know no browser actually implements a security feature like this yet. There are a few Firefox Add-ons like Exif Viewer and FxIF (both written in pure JavaScript) that look at EXIF data but nothing that intercepts uploads.

Who Can Do It First?

I’m curious who can do it first. By add-on (seems like it should be possible at least in Firefox), and dare I say include in a browser itself? If this were earlier in the year I would have added this to the Summer of Code ideas list. Instead I’m just throwing it into the wind until 2011 rolls around.

Categories
Apple Mozilla

Firefox Home: Adults Only

Firefox Home iTunes WarningApple posted the Firefox Home application, which complies with Apple’s policies by using WebKit as opposed to Gecko. Regardless, for whatever reason Apple feels that Firefox Home is a NC-17 application.

Presumably the reasoning behind this is that since a web browser can view anything on the internet and 12% of it is porn among other things out there.

If Apple really feels the Firefox Home app is dangerous, why doesn’t it update Safari so that it warns people of the risks before first use? Presumably a fair amount of iPhone users are under 17 and potentially unaware of the risks. Should parents be warned in the store? Safari is a default app and included in every iPhone that ships.

Other web browsers like Opera and Perfect Browser have the same restriction but much less verbose warnings (only “Frequent/Intense Mature/Suggestive Themes”). At least two others, iCab Mobile and Browser has the same warnings as Firefox. Apple isn’t very consistent.

Meanwhile the Twitter app (formerly Tweetie) will let you “follow” porn starts who will provide services if a particular team won the world cup. It also embeds a web browser that will go to links in tweets regardless of content. That app is rated 4+.

This strikes me as inconsistent and unnecessary.

Edit: This is the dialog presented when you try and download it. This must be one hardcore app:

iTunes Firefox Warning Dialog

Categories
Mozilla

Firefox On Bing Again

Back in December a Firefox was featured on Bing. They did another one today:
Firefox On Bing

Categories
Google Mozilla

WebM

In August 2009 after the On2 announcement, I suggested that Google might open source a codec in hopes of derailing OGG which it feels is inferior as well as h.264 which is patent-encumbered. Google took VP8, the successor to the popular VP7 codec and started The WebM Project. To quote the project page:

WebM is an open, royalty-free, media file format designed for the web.

WebM defines the file container structure, video and audio formats. WebM files consist of video streams compressed with the VP8 video codec and audio streams compressed with the Vorbis audio codec. The WebM file structure is based on the Matroska container.

Google describes the license as “BSD-style”. A very good move since it’s liberal enough to encourage widespread open and proprietary inclusion. GPL is to viral for some potential adopters.

Software Support

For the browser side, Chromium and Firefox Nightly builds support WebM starting today. Opera and Google Chrome to come shortly.

Google also created patches against FFmpeg for encode as well as decode and created DirectShow filters which are available for download. I suspect by way of libavcodec we’ll see support in lots of other products in the near future.

Microsoft will support VP8 in Internet Explorer 9 if you have the VP8 codec installed. Not quite “support”, but better than nothing.

Adobe is also supporting VP8 in Flash, which means content producers can eventually kill VP7 and VP6 encoding and use VP8 to reach most of their audience. This is very important as encoding videos into several formats is costly and time consuming (I know this very well).

Hardware Support

Google has already said they are working with video and silicon vendors to add VP8 hardware acceleration to their chipsets. I suspect newer phones in the near future will be supporting it. Especially if they run Android.

Content

Google is supporting WebM in the HTML5 test for YouTube which I mentioned a few months ago. I suspect we’ll see lots more support in the very near future.

Supporters

Even more telling of the potential than the above is the list of supporters which contains some big names who can put a lot of weight behind hardware/software/content support. AMD (who owns ATI), NVIDIA, Marvell (lots of mobile chipsets), Qualcomm (think mobile chipsets), TI, Broadcom, ARM on the hardware side alone is impressive. If the majority of them add hardware support to their upcoming offerings, that will be game changing. On the software side leaves 1.5 holdouts in the web video world: Apple (1) and Microsoft (0.5).

This is a game changer.

Categories
Apple Mozilla

Steve Jobs: Thoughts On Flash

Apple today published a letter from Steve Jobs aptly title “Thoughts on Flash“. What’s interesting isn’t so much what he said, but what he alluded to. This letter is about Flash, but it’s also about the future if the iPhone platform strategy. It also alludes to the future importance of WebKit and the open web. Lets walk through this. From his points:

First, there’s “Open”.

Steve is right. Flash isn’t really “open”. The iPhone isn’t either by any means. In fact it’s the most restricted computing platform in the world as far as I know. What he did note is that the iPhone uses WebKit and by proxy the web is the most open platform on the planet. That’s very noteworthy.

Second, there’s the “full web”.

Flash video itself isn’t that great by todays standards. That’s why sites like YouTube are serving HD video in H.264 rather than VP6. H.264, VP8 and Theora are the future. If all 3 or just one will survive remains to be seen. Regardless any of them can be played outside of Flash. The dependency on Flash to build a player is going away more and more each day.

Regarding games, this is a silly point. Almost all Flash games need a keyboard or mouse to work. They would never work with a touch screen. Nor would they scale to fit the screen. They would need to be significantly reworked/rewritten.

This is yet more alluding to WebKit and HTML5 where there are solutions already in place.

Third, there’s reliability, security and performance.

It’s pretty hard to dispute the reliability of Flash. It’s by far the driving force behind things like out of process plugins (OOPP) in Firefox among other browsers. It’s also been subject to lots of security vulnerabilities.

Fourth, there’s battery life.

The WSJ quotes Adobe’s Shantanu Narayen as saying the claims of Flash being battery draining are “patently false” but if you look at a CPU monitor while browsing a page with Flash, you can see the load increase quite a bit. Blocking flash on your browser does speed things up and keep your system cooler. I’m very suspect that Adobe has solved this in cell phones when they don’t even seem to have it under control in Windows.

Fifth, there’s Touch.

I already mentioned that mouse/keyboard interfaces just don’t work on the iPhone. No need to rehash that.

Sixth, the most important reason.

That’s actually a vague header. The reason is that they don’t want a third-party sitting between the iPhone API’s and developers. If that happens, developers are limited to what that third-party decides to implement. At the very most developers on the Flash platform get whatever is supported on all Flash platform (greatest common denominator).

That leaves Apple in a stupid position. They could implement killer features in the iPhone and create amazing API’s to take advantage of the features. But if Adobe doesn’t see a way to support things across platforms, or just doesn’t see the cost/benefit of implementing that feature, developers can’t use it. That marginalizes the product for Apple as well as developers.

Conclusion

I found this very interesting that he closed it like this:

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

In February of 2007 Steve Jobs wrote another letter on DRM. It’s noteworthy because in January 2009 Apple launched the ability to buy non-DRM protected music. The letter was really a hint at where things were going. He’s repeating the PR strategy that he used then, make no mistake of it.

I have a feeling the day will come where the App Store is deprecated in favor of promoting HTML5 based Applications either directly off the web or packed similar to how Dashboard Widgets are done now on Mac OS X. The App Store will be around for quite some time, but it will eventually morph.

That is why WebKit is so important to Apple. They want to abstract their OS to the point where they can provide very high level hooks into features they want developers to be able to use. The current iPhone App SDK was a solution created by Apple as a way to let developers put applications on the iPhone as an afterthought. The moderation is so that they can keep their security record intact and could shut down a malicious app before trouble becomes rampant. That puts them in the position where they can either approve all content and be viewed as sleazy by more conservative folks, or they can let everything go and accept that reputation. They obviously made their decision. Developers and some geeks hate it, but 99% of the rest of the world doesn’t even know about the process. Nobody wants to know how sausage is made.

The App Store will likely morph to feature Dashboard Widget like applications (not to different from Palm’s WebOS). Apple will still be able to cash in via that distribution point since they can use DRM giving them the only way to actually sell a protected application. You can view them online via you’re browser.

That’s my prediction. The day will come when the iPhone SDK that we know today will be deprecated. WebKit and HTML5 aren’t there today, but the day will come when they will be the tier 1 development platform for the iPhone. Steve Jobs is just laying the groundwork today.

For desktops, other platforms and browsers it’s worth noting that there’s a lot to gain here.

Categories
Apple Mozilla

Mark Pilgrim On iPad Freedoms

Mark Pilgrim has a brilliant blog post on the iPad and the freedoms it’s taking away from tomorrow’s programmers. My favorite part:

Now, I am aware that you will be able to develop your own programs for the iPad, the same way you can develop for the iPhone today. Anyone can develop! All you need is a Mac, XCode, an iPhone “simulator,” and $99 for an auto-expiring developer certificate. The “developer certificate” is really a cryptographic key that (temporarily) allows you (slightly) elevated access to… your own computer. And that’s fine — or at least workable — for the developers of today, because they already know that they’re developers. But the developers of tomorrow don’t know it yet. And without the freedom to tinker, some of them never will.

I’m not sure how we got here, but it does now cost $99 to tinker with your iPhone and soon iPad. While your computer is still pretty open, it’s only a matter of time before the iPad can be used for development via Xcode and a new UI builder. Want to share your creation with someone? You need Apple’s permission (App Store) or you can’t easily do so. Back in my day you took a copy of Stuffit (you can use the 30 day demo) and put it on a server with a web page explaining it to the rest of the world.

However the web is still open. This is exactly why HTML5 and the open web is so important. The web is playing catchup to desktop computing and is accelerating. Browsers like Gecko and WebKit are making it more compelling than ever. The iPad like the iPhone is an awesome way to browse the web. Making the web powerful enough to take advantage of the hardware is the near future of personal computing.

Categories
Mozilla

Apple, Adobe, Flash, and MPEG LA

John Gruber has a great post explaining why Apple has been so adamant about the keeping Flash off of the iPhone and presumably the upcoming tablet device. He’s right that Flash performance is sub par and most people just want video. 99% of the other Flash experiences you see are just ads that suck precious battery life and CPU.

He is also right that third-party plug-ins do cause architectural issues for browser vendors. As of 10/2009 plug-ins accounted for at least 30% of Firefox crashes, a motivating factor for the new plug-in checker.

I will however object to a sentence:

Why? At the core, because Flash is the only de facto web standard based on a proprietary technology. There are numerous proprietary web content plugins — including Apple’s QuickTime — but Flash is the only one that’s so ubiquitous that it’s a de facto standard. Flash is the way video is delivered over the web, and Adobe completely controls Flash. No other aspect of the web works like this. HTML, CSS, and JavaScript are all open standards, with numerous implementations, including several that are open source.

Apple isn’t trying to replace Flash with its own proprietary thing. They’re replacing it with H.264 and HTML5. This is good for everyone but Adobe.

I included an earlier paragraph since I think the context is important. H.264 is not like HTML, CSS, and JavaScript. It’s patent-encumbered much like GIF was. Your trading Adobe for MPEG LA. The difference between H.264 and Flash is browser/OS vendors can control the implementation. It’s still proprietary technology.

I should note that I’m not a fan of Flash either, as a result there’s none on this blog. Even videos I link to are static images for performance and aesthetic reasons.

Categories
Google Mozilla

YouTube HTML5 + Firefox

Google has been a long time supporter of HTML5. They recently launched a HTML5 beta of YouTube however it will only work in Safari and Chrome. The reason for this is not due to the actual markup but the video codec chosen. YouTube is using h.264, the same codec used for YouTube HD via Flash. This works in Safari and Chrome because Safari uses QuickTime to render <video/> and Google licensed h.264 for Chrome. Firefox however doesn’t include the proprietary codec for licensing reasons. It’s not a matter of cost but principle.

IE is supported through “Chrome Frame” which is essentially the Chrome browser in IE’s chrome. Your really just browsing the YouTube site with Chrome. Google could use this as a way to get people away from Flash and IE and onto Chrome one way or another.

I discussed the h.264 debate in more depth a few months ago.

You have to wonder why we don’t want anything proprietary slipping into HTML5, or want proprietary image formats (GIF turned us off to that) but exceptions are made for video.

Edit 1/23/2010: More on the topic:

Edit 5/21/2010: Thoughts on WebM.