W3C home > Mailing lists > Public > www-html@w3.org > December 2005

Re: object + fallback content in form submission

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Sun, 4 Dec 2005 09:31:03 +0200 (EET)
To: www-html@w3.org
Message-ID: <Pine.GSO.4.63.0512040906140.6321@korppi.cs.tut.fi>

On Sun, 4 Dec 2005, Patrick H. Lauke wrote:

> I hope this is the right list for this type of question...

The list exists for discussing the development of HTML.
If you need help with practical problems in HTML authoring,
other fora such as news:comp.infosystems.www.authoring.html
are more appropriate.

> When using an object (for a WYSIWYG plugin) with a fallback
> form control
- -
> should the browser submit both the object value *and*
> the textarea value even when the object was rendered
> succesfully?

You seem to be asking about the interpretation of existing HTML 
specifications. I'm afraid this has little to do with the way
HTML development has taken, especially since the whole <form>
business has been changed.

Anyway, existing specs say that a browser *should not* render
the <object> element's content, if it can render the object.
The XHTML 2.0 draft changes this to *must not*. (Note that in the
existing specs, "should not" has a meaning defined in RFC 2119,
so it means more than what people might intuitively expect, but
it means less that "must not".)

It would be highly unnatural to treat a textarea as successful control if 
it has not been rendered due to its being inside an <object> that has been 
rendered. Theoretically, it might be argued that it can still be a 
successful control in the technical sense: it has a name and an initial 
value (possibly empty), and there is no reason why it should not be 
treated as successful, effectively similar to hidden fields.

Implementations of <object> have traditionally been faulty; the 
implementations that are closest to the specs are those in old browsers 
that do not recognize <object> markup at all. :-) Thus, asking how
browsers should handle <object> by the current specs in a contrived 
situation is rather pointless.

In the XHTML 2.0 draft, the formulation is better, but it still refers to 
"processing" of the object and the <object> element's content, and it 
seems that the meaning of "processing" is still somewhat vague.

> And an additional question, related to the above: what's the
> expected behaviour when a form contains 2 or more form controls
> with the same name attribute (not radio buttons ... something like
> text inputs)?

This one is simple. The fields shall be handled separately and
independently of each other.

> Should the browser send an array of those values
> for that single name?

Browsers are not expected to send any arrays.

Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Sunday, 4 December 2005 07:31:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:12 UTC