The clinic is getting busy with more HTML5 ailments. This week, we’ll cover using sections within a footer,
<canvas> vs. Flash security, why HTML5 elements are treated as inline, using offline with storage, and marking up block quotes.
Footer with sections
Hi, I’ll get to the point right away. I want to use, lets say 3 section elements inside a footer each floating left and inside each of this sections I have some standard information. Is this the right way to go, or should I put my section elements outside the footer and only put copyright text etc. inside the footer?
You could use a
but If you want them to appear in the outline within the footer, then it makes perfect sense to do as you suggest.
<footer> is a sectioning root anyway
<canvas> vs. Flash (security and copyright)
I’m seeing lots of opinions that the
Right now I’m thinking about simple flash games, but I’m sure this is a concern for others wanting to use (free) HTML methods to perform functions now reserved more for flash.
Thanks for any input.
I’m not sure of any security mechanisms that we can use to protect
<canvas> content. It isn’t really any different than an image or any other type of resource. Having said that, decompilers can circumvent some of Flash’s security measures as well, so you may not be much worse off using
If we come across anything, we’ll be sure to let you know.
HTML5 tags inline?
So, I’ve been experimenting with the new HTML5 elements, and one frustration I have is understanding the native display of the new elements, and how it works within the document flow. So far, experimenting with them has shown them to be very unpredictable. At best, they’re kind of behaving like a bastard span. They seem to be behaving like inline elements but that seems like it is wrong. In some cases, setting to display: block gives the expected behavior, but on the footer tag, it’s not interacting with floated elements properly.
So, are these new elements inline or are browsers still just trying to catch up? I tried looking in in the HTML5 working draft spec, but so far I am not understanding the way its written (HTML4’s specs clearly spelled out whether an element was display or inline).
Here’s an article from my personal blog that I wrote a while ago describing why browsers treat HTML5 elements as inline.
Offline + Storage
Dear Doctor, I’m trying to work out if HTML5 will be able to do the job that I want. I have a number of documents (PDF, PPT, etc.) that I want to share with people in my team. These documents may change from time to time. Also, the people may not always be connected online.
Would it be possible to “cache” documents in an offline database in the browser so that when they are not connected they can still view them but when they are, they get the latest versions (which also refresh the cache)?
That way I can do a fairly pretty interface for sorting these documents so that they can easily find them.
Thanks in advance for any help you can provide.
You can, but I would strongly encourage you to think carefully about whether it’s worth it.
You can include these “assets” in the manifest, which will make the files available to the offline applications (note that this isn’t storage, just caching, which is what you’re after).
The problem is that when the visitor first hits the page with the manifest — which contains all the PDFs, PPTs, etc. — it will download all of these files. This is the bit that I’d encourage you to consider carefully. To compound that, I believe there’s a 5MB limit on the cache, so you might run into problems if you’re trying to cache more than that.
I’ve not covered offline cache on HTML5 Doctor yet (though it’s on the list), but I have described the process on my 24ways article.
If there are new versions of the cached files, you need to change the contents of the manifest — e.g., include a version number, which will trigger a download of all the assets again. Not ideal, but that’s the current situation.
Hope that helps a bit, Remy
Correct markup with blockquote
Hi, in HTML 4.0 Strict and XHTML 1.0 Strict, text inside a
blockquoteelement is required to be nested inside another block-level element, e.g.
In HTML5 that requirement seems to have been relaxed, as the following element validates successfully:
<blockquote>This is a blockquote.</blockquote>
The HTML5 spec uses the
pelement in the usage examples, but does not mention whether it is required.
Can you please confirm if this requirement has now been deprecated?
Great question. As I expected, this validates:
<!doctype html> <meta charset=utf-8> <title>blockquote test</title> <blockquote>Tiger tiger burning bright</blockquote>
We double-checked with the WHATWG mailing list and confirmed that
<blockquote> can contain ‘flow’ content (i.e., text, paragraphs, etc.).
To summarise, it would be valid not to further mark up content within a
<blockquote>, but authors are encouraged to use a
<p> (or other more appropriate element).
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.