- From: Sam Kuper <sam.kuper@uclmail.net>
- Date: Mon, 21 Jan 2008 23:25:14 +0000
- To: "Howard Cary Morris" <howard_cary_morris@hotmail.com>, public-html@w3.org
- Message-ID: <4126b3450801211525x45743fe1ta0e061d8a3a6fcf6@mail.gmail.com>
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., &= 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, Sam
Received on Wednesday, 23 January 2008 04:16:28 UTC