HTML5, who is bad enough to take on canvas?

HTML5 Superfriends

I recently went to New York to hang with some people who are interested in HTML5 and figure out what I thought about the future of this web standard. I’m a skeptic by nature, so I went into our little quest expecting to be unimpressed by HTML5, but in fact, it isn’t so bad, and even has a few additions I’m excited about.

Down with Pseudocode!

On the other hand the spec itself drives me crazy because I feel like pseudocode is a poor substitute for properly and clearly stating what you are trying to achieve. It is easy to mask your agenda in pseudocode and harder for people to sort out later what was intentional versus incidental.

#html5 .pseudo-code { display: none;} Thought experiments don’t belong in a spec & pseudocode can’t replace properly specifying requirements.

@stubbornella

Additional Elements

One of the things that pleased me about the spec was what was not in it. While there are a bunch of additional elements that seem unnecessary, they haven’t gone too badly overboard. I suggested a sanity test of the data used to gather these classes because sometimes they got the name correct, but the use-case wrong. I won’t go into it here because it will be on the section titled “footer” in a document we will publish shortly.

Multinode Elements

I think we need a mechanism to define more complex structures than one element allows. I’d like to be able to define the small lego that make up the building blocks of my sites. The existing elements in the HTML 5 specification are more than sufficient, I’d just like to have a mechanism to define combinations of those that repeat throughout the site. It would also be great to be able to define error handling, for example, what happens if the browser finds a module with no body? Or automatically insert presentational junk so it doesn’t clutter dev code or add bytes over the wire.

Performance

It should be possible to do more with less javascript. I’d like to see browser support for common aspects of web pages as well as web applications. Practically every site in the known universe has toggle blocks, tabs, carousels, or accordion menus. I’d like to seen native browser support and CSS styling, so that these element incur no particular performance cost.

Woot! for mashups being compatible with standards

The addition of the section tag means we can mashup content from different sources without worrying about messing up a table of contents or site map generated from the pages of the site. Very cool. I thought section was completely stupid, but it has this cool feature, so now I’m satisfied.

Canvas

Who isn’t excited about canvas? It pushes the boundaries of what we can do in our webapps and websites. Very very cool. On the other hand there is a giant gnarly unsolved technical problem with the canvas element. How do we provide universal access to an element that exists primarily via JavaScript? What would the API look like that insures that anyone can get the data goodies out of canvas and interact with its controls? What do browsers need to implement to make this workable? How can app developers get started today without ruining the accessibility of their work?

Standardistas meet JavaScripters, JavaScripters meet Standardistas. There. Much better. There are a few of us who span both worlds, but remarkably few considering how much our work overlaps. Maybe I should have said Ajaxian meet A List Apart, A List Apart, Ajaxian. You would probably like each other if you got to know one another. Though you don’t speak the same language, you both really care about users. 😉

Bespin raises questions about universal access to the canvas tag
Bespin raises questions about universal access to the canvas tag

We have a really cool technical problem to solve (In my book, really cool == hard, otherwise it would be boring!). If we are going to build bigger and more complicated stuff out of canvas (holy crap Bespin!), and we want to display data via interactive charts and controls, how in the world do we make this stuff universally accessible? How can we make sure search engines can see the data? How do people access it on any device? Without sight? Without a mouse (like cell phones).

We want the stuff we build to be used as widely as possible. So JavaScripters, what do you want from browsers? What could they do now that would make your life far easier? We need to solve this now, before this thing (HTML5) goes into Last Call and we end up with a half-baked solution. We’ve only just gotten started thinking about all the cool stuff we can build with Canvas, but the specification needs suggestions now. Where is the developer bad-ass enough to figure it out? Is there anything we can learn from flash? SVG?


Posted

in

, , , ,

by

Tags:

Comments

11 responses to “HTML5, who is bad enough to take on canvas?”

  1. Audrey Avatar

    I’ve started using the HTML5 canvas and am loving it to death. I think a way to save the current persisting path into a variable, onto a stack, or elsewhere would be really helpful. I could see how that might encourage messes & bad coding practices, though.

  2. James Pearce Avatar

    I am puzzled by your general assertion that ‘Javascript is to standards’ as ‘Ajaxian is to ALA’ as ‘canvas is to markup’ as ‘non-accessible is to accessible’.

    These are mostly orthogonal vectors… I know you can’t be suggesting that all non-canvas code written by ALA readers is perfectly accessible 😉 And highly interactive web sites have had poor accessibility (and mobile suitability) long before canvas came along.

    But in general I agree. My personal concern would not be about readership cliques and one tag per se, but about how to display *any sort* of ‘data via interactive charts and controls’ in a universally accessible way. Or even static charts!

    This is an devilishly intriguing challenge, but on the whole unconnected to HTML5, I would have thought. No?

  3. hackepeter Avatar
    hackepeter

    “A conversation is an ugly way to use a DL, I mean, which speaker is the DT and which is the DD?”

    the DT is the name of the Speaker and the DD is what the speaker says.

    http://www.w3schools.com/tags/html5_dialog.asp

  4. Nicole Avatar
    Nicole

    @hackepeter – Thanks! Let me correct that.

    @James – It was a joke. 😉 I think you might be looking too deeply for meaning. What I did mean is that the standards, accessibility, and JS communities need to talk more. Canvas is in HTML5, with no way to use it accessibly (yet!)

    @Audrey – Can you explain more?

  5. Mark Perkins Avatar

    “Practically every site in the known universe has toggle blocks, tabs, carousels, or accordion menus. I’d like to seen native browser support and CSS styling, so that these element incur no particular performance cost.”

    I’m sorry, but I have to say that I couldn’t disagree with this more strongly about the above statement. I can only think of disadvantages (apart from, speculatively, performance) to having these elements implemented as native browser controls. How would we be able to fine tune their behaviour? What happens if I want a tabbed slider, not just a plain slider? What is the interaction model with these? How do we even get to decide what items (tabs, carosels etc) get included in the ‘native’ controls? What happens when someone invents a new ‘widget’ that becomes popular and widespread – Do we wait for HTML6 to include it?

    In my mind this sort of thing is exactly what javascript is for, and should stay well away from any kind of native browser implementation.

  6. […] Stubbornella » Blog Archive » HTML5, who is bad enough to take on … […]

  7. Nicholas C. Zakas Avatar

    Funny, this post made me go dig up some of my posts on HTML5:
    http://www.nczonline.net/blog/2007/12/06/what-i-d-like-to-see-in-html-5/
    http://www.nczonline.net/blog/2008/02/28/thoughts-on-html-5/

    I think you and I agree on a lot of the points (funny that a lot of those are still relevant now, in 2009, when my first post was in 2007).

    @Mark – JavaScript isn’t for creating UI, it’s for defining UI behavior. The UI should be defined by HTML and scripted by JavaScript. The paradigms Nicole is talking about have pretty clear user experiences, tabs tend to work the same way regardless of who implements them and how. Think of a checkbox control – should I also have to make that from scratch? Common UI elements are already part of HTML, we just need more of them so we don’t need to keep recreating the wheel. And just like the current UI elements, you’d be able to augment its behavior using JavaScript.

  8. Nicole Avatar
    Nicole

    @Nicholas C. Zakas – the standards world moves at a glacial pace, this is both an advantage and an inconvenience. 🙂 Thanks for the links, you made some good points.

  9. […] Nicole Sullivan: »HTML5, who is bad enough to take on canvas?« […]

  10. Peter Kingsbury Avatar

    My first impulse, once introduced to HTML5 Canvas, was tile-based RPGs. Take a look at http://tge.stormwarestudios.com/ and let me know what you think.

  11. Elroy Bridge Avatar

    I would like to thank you for the endeavors you have made in composing this article. I am hoping the same best work from you in the future as well. In fact your fanciful writing abilities has inspired me to start my own blog now. Actually the blogging is spreading its wings rapidly. Your write up is a fine instance of it.