If you’ve been here last week, you might have seen the webinar and geolocation Q&A with Remy Sharp. Sadly enough, we had a problem recording the screen so we recorded this replacement screencast yesterday night to give you a quick introduction to the Geolocation API.
Once you are up to speed (or refreshed your memory) why not go and build something for this month’s Developer Derby?
You can see the video on any HTML5 enabled device here (courtesy of vid.ly).
I’m currently attending the Frontend Conference in Zurich, Switzerland and this morning I gave a presentation about mobile possibilities offered through CSS3 and HTML5.
Thursday again, and we in the Mozilla Developer Engagement team are happy to present you with another Mozilla Hacks Weekly!
Update 2011-09-09: Oh noes! We had a double dose of technical difficulties during this webinar. The BigBlueButton server froze and required a couple of reboots to get it working. It worked fine for the remainder of the session. Thanks to those who stuck around, and apologies to everyone for the problem.
On top of that, we had another recording failure. That is, we have a recording, but it has no audio. And as Remy demoed code rather than slides, there are no slides to share. We can post the recording if there’s interest, but it’s sadly lacking Remy’s narration. Double apologies for that.
Please join us on on Friday, September 9th at 16:00 UTC (convert to your local time), for a webinar on the Geolocation API, with Remy Sharp. Remy is well-known in web development circles, and was one of the first folks interviewed for our People of HTML5 series.
Geolocation is the topic for the September Dev Derby. Remy has indicated that this session will be light on slides and heavy on code, so get ready for some meaty stuff! Then whip up an awesome way to use geolocation and submit it to the Dev Derby.
Once again, we’re using BigBlueButton, thanks to Blindside Networks. (The recording issues with last month’s webinar were independent of BBB.)
Add this event to your calendar:
We’d like to get a rough estimate of how many people will be attending. If you happen to use Plancast and you expect to attend the webinar, please join the event on Plancast.
To join the webinar:
MDNHacks.Note: Big Blue Button uses Flash, so make sure you have the latest version installed, especially if you are running Mac OS X Lion.
We are planning to record the webinar and make it available for those who can’t attend to view later.
Another month, another Developer Derby. This month we want you to play with something that is not part of the HTML5 stack and we feel it doesn’t get the love it deserves from developers: the geolocation API. Firefox has supported this API for a long time and you can do some pretty cool things with it.
So, what is the Geolocation API? In essence it allows you to detect where the user of your product is at the moment. The location data is found by different means: GPS location, mobile phone masts or wireless hub location. If you turn off wireless on your laptop and you have no 3G connectivity, the API will not be able to get any data.
Using geolocation is incredibly simple. You ask the browser to tell you what the current location is with a method on the navigator.geolocation object:
navigator.geolocation.getCurrentPosition(
success,
failure,
{ parameters }
); |
Where success is the function that is called when the browser found a location, failure is the function called when there was an error and properties is an object that can contain a few parameters. The parameters are the Boolean enableHighAccuracy, the maximumAge of the location before the browser should ask for a new one and the timeout in milliseconds after which the browser should stop trying to find a location.
Each function (success and failure) get a parameter with which to do your coding magic. The success function will get a location object when everything went well. This location object has the following properties: A timestamp telling you when the reading was done and a coordinates object with the following properties: accuracy, altitude, altitudeAccuracy, heading, latitude, longitude and speed.
Some of these are dependent on having more than one reading as for example heading and speed are calculated from the distance in latitude and longitude from reading to reading.
On Firefox you have an extra object called address which is the result of reverse geocoding the latitude and longitude. Reverse geocoding is normally done with an API but in the case of Firefox we have it baked in. When I currently do a call to getCurrentPosition I get the following result on Firefox:
Timestamp: 1315378919289
Coordinates:
Accuracy: 18000
Altitude: 0
AltitudeAccuracy: 0
Heading: NaN
Latitude: 50.06465
Longitude: 19.94498
Speed: NaN
Address:
City: Kraków
Country: Poland
CountryCode: PL
County: Kraków County
Postal Code: null
Premises: null
Street: Lubicz
Street Number: 1
You can Run this test for yourself and see the code here on JSFiddle:
The failure function gets an error object with a code property. This property can have three values: 1 is a permission denied error, 2 is a position unavailable error and 3 is a timeout.
In addition to the getCurrentPosition method you also have a watchPosition method which keeps firing when a new location was found. The parameters are the same and when you keep reading (for example on a mobile device) then you will get values for the heading and the speed. You can stop watching the position change using the clearWatch method.
Using watchPosition is very cool when you are on the go. Check the Geolocation demo page and turn the watch position on and off with the button on the bottom.
In essence, this is what the map app on your mobile phone does.
Well, what you get is a latitude and longitude of your end user. This can be used with all kind of geo platforms like for example GeoNames to find places of interest around you.
You could also allow people to set markers for their friends on a map, collaboratively paint with them, find photos, tweets or foursquare checkins around you – a lot is possible when you come from lat/lon.
We will also soon run a webinar on geolocation, stay tuned!
Last week I spoke at the Dynabyte meetup in Stockholm and I wanted to share the slides and what I was talking about.
HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.
Today we are featuring Divya Manian, Web Opener at Opera Software.
Most likely you came across Divya because of her involvement in HTML5 readiness and HTML5 Boilerplate. She is available on Twitter as @divya and is very much involved in the CSS standards working group.
As you will see in the interview, Divya is a very pragmatic person when it comes to web standards and has a big passion for educating developers instead of woo-ing them.
You can see the video on any HTML5 enabled device here (courtesy of vid.ly).
1) I feel that right now is a terribly exciting time to be a web developer. Would you agree? What gets you really excited about the new tech we have to play with?
Definitely. These are exciting times for a web developer. You have new tools to work with almost every other week and what your page is capable of doing has expanded significantly from just delivering static content to enabling real-time media streaming and more. We also have very strong developer tools for each browser: Opera’s Dragonfly, Chrome’s Developer Tools, IE Developer tools in addition to the original trail blazer Firebug. So, it is simultaneously easier and harder to develop for the web.
2) Back in the days we very much preached separation of concerns as the right way to build web products. HTML is for structure, CSS for look and feel and JavaScript for behaviour. It seems to me that with new technologies this strict separation is blurring a bit. We can generated content in CSS and animate and transform. Some HTML5 elements do nothing without JavaScript (canvas being the big example). Do you think we need to re-visit our best practices?
Yes, the new features do definitely make you think harder about what you put where, but they do enable a similar separation still, except there are nuances to be aware of when you do the separation.
For example, I would consider animation with JavaScript as a way around the roadblock of not being able to do natively. Browsers are in a better position to control most of the animations that we require (animations for gaming are slightly different ballgame), and doing them natively would get us better performance in the long run.
Personally, for me maintainability and writing something readable and that works well and efficiently is more important than just being driven to compartmentalise your code into HTML/CSS/JS.
And definitely we do need to revisit our best practices every so often because technologies change and our best practices need to change with them, none of them are enshrined in stone and we should keep them relevant to our current set of features/technologies.
3) In your post “This revolution needs new revolutionaries” you point out that a lot of the people who drive the web today are not the known luminaries of web design. Do you see a complacency in our advocacy of web standards?
There are two concerns for me in that post:
1. we are not hearing enough from people who have to deal with creating web applications that work in areas with poor internet connections, censorship, with content in languages that are not popular.
2. There are not enough do-ers who are talking, we are hearing from the same people again and again on similar topics.
I feel strongly about both, but more so about #2 because it impacts every web developer all over the world. There are changes that are occurring that most of them are unaware of, because word does not get out. I think we should do our best to encourage those who do actively seek to create tools, and help fellow web developers or work on interesting challenges for the web to speak and inspire rather than those who are known for their speaking abilities because ultimately we want people to use/work with what is best for the web and not just be informed of what was news 5 years ago.
4) I found lately that collaboration is getting easier and easier. Tools like github, JSBin and JSFiddle allow you to talk about code and get your readers to fix and change things with you. I did that lately with getting bullet proof 90 degrees turned headlines for example. Why do you think not that many take advantage of that opportunity?
I would be hesitant to say not many are taking advantage of these tools. They are, but it is true that not everyone is on the bandwagon yet. Github is certainly the most gentle and social introduction to version control you can get, but a lot of web developers are not programmers and have not seen enough pain and horror to know why version control systems are useful. It also requires knowing about what version control systems are, and how to use the command line (a bit), which might be scary for those who are just used to designing with IDEs or TextMate.
5) CSS seems to be moving in leaps and bounds right now. I for one am very excited about the CSS element property which allows to take screenshots of elements. Are there any lesser known extensions you are fond of and use?
I am not a big fan of vendor prefixes, and would rather see them quickly unprefixed rather than see more of the prefixes populating stylesheets more and more.
That said, I do like a lot of the new properties that we are experimenting with. We have the obscure tab-size which allows you to control the width of the ‘tab’ character in your content. Pretty useful when you are displaying code.
Opera also introduced the @viewport which will let you set the viewport from within your CSS rather than using meta tags (like <meta name=”viewport” content=”width=320″>). I think viewport belongs to CSS rather than markup, so I would love to see it gain adoption.
Some of the less known properties such as box-sizing (unprefixed in Opera, IE 8+, Safari 5.1+, Chrome, prefixed in Firefox) are also invaluable, as they let you control your box model, which is definitely a revolutionary step from the dark days of trying to work with separate box models.
6) When we had a longer chat before this interview we discussed that there seems to be a disconnect between what people show on stage at conferences and what people can use these days in their day-to-day jobs. Do you think we should remedy this? More hands-on stuff for people to use now rather than a “look what is possible” approach?
I think what gets shown on stage is partly entertainment and partly information. I think it is hard to show “real hands-on” stuff without diving deep into it and losing half the audience while doing so. We need a balance for sure.
7) When writing CSS these days I get very annoyed about having to repeat a lot of code with different browser prefixes. Animations are the worst with all keyframes having to be repeated. Do you use any preprocessors like SASS or LESS? What do you think of that approach?
Yes, I was/am an early fan of Sass. I have been using it for 2.5 years (a lot less now as I do not deal with as much CSS as I would like to). I certainly think Sass/LESS would be the way to go forward for any web developer right now. They make CSS a lot more powerful and attempt to bring in programming paradigms that CSS sorely lacks. Attempts are being made by Tab Atkins at Google to bring these in a form of a proposal to the CSS WG, and hopefully we should see some form of support in the browser.
I would definitely recommend doing it on the server side though, doing JIT compiling of such code would be such a disaster for performance.
Especially today with so many vendor-prefixed extensions, not using such preprocessors would only cause more harm than not.
8) You work for Opera, the browser that did implement the most of the HTML5 form elements. Why do you think others are reluctant to do the same? Do you think HTML5 forms are ready for prime time yet?
It is certainly not true that others are reluctant. Chrome is pretty close to Opera in terms of support, and Firefox and IE10 are have various levels of support too. Yes, HTML5 forms need to be used with polyfills as of the moment, but I cannot wait for full support to land on all browsers so we can get beyond validating forms on the server.
9) I get a feeling that there is a general fatigue of semantic matters in the HTML5 world. Showcases have no HTML at all or meaningless elements like DIVs as buttons and so on. Is it just not sexy enough when we can rotate things in 3D and make sounds?
I am tired of semantics, too, really :) I think there is more to HTML5 than discussing when to use a section or a div or an article or an aside. Semantics are good to know about and learn to use, but we have had 15 years of talk about semantics surely we can go beyond that and learn about all the new stuff that occurs in HTML5 that will allow faster/more performant way to provide better experiences for your users.
10) If you have a friend who just wants to start with web development, what would you tell them to do and go to? What is the most efficient way to get people hit the ground running these days?
I would ask them to first hit the Opera Web Curriculum which has now moved to W3C – it is a wiki now so everyone is welcome to contribute to keep it up-to-date and relevant. Then I would highly recommend they refer to explanations and tutorials at the Mozilla Developer Center!
Do you know anyone I should interview for “People of HTML5″? Tell me on Twitter: @codepo8
One of the best new features of HTML5 when it comes to visual effects is the canvas element and its API. On the surface, it doesn’t look like much – just a rectangle in the page you can paint on and wipe. Much like an etch-a-sketch. However, the ability to transform, rotate and scale its coordinate system is very powerful indeed once you master it.
Today I want to quickly show how you can do (well simulate) something rather complex with it, like a calculated drop shadow on an element. To see what I mean with this, check out the following demo which is also available on the Demo Studio:
See animated version on JSFiddle
(This is using JSFiddle to show you the demos, so you can click the different tabs to see the JavaScript and CSS needed for the effects. All of the demos are also available on GitHub.)
As you can see, the shadow becomes more blurred and less pronounced the further away the “sun” is from it. You can use the mouse to see the effect in the following demo:
See mouse enabled demo on JSFiddle
Let’s take a look how that is done. The first step is to have a canvas we can paint on – you do this simply by having a mouse detection script (which we used for years and years) and a canvas with access to its API:
Click the play button of the above example and you see that you can paint on the canvas. However, the issue is that you keep painting on the canvas instead of only having the orb follow the cursor. To do this, we need to wipe the canvas every time the mouse moves. You do this with clearRect()
Running the above example now shows that the orb moves with the mouse. Cool, so this is going to be our “sun”. Now we need to place an object on the canvas to cast a shadow. We could just plot it somewhere, but what we really want is it to be in the middle of the canvas and the shadow to go left and right from that. You can move the origin of the canvas’ coordinate system using translate(). Which means though that our orb is now offset from the mouse:
If you check the “fix mouse position” checkbox you see that this is fixed. As we move the coordinate system to the half of the width of the canvas and half of its height, we also need to substract these values from the mouse x and y position.
Now we can draw a line from the centre of the canvas to the mouse position to see the distance using c.moveTo( 0, 0 );c.lineTo( distx, disty ); where distx and disty are the mouse position values after the shifting:
In order to find out the distance of the shadow, all we need to do is multiply the mouse coordinates with -1 – in this demo shown as a red line:
This gives us a shadow distance from the centre opposite of the mouse position, but we don’t want the full length. Therefore we can apply a factor to the length, in our case 0.6 or 60%:
Now we are ready for some drop shadow action. You can apply shadows to canvas objects using shadowColor and its distance is shadowOffsetX and shadowOffsetY. In our case, this is the end of the red line, the inversed and factored distance from the mouse position to the centre of the canvas:
Now, let’s blur the shadow. Blurring is done using the shadowBlur property and it is a number starting from 0 to the strength of the blur. We now need to find a way to calculate the blur strength from the distance of the mouse to the centre of the canvas. Luckily enough, Pythagoras found out for us years ago how to do it. As the x and y coordinate of the mouse are the catheti of a right-angled triangle, we can calculate the length of the hypothenuse (the distance of the point from the centre of the canvas) using the Square root of the squares of the coordinates or Math.sqrt( ( distx * distx ) + ( disty * disty ) ).
This gives us the distance in pixels, but what the really want is a number much lower. Therefore we can again calculate a factor for the blur strength – here we use an array for the weakest and strongest blur blur = [ 2, 9 ]. As the canvas itself also has a right-angled triangle from the centre to the top edge points we can calculate the longest possible distance from the center using longest = Math.sqrt( ( hw * hw ) + ( hh * hh ) ) where hw is half the width of the canvas and hh half the height. Now all we need to do is to calculate the factor to multiply the distance with as blurfactor = blur[1] / longest. The blur during the drawing of the canvas is the distance of the mouse position multiplied with the factor or currentblur = parseInt( blurfactor * realdistance, 10 );. We disregard blur values below the range we defined earlier and we have our blurred shadow:
In order to make the shadow weaker the further away the mouse is we can use the alpha value of its rgba() colour. The same principle applies as with the blur, we set our edge values as shadowalpha = [ 3, 8 ] and after calculating them from the distance we apply their inverse as the alpha value with c.shadowColor = 'rgba(0,0,0,' + (1 - currentalpha / 10) + ')';. This blurs and weakens the shadow:
You can do a lot more with this, for example we could also scale the sun orb the further out it gets or use a second shape to resize and blur it. You can also go completely overboard.
Found a way to optimise this? Tell us about it!
We shifted gears for July and invited Web developers to have some fun with HTML5 video for Dev Derby.
We had 15 awesome demos submitted and while there was a lot of entertainment and innovation happening, we had to narrow them down to 5 finalists:
Facial Recognition and Analytics with HTML5′s Video Tag
HTML5 Video Voting
HTML5 VJing Tool
jQuery VideoBG
Punch the TV!
There are so many cool things you can do with HTML5 video on the Web, and our winners circle definitely reflects the possibilities. So join us in congratulating our July Dev Derby winners!
1st Place: HTML5 Video Voting by Jordan Humphreys
2nd Place: HTML5 VJing Tool by spite
3rd Place: Facial Recognition and Analytics with HTML5′s Video Tag by dsg (@dsg: Please update your profile with an email address so we can contact you! Thanks.)
Runners-up:
jQuery VideoBG
Punch the TV!
Thanks to everyone that submitted their HTML5 video demos for the July Dev Derby. On to the next race!
Right now, there are only a few days left to submit your History API demo for August. And coming up next we have Geolocation for September and CSS Media Queries for October. So start experimenting and hack on.
HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.
Today we are featuring John Allsopp, author of Developing with Web Standards and organiser of the Webdirections conferences.
As you will see in the video, John is neither mincing his words nor does he hold back in spreading good messages about the web as a whole and independent of technology. He has been around since connecting to the web meant enduring bleeping noises and has spent quite some time building software and online generators to allow people to build for the web.
He has been very outspoken about the lack of semantic improvement in HTML5 and you can count on him to speak up every time somebody claims that native apps on mobiles will always be better than web standards based apps.
You can see the video on any HTML5 enabled device here (courtesy of vid.ly).
1) You’ve been around this internet thing quite a while and seen a lot of things come and go. What makes you believe in HTML5?
Well, interestingly I’m probably known by some people for being the anti-HTML5 guy. I’ve been quite critical in particular of the semantics in HTML5, both about some of the specific decisions made, but more importantly the approach to extending semantics in HTML5.
My particular interest in HTML5 in the broadest sense (so, including CSS3, related extensions to the DOM, geolocation, DAP etc) is seeing the web become an increasingly powerful application platform.
Over the last 20 years or so, we’ve seen the web revolutionise publishing, journalism, and other essentially text based media. This emerging generation of technologies promise to revolutionise much more.
2) What are the things in HTML5 that still need tweaking in your book? Anything that ails you about the current state of the spec?
Well, I still think the ball has been dropped when it comes to increasing the semantic richness and expressibility of the language in any genuinely useful way. And I sadly don’t really see anything happening there.
I also think HTML needs to take a leaf from the CSS book – CSS2, a monolithic specification became increasingly bogged down in minutiae, and the failure to finalise it became a kind of running joke.
With CSS3, we saw the modularisation of the specification, with much more rapid innovation, much more experimentation. In truth, it was the experimental CSS3 features that I think ignited the excitement around what we call HTML5, far more than a new DOCTYPE and things like the header element.
The core of the HTML5 specification is really monolithic, and is suffering much the same way CSS2 did. We’re even seeing the same sort of glib jokes about how it’s going to be finished in 2020, which impacts on whether many developers will adopt something perceived (mistakenly, though somewhat understandably) as unready for commercial use. Some aspects of the initial monolithic HTML5 spec have been modularised, while related technologies like geolocation, which is widely considered to be part of HTML5 have always been their own small, independent activities.
So, if anything, I’d like to se the increasing modularisation of the HTML5 spec.
3) You seem to spend quite some time building code generators at the moment. The CSS gradient generator and the audio embed generator being just two of them. Do people use them a lot? And why the separation between Firefox and Webkit rather than generating both?
Just to clarify, all my new tools (audio, video, and some others in the pipeline), as well as the upgrades to existing ones (linear and radial gradients) are cross browser – they work in all browsers that support the technology they’re focussed on, and create code for all modern browsers (in some cases where they don’t even yet support the particular functionality – for example Opera and radial gradients).
In the past (and some of these are 2-3 years old now), I decided to focus only on those browsers which supported a particular technology. I had separate Firefox and Webkit versions of the gradient tools because they supported quite radically different models of gradients, which made a single interface to producing two separate versions of a gradient confusing, as well as essentially impossible.
It’s important to note that the primary motivation for these tools is to help people learn the concepts and syntax for these various features. I think many CSS3 features in particular are really quite complex, and learning them in the more traditional text oriented way is becoming increasingly difficult. For example, you can generate a radial or linear gradient with my tools for all modern browsers in a few seconds, even if you have no idea about how CSS gradients work. But the two articles I wrote on gradients in total come to nearly 10,000 words, and a couple of dozen or more illustrations.
Do many people use them? – they certainly generate quite a bit of traffic. They’re definitely popular – and I think as importantly, people really appreciate them – even really well known CSS experts let me know they really appreciate having them there, and I know others are using them to actually test browser implementations. So I think they are well worth doing.
The last thing I’ll say on them is I also build them to let *me* learn – I’ve been developing tools for web developers for 15 years, all the way back to the earliest days of CSS, and I find the best way to know a technology (and its and your limitations) is to build a tool to work with it.
4) You are also a conference organiser and run workshops. What are the current hot topics in those related to new, open web technology and are there things you’d like to cover more that are not yet requested?
New CSS3 features definitely get a lot of interest – animations, shiny effects like gradients and so on. And we’re definitely seeing a lot more interest across the board in the app development related technologies – offline webapps, geolocation, JavaScript more broadly. Im a sense I think a lot of more traditional web design is “done”. There are widely accepted and understood markup practices, patterns and techniques. There are page architecture patterns that we increasingly build page and site designs out of. But the area of web application development is really uncharted territory by comparison.
5) A sure-fire way to tick you off and get you to blog seems to be to say that native experiences on devices will always be better than using open web technology. If you look at it straight from an end user perspective, this seems to be the case though – things look smoother in native apps. How can we make standards-based development more interesting for developers when the lure of native apps with a money-making store is that big? How can we break the notion of open tech apps being of lesser quality?
There’s a lot going on with this question, so let me begin by stating my basic case. I call BS on the argument that native apps are intrinsically better looking, have better UX, and so on, simply because they are built with say objective-c (when people say native, they almost invariably mean apps for iOS they *think* are built with cocoa touch).
Your observation that many “native” apps are slicker, etc than web apps is a fair one. I think that it *is* somewhat easier to create a cookie cutter native app for say iOS using CocoaTouch, and the really excellent tools Apple has been working on since the NeXT days. But it’s also important to note that for many categories of applications, for example games, these apps use technologies like Unity3D, so in a sense many of the most successful, most engaging applications people use on say iOS aren’t native. I think it really comes down to the tools – and for developing apps using web technologies, these are far less sophisticated on the whole than those like Apple’s. Which to me presents an opportunity.
As to the lure of big money – it’s again one of those myths that get repeated ad nauseam. In fact it started even before there were any apps in Apple App Store! Now we’ve seen several years of activity, what have wen learned? There are doubtless a small number of big winners – but all indications are that almost no one makes any more selling apps on app stores.
There’s a whole industry in app discovery, so the supposed bon to developers that the App Store was going to provide in allowing the little guys to get their apps discovered by users really isn’t panning out.
As soon as you start looking at any sort of numbers objectively, it’s hard to see business case for building a native iOS app and selling it on Apple’s App Store, compared with simply taking that money to Las Vegas for the weekend. You’re going to waste far less of your life.
Finally, the single best way we can address the challenge web technology based apps have of being perceived of inferior quality is to continue building apps that are of superior quality. There are plenty out there – and often you don’t know it, because they are packaged up as native apps.
6) I am worried about showcases these days. The latest “Chrome experiment” (the collaboration interactive video with OK Go) didn’t even work on my Macbook Air with Chrome and let my fan do the impression of an aircraft taking off (it also, ironically, doesn’t work on my Chromebook). There seems to be a – to me – dangerous move towards experimental web sites expecting certain browsers and even hardware. Are we facing a new “best viewed with IE6 and 1024×786 resolution”?
I understand the concern, but don’t think we’re seeing, or will see a return to those bad old days. The “best viewed in” was seen on many many production sites back in the day. Experiments are just that – something at the bleeding edge, pushing the technology to the edges of its capability. So, I love seeing these experiments. We’ve been involved in some ourselves. We typically kick off our conferences with an opening title sequence (we started this a long time ago, but we’re seeing loads of folks doing it now). In the last year or so, we’ve been commissioning people to create these sequences using web technologies – and we’ve got no trouble with them targeting even a really, really specific setup – after all, it’s being designed for a very specific circumstance.
I honestly don’t think we’ll head back to the best viewed in days. Developers and browser makers have learned the lesson of just how bad that is for everyone.
7) Whilst there is a lot of uptake on cool CSS3 transitions, animations, 3D transformations, WebGL and video it seems to me that the semantics of HTML5 and the forms get a bit forgotten. Even more so, it seems like a scam to tell people that there is a need for sections, articles and time elements when no browser uses them to create an outline or syndicates them. Do you see that changing? How can we make it more real for people? Haven’t we used the “use this and that markup as it is the right thing to do” argument too often?
I tend to think the use of various new HTML5 elements as something of a cargo cult. I don’t really see any practical benefit, and there’s still legacy browser challenges (IE6 and 7) to deal with there. And I doubt there’s ever really going to be particular benefits – there’s ultimately very little additional information we’re providing by saying “this is a section”, “this is navigation”, and so on. If the semantics were richer, there would potentially be much more browser developers, search engine developers and so on could do with the richer markup, but as I’ve mentioned, I think we’ve got what we’ve got.
As for forms, now, there’s a lot more going on here of practical use today, and into the future. We can use new elements like number, email and url, and attributes like required right now (I’m doing it myself), as these fallback nicely in older browsers.
In fact, it’s one of my next big areas of focus after I finish a little project involving animations! HTML5 forms stuff is awesome!
8) Let’s talk accessibility a bit. I get the feeling that right now the accessibility world is falling immensely behind. Whilst HTML5 and jQuery tells people to “write less and achieve more” it seems that ARIA roles are ridiculously verbose and rather tough to add. A lot of the needs of mobile and touch interfaces overlap with the needs of disabilities. However, it seems to me there is not enough interest in the a11y world for new technology as it is not proven. Do you find it hard to connect the two?
I’m very far from an accessibility expert, so there’s probably not a a great deal I can add to this particular area of any real value.
ARIA roles are how I’d actually go about enriching the semantics of HTML5, rather than adding a small number of new elements as is the current state of play.
There’s two aspects to ARIA roles. First is the role attribute, initially introduced in XHTML as a means for adding additional semantic information about an element – the role that element is playing. For example, we have a common markup pattern of a div element, playing the role of the page header. We can mark this up with the role attribute like so <div role=”header”>
role is actually quite separate to ARIA. What ARIA brings to the role attribute is a vocabulary, a number of possible values for role, that we can use to add further semantic information to our pages. But you aren’t restricted to ARIAs vocabulary, and indeed can define your own. ARIAs vocabulary is actually far more extensive than HTML5′s.
I think the markup pattern, of using an attribute with a value to give additional information about an element, is really well known and widely used by developers – who doesn’t use class more or less like this?
So, I don’t see the use of role as a particular challenge for developers to adopt.
Then, role has the advantage that you can style it in every browser from IE7 up, using CSS with no JavaScript as well. For HTML5 elements, we need JavaScript for IE7 as well as IE6.
It has to be noted that he ARIA vocabulary is a generic one for rich internet applications, not specifically designed for apps developed using HTML. And sadly the ARIA vocabulary, and HTML5 semantics don’t map onto each other well.
I guess the biggest challenge for web accessibility into the future is that while making essentially text based and static content accessible is not overly challenging, and is now well understood, making applications, dynamic media, and rich interactive content accessible is a far more significant challenge.
9) To me it is high time we stop doing showcases and demos and instead start documenting what people can do themselves and build real products with open web technologies.
I love the showcases, the demos, the proofs of concept, but I agree, I also think it is time to really draw attention to the real world examples. I guess with my articles and tools, what I’m trying to do is help developers adopt these technologies today. As are many other folk as well.
9) (ctd) Sadly, when it comes to conferences though a lot of the things shown on stage were written as a demo for the talk. Are there any exceptions you found? I remember some @media had a great talk on how Blogger saved money by moving to CSS for layout. We need more hard evidence talks like that. Do you actively try to find real life showcases?
Absolutely – one of our goals is to have people who walk the walk. We actively look for folks who go beyond the opinions, and can speak with experience about projects, showcase successes, talk about the challenges they face, and the solutions to those.
10) What’s the next big challenge? Where would you like the web to go and what are the next things that browser makers should agree on?
Those of us old enough will remember when suddenly everything had an LED then LCD screen – things that were once analog, with mechanical dials and the like, things like microwave ovens, suddenly had displays, for time, temperature settings, and so on.
I think far sooner than we realise, there’ll be high resolution touchscreens everywhere, on almost every device.
Not all these devices will necessarily be connected to the web, but many of them will be. But their UIs will be essentially browser technology.
So, there’s going to be huge opportunity to develop user experiences for all kinds of devices using HTML, CSS, JavaScript and related web technologies.
Another really significant trend we’ve seen faltering steps toward, but which I think will genuinely be a paradigmatic change in technology use is “boot to web”.
Think back 3 or 4 years. The hardware, chip, motherboard, RAM speed of your laptop was a big deal. People really cared. They bragged about this stuff! Apple went through 2 incredibly complex expensive CPU architecture changes over about 12 years because of it. Now virtually no one cares. Hardware doesn’t matter any more. It’s been commodified.
The next layer to be commodified will be the OS. It may seem unimaginable now with iOS so dominant in the mobile, not to mention tablet space, but to me this is a very transitional period. The web will commodify operating systems. ChromeOS is a commercial example of this. Boot to Gecko, something Mozilla IMO should have been working on a long time ago is a more experimental example.
The technologies we currently call HTML5 will be the building blocks of the applications which run on these devices.
The as yet missing piece of this puzzle is the emerging Devices API standard, which exposes hardware and system APIs like the camera, address book, calendar, messaging services (for example SMS) to the browser. We’re already seeing support for aspects of this, such as the camera in Android 3 devices. I’m sure this is a big part of the “Boot to Gecko” project too.
Photo by Sam Whiteman / TEDxNSW
Do you know anyone I should interview for “People of HTML5″? Tell me on Twitter: @codepo8