Re: 'px' or'%' given with values for width&heigth attributes gives validation error (html5)

David Dorward wrote:

> In HTML 5, however:
>
> http://www.w3.org/TR/html5/the-map-element.html#dom-dim-width
>
>> The width and height attributes on img, iframe, embed, object,
>> video, and, when their type attribute is in the Image Button state,
>> input elements may be specified to give the dimensions of the visual
>> content of the element (the width and height respectively, relative
>> to the nominal direction of the output medium), in CSS pixels. The
>> attributes, if specified, must have values that are valid
>> non-negative
>> integers.
>
> This removes the percentage option provided by HTML 4 (possibly an
> error on the part of the spec authors, since they tend not to remove
> things from HTML 4)

The HTML5 drafts tend to contain most of HTML4, but parts thereof are 
flagged as obsolete, at two levels, the first one with the requirement that 
they "will trigger warnings in conformance checkers", the second one being 
"entirely obsolete, and must not be used by authors", apparently intended to 
trigger error messages in conformance checkers. This sounds odd, mainly 
because it _is_ odd.

So width="100%" in <iframe> is part of HTML5 as defined in HTML5 drafts but 
must not be used by authors.

Even with pixel values, the width and height attribute in <iframe> are 
suspicious. Though explicitly mentioned in the quoted passage, the draft 
says a little later:
"The two attributes must be omitted if the resource in question does not 
have both an intrinsic width and an intrinsic height."
What might the _intrinsic_ dimensions of an <iframe> element be, in the case 
of embedding an HTML document (as the intent apparently is here - 
src="owstone.html" strongly suggests that). It seems to me that according to 
what HTML5 drafts tell authors to do, those attributes should be removed in 
this case, replacing them with CSS rules. This would of course imply that 
when stylesheets are disabled, the inline frame would appear with some 
browser defaults as its dimensions.

> In short, the validator is right and this is not a bug.

I would reformulate that as follows: The W3C Markup Validation Service, when 
set to the mode where it treats its input as HTML5 and thus applies mixed, 
mostly undocumented checking purported to match some unspecified HTML5 
draft(s), is not contradiction with the current W3C HTML5 draft in this 
issue.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Received on Monday, 7 February 2011 08:30:37 UTC