So, this week’s stand up meeting is finally concluded. You weren’t really paying attention – blah blah something uploader, the details are in the task, blah blah HTML5. You sit down at your station, pull up the task and – hmm, support for modern browsers, including mobile… need to show previews of certain types of files before uploading… show progress… pause and resume? You seem to remember seeing something like that on one of your favourite developer blogs…
You may have been thinking about the HTML5-based uploader and file reader I shared way back when. However, as reader RLK points out, there wasn’t really a way to pause or resume uploads previously. The logic was there… if you were willing to unwrap DeferXHR from the plugin. Oops. Let’s fix that, and add some functionality while we’re at it.
Or Why We Still Have To Test In Every Browser, Web Standards Notwithstanding
It’s pretty seldom that anyone mentions web pages these days, other than in historical reference to days long gone by (yes, a whole few years ago). Web sites, sure, but not if what is really wanted is to replace something that, not so long ago, would have been some native code for a smartphone (or a little further back still, a desktop computer). Generally speaking, the most common term tripping from client’s lips these days is ‘web applications’ – or webapps, because who has time for spaces and proper spelling, amirite?
Of course, the client in question is almost certainly not interested in a webapp because they’re hoping to take advantage of the unique properties and capabilities of any particular browser (unless they’re looking for a line-of-business intranet application in IE8, in which case, you have both my scorn and my pity). Everyone wants their app to have the potential to reach the widest audience possible – and that means supporting all the mainstream browsers.
Oh, and all of the mainstream mobile devices, and their browsers; and maybe smart TVs, consoles, and I hear they’re coming out with, like, iWatches and stuff, can we target those too? (more…)
TABLE vs DIV grid layout
The above diagram shows two ways to place a grid on an HTML page. The
<TABLE> version on the left is the old school way of managing layout. The web was positively littered with such code before widespread use of CSS (and browser manufacturer adoption of standards), which freed designers from use of tables or framesets for managing layout. The
<DIV> version on the right is a sample of modern accepted practice, specifically in this example, using Bootstrap 3 styling.
You will find no one suggesting using tables for HTML layout (except when it comes to formatting HTML email. It’s ugly out there) today. Many a rant exists on the web exhorting all to separate presentation from structure, yet aren’t the two examples shockingly similar? Can the
<DIV> version be that much better, when it looks like a one-for-one mapping of one element to another?
To answer the questions asked in the image, yes, the HTML on the left is bad layout and the sample on the right is OK. The reasons behind the answers come with an understanding of semantic HTML.
A few weeks ago I got a germ of an idea in my head for a personal web-application that required recording and playing video, something with which I have had very little experience. I have seen how effortless is it to play video with HTML5 so I thought this would be simple. After searching countless sites looking for the HTML5 magic bullet for recording both audio & video, I had pretty much given up.
If you have stumbled upon this article also looking for a way to record audio & video together, you can stop searching now. I can say with fairly strong confidence that such a mechanism does not yet exist (as of the publish date of this article). However, I believe I have a workable solution for the time being.
The full source for the example application is on github.
This just came through the wire — it works great for me here (Chrome 29 on OS X) but I’ve heard of other browsers (or perhaps video hardware) having some issues with it.
Seriously.js is a real-time, node-based video compositor for the web. Inspired by professional software such as After Effects and Nuke, Seriously.js renders high-quality video effects, but allows them to be dynamic and interactive.
The site at seriouslyjs.org plays a music video by OK Go (who I think are now required by law to be involved with any cool new video on the internet stuff) where the green screen background can be replaced live with four different video effects inside the browser: