The clinic is busy as ever with more HTML5 ailments. This week, we’ll show you how (and whether) to store a
<canvas> on the server, whether to use
<meter>, more on
placeholder attribute, and HTML5 minification.
Getting info from a canvas to the server
I want to use a canvas element as a layout plan and allow people to move things about and the like but I then want to be able to submit the changed layout to the server so it can be kept not just as a bitmap but as the various current layout of the plan. Is this possible?
You could call
canvas.toDataURL() and store this output on the server. (Note that
canvas is the DOM node and not the 2D context.) This will store the current state of your canvas, but it’s effectively a bitmap at this point. If you want to store the element for later editing, I’d suggest you use SVG instead. You can achieve the same graphical effect, but you’ll have access to the actual vector data since it’s XML.
Hope that helps,
Progress or meter?
I’m beginning with HTML5. I just wonder if I’m using the progress and meter elements correctly. Just imagine a player. Is it correct to use: the progress element to specify a load bar; the meter element to specify the volume set.
Thank you Doctor, have a good day. :-)
<progress> is spot on for a loading bar, yes.
<meter> is read only, however, so it’s not appropriate for a volume control. There are some examples in Tom’s article on
<meter>. To create a volume control, you could use one of the new input types specified in HTML5, perhaps
Having read you can use the header tag within almost any other element, is it fair to say you no longer “design” the header but simply design the elements in each header? How does that work? Would you use header classes?
In the past you define your header with an image or text etc. You can no longer do that if you use multiple headers?
<header> element should be used if you have any related information within the “header” of that section that needs to be grouped. This means, for example, it isn’t necessary to wrap a lone
<h1> in a
<header> element. Also remember that the header doesn’t have to appear at the top of a section of page.
Whether you need to use classes depends on your site.
We’re publishing an article on forms shortly, so be sure to look out for it.
Meanwhile, you’re looking for the
placeholder attribute. Currently, this is supported only on Webkit browsers, although Mozilla is also working on it. You can use
placeholder like this:
<input placeholder="Search" title="Type your search here" ...>
placeholder and adds support if not). Just add this script to the end of your markup (note that it should be the end since it needs to run once the DOM is ready).
Hope that helps,
Bruce & Remy
Hello! Big fan of your website. I wanted to know about the so called “HTML Minified” feature that allows you to strip the
bodytags from your page.
The W3C Validator Conformance Checker for HTML5 says this is valid, but the Conformance Checker is beta and is supposedly unreliable. I haven’t heard from anywhere else that stripping these tags is a feature.
So is it really a feature? Or just a bug (A BIG one at that) in the experimental validator? I know that it works, but I would like to see any confirmation other than the validator that this is in fact an intended standard before I start using it on my websites. Thanks!
According to the spec, it is now explicitly permitted to omit all kinds of
elements , including the ones you mention. Browsers are able to deduce the document structure based on context (e.g., some elements are only allowed within a
<body> element) and will fix the DOM as they go. In fact, these have always been optional tags in HTML (but not XHTML).
Browsers are so good at this, though, because they’ve had to deal with the pants code out there on the interwebs. Going this route means you’re relying on browser error handling to render your document
(although said error handling has admittedly been standardised in HTML5). I personally see it as a more extreme version of quoting element attributes. Of course you don’t have to, but being strict makes errors much easier to find, helps out parsers that may not be as sophisticated as a full-fledged browser (like text editor syntax highlighting), and makes it easier for beginners and veterans alike to learn and use HTML.
In general, machines understand you better when you’re explicit, so I’d advise against omitting these elements.
Got a question for us?
That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.