[Bug 10068] Suggest making noscript obsolete but conforming

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068





--- Comment #37 from Shelley Powers <shelleyp@burningbird.net>  2010-08-22 16:23:12 ---
(In reply to comment #36)
> > Fine. Note, though, if you want to include me in the discussion, you should
> > send the email to public-html-comments, too. I cannot participate in the HTML
> > WG email list.
> 
> Ok, I'll just write it here.  Issue-117 is ill-informed.  <noscript> is
> both quite popular and quite useful.  It can do things that no other element
> can do, which is why folks use it a lot.  In particular, developers can use
> <noscript> to defend against threats that (as far as I can tell) cannot be
> defended against with other mechanisms.  Finally, this business of firewalls
> striping JavaScript is BS, as far as I can tell.

What threats? You say firewall stripping of script is "BS" and then you provide
a vague assertion that noscript is needed for some nebulous "threat". 

There is no rhyme or reason, or underlying design philosophy about deprecating
or making obsolete previous elements. It seems to come down to whatever a few
select people decide. 

This is poor basis on which to build a specification. Whether an element is
deprecated or made obsolete or not should be based on a quantifiable,
documented criteria -- not opinion and random searches of the Google database. 

This haphazard and sloppy approach has undermined the credibility of the entire
HTML WG effort. It is one of the leading causes of contention within the group,
and one of the leading causes of issues. If there were sound design principles
underlying these decisions, rather than being based on the whim of the editor,
then we wouldn't have these disagreements. On, not the vague design principles
that have been expressed for the group, which are all akin to being agin' sin.
I'm talking about solid, sound design principles agreed to by all communities
impacted by HTML, not just browser companies. 

We don't have sound design principles, though. So we have the bug/issue
process, as bottlenecked as it is. You may disagree with me, but that also
doesn't make a good solid foundation for whether this issue is "ill-informed"
or not. 

Whenever this goes to change proposal, it sounds like you'll be interested in
writing a counter-proposal. Good.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 22 August 2010 16:23:16 UTC