Comments on: Your Questions Answered #5

By: Adam Boarman's dot com » Blog Archive » Your Questions Answered #8

Adam Boarman's dot com » Blog Archive » Your Questions Answered #8 — Thu, 24 Jun 2010 08:11:43 +0000

[...] Your Questions Answered #5 [...]

By: Nathan Hammond

Nathan Hammond — Fri, 05 Mar 2010 18:20:09 +0000

@Ian (Original Question)

The basic version of what Mozilla did for creating the video scaling effect can be accomplished by wrapping a video element in a div. The video element would need to be set to 100% of the width and height of the div and then you can scale the div however you see fit.

There are, of course, a lot more considerations than just that, but that should get you started. If you’re interested in recreating this effect you can use Mozilla’s JavaScript as a guideline.

By: Get more traffic with Google’s Image search results | Steve Shaw

Get more traffic with Google’s Image search results | Steve Shaw — Thu, 04 Mar 2010 22:29:29 +0000

[...] Your Questions #5 | HTML5 Doctor [...]

By: Oli Studholme

Oli Studholme — Thu, 04 Mar 2010 13:59:17 +0000

@Florent In those cases adding the text to

(outside ) works for me I should also ask @feather if his advice has changed in the intervening last 5 years…

By: Florent V.

Florent V. — Thu, 04 Mar 2010 13:46:26 +0000

Hi all,
@Mike, I’m not knowledgeable enough to do that kind of study. I may ask some accessibility experts I happen to know if they think there is a need for something like this.
@Oli, your two examples are nice. For placing a conventional typographic sign (*) or a few words, it’s a decent solution to embed that information in the label. But sometimes you have a full sentence used as help text or a validation message, and embedding it in the label would be cumbersome (verbose output in a screen reader, for instance).

By: Oli Studholme

Oli Studholme — Wed, 03 Mar 2010 12:38:48 +0000

@Florent To associate content with a form field, why not add the content to the label and control positioning via CSS? Examples of this are Required Form Fields and Form Error Messages. I also wrap in to increase clickable area (click on the label and the input becomes active). Note that while most browsers won’t need the for="" attribute when you do this, IE6 still does. Regarding @John’s proposal, for me the various

child elements (,

</code> etc) with their associated labels <strong>are</strong> the fields — the input field, the textarea field etc. I also think the form’s content dictates what wrapper element to use. For me it’s almost always a list (<code><ol></code> or <code><ul></code>), and very rarely a <code><table></code> (for a complex multi-column form). For me <code><div></code> is fine but not ideal (as it’s generally a list of questions), and <code><dl></code> seems inappropriate somehow, maybe because initially the <code><input></code>s don’t have any data. The other disadvantage of <code><dl></code> (and <code><table></code>) is you can’t wrap <code><input></code> in <code><label></code>.

Using <code><label></code> for the label and <code><input></code> for the input is the most important bit though. The rest is presentation as much as anything.
</article>
<article>
<h1>By: Leo</h1>
<p>Leo — Tue, 02 Mar 2010 21:12:21 +0000</p>
<p>Thanks again! The question & answer concerning the img-tag was an interesting (reflow!) one.</p>

</article>
<article>
<h1>By: Mike Robinson</h1>
<p>Mike Robinson — Tue, 02 Mar 2010 16:45:42 +0000</p>
<p>@Florent: This is the kind of case study I would be interested in seeing, how beneficial it would be to have those related elements grouped and how it can make a page more accessible. It would definitely be interesting to see what accessibility experts have to say on this subject.</p>
<p>However, I am still concerned about backwards compatibility. We don’t want to fall into a trap of this element being added, and then having unknowledgeable developers thinking that the for attribute is no longer required, excluding it entirely and making the form less accesible in older browsers. The attribute would have to remain for an indefinite amount of time, as we hope that it can be phased out in the future.</p>
<p>Perhaps that is a worthwhile sacrifice? I suppose it depends on the proposed element’s implementation within the browser and how they deal with the combination of the element and a mis-matched for attribute.</p>

</article>
<article>
<h1>By: Juliano Moreira</h1>
<p>Juliano Moreira — Tue, 02 Mar 2010 16:30:12 +0000</p>
<p>Hi! Good article. Did you try validating your site? I tried and got 3 errors. Is it possible to fix them?</p>

</article>
<article>
<h1>By: Florent V.</h1>
<p>Florent V. — Tue, 02 Mar 2010 15:46:28 +0000</p>
<p>Regarding the (for now fictional) FIELD tag, it could be used to specify that some content is relative to the field. That could be help text, error messages, instant validation feedback, etc. Right now this text is place before or after the field, with no semantic way of saying to which field it should be applied. We rely on CSS to put that kind of content close to the field or right of it.</p>
<p>So I think this proposal could help for accessibility needs. I would like to know if accessibility experts think it would be useful or not.</p>

</article>
</main></body></html>