W3C home > Mailing lists > Public > html-tidy@w3.org > July to September 2000

Re: Tidying the value of an attribute?

From: Dave Raggett <dsr@w3.org>
Date: Tue, 1 Aug 2000 17:34:37 +0100 (GMT Daylight Time)
To: "Rzepa, Henry" <h.rzepa@ic.ac.uk>
cc: html-tidy@w3.org, g.gkoutos@ic.ac.uk
Message-ID: <Pine.WNT.4.10.10008011724350.-766643@hazel.hpl.hp.com>
On Tue, 1 Aug 2000, Rzepa, Henry wrote:

> We have come across a rather peculiar situation, which has
> arisen because of a legacy inheritance from "pre HTML" days.
> An <object>, <embed> or <param> element can have an attribute
> such as eg script="...script commands..."
> These "legacy" script commands it turns out have some
> undesirable features
> a) they often contain semantic line breaks. for example
> # comment where the # starts on a new line and the comment
> ends with a line break
> b) Even worse, the scripts can use the  < or  > operators.
> Might it be possible to have a Tidy flag which would be used to
> suppress processing of the value of an attribute?  For example,
> a particularly long value is currently concatenated onto a
> single line, with line breaks removed. The new flag would
> suppress this.

In principle this could be done, it should be relatively easy to
modify ParseValue() in lexer.c to do this.

Do you have any examples of such legacy scripts, and why these
need to be included in attribute values rather than as the
content of script elements, or in linked scripts?

> Or is it perhaps that XHTML specification mandates that the
> value of an element attribute MUST be specified on a single
> line?  Or possibly that XHTML imposes a character length limit
> on the value of an attribute?

XHTML could specify whitespace handling beyond that specified
by XML 1.0. So far folks have not been in favor of specifying
limits on the length of attribute values.


-- Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
tel/fax: +44 122 578 3011 (or 2521) +44 778 532 0444 (mobile)
World Wide Web Consortium (on assignment from HP Labs)
Received on Tuesday, 1 August 2000 12:34:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:38:48 UTC