W3C home > Mailing lists > Public > public-html@w3.org > January 2008

Re: Suggestions for improvement

From: Sam Kuper <sam.kuper@uclmail.net>
Date: Mon, 21 Jan 2008 23:25:14 +0000
Message-ID: <4126b3450801211525x45743fe1ta0e061d8a3a6fcf6@mail.gmail.com>
To: "Howard Cary Morris" <howard_cary_morris@hotmail.com>, public-html@w3.org
On 21/01/2008, Howard Cary Morris <howard_cary_morris@hotmail.com> wrote:
>  Yes, what I wrote is a suggestion. I think this should be done by browser
> implementation, but I would want it standardized so all browsers work the
> same. On my slight improvement, I overlooked an argument. In the
> substitution, to tell the difference between &parm= and &parm2=, the
> semicolon would be needed to resolve any ambiguities. There would also need
> to be a restriction not to use reserve words, i.e., &amp= would not be
> legal.

Most regexp syntaxes have escape symbols and some have reserve
words/characters. The syntax you suggest isn't familiar to me (perhaps
because it's a new idea altogether), but I think it's following the same
basic principles. I'm not a regexp expert, so I don't know whether - were
the HTML5 WG to consider adding your <copy/> element to the HTML 5 draft -
to support your suggested syntax or not. Hopefully someone else will come
into this discussion who is more familiar with these things.

More generally, I'd suggest waiting to see how much interest the <copy/>
element proposal generates. If consensus is against it, you won't, that way,
have spent hours worrying over perfecting a new syntax. If, on the other
hand, the community takes up the basic proposal you've made, then there will
be plenty of time for fleshing out the syntax.

It just feels wrong to me to allow <html>, </html>, <head>, </head>, <body>,
> or </body>. The only thing close I can come up with to a good reason is if
> someone were to insert an end tag maliciously, it could foul up the works.

Not if the UA cascades over end tags (for the elements you mention) found in
the included html.

As for your suggestion "Presumably, the element specification would have to
> explain the allowed elements of the code that is to be included, or would
> have to e.g. somehow cascade over an included <head> element so that it is
> over-ridden by the <head> element of the including document.", I would at
> least like the "html validation programs" to warn of such conflicts. It
> would not be a bad idea to have an utility to expand the code (with
> comments).
> Thanks, Howard

Perhaps this sort of thing could be implemented in the HTML 5 validator.

All best,

Received on Wednesday, 23 January 2008 04:16:28 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:25 UTC