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 <progress> or <meter>, more on <header>, the placeholder attribute, and HTML5 minification.
Getting info from a canvas to the server
Stephen asked:
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,
Remy
Progress or meter?
Pierre asked:
Hello doctor,
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 <input type="range">.
Cheers,
Rich
Headers
Brad asked:
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?
The <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.
Our articles on the <header> element and <hgroup> element explain this some more.
Whether you need to use classes depends on your site.
Ta,
Rich
The placeholder attribute
José asked:
I recall once having seen text inputs that had tips inside them. They didn’t need Javascript in order to manage those tips. Would you consider discussing that a little better? That’d be great! Thanks!
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" ...>We’ve also written a JavaScript solution using feature detection (i.e., it will check whether the browser supports 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
HTML5 Minified
Grant asked:
Hello! Big fan of your website. I wanted to know about the so called “HTML Minified” feature that allows you to strip the
html,headandbodytags 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.
For more detailed articles on HTML5 minification, check out Remy’s HTML5 Boilerplates and Bruce’s A minimal HTML5 document.
Peace,
Oli
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.
Related Posts:
Your Questions Answered #11 originally appeared on HTML5 Doctor on July 30, 2010.
No comments:
Post a Comment