[ Slightly reworked version of reply originally sent to wrong list ]

> protecting users against XSS attacks.  The idea is to add a "nocode"
> (or a more descriptive name) attribute to elements that hints the

I think this has the same flaw as the recent Google invention of
an attribute that prevents third party content links being followed
in that it is a command to the browser, rather than description
of the content.  I suspect the same descriptive property would actually
have covered both cases.

I think the choice is between encoding the third partyness, and encoding
the untrustworthyness.  In the latter case, the parameter value could
indicate what features couldn't be trusted, but would probably have to
do it by listing what was trusted so as to fail untrusted.

I don't think role is appropriate here as, if this proposal is to
work at all, the attribute needs to be considered a core attribute
that will be implemented in all user agents, not something that might
only be used to control styling, or specialist tools.

> browser to not execute any client-side code found within that element.
> For example, a content management system or a blog software that
> allows comments on some entry might use the following markup ..

One needs to consider what happens if the attribute is dynamically 
modified by scripting.

> 
> <div id="comment123"  nocode="true">

Historically, this would have been nocode="nocode", which, by SGML
rules, can be collapsed to simply nocode in HTML.  I don't know 
what the current policy is on this.

The problem of pre-filtering will be easier on a true XHTML browser,
which will reject not-well-formed input, but serving as proper XHTML
isn't a good short term option.

PS.  It's a good idea to avoid two word subject that don't obviously
relate to an active topic.  Most of the spam that gets through my
ISP's filters falls into that category these days, i.e. two random
words from the dictionary.  I discarded this unread until I saw the
replies.