[Bug 10068] Suggest making noscript obsolete but conforming

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





--- Comment #59 from Shelley Powers <shelleyp@burningbird.net>  2010-08-24 12:03:40 ---
(In reply to comment #58)
> (In reply to comment #55)
> > (In reply to comment #53)
> > > 
> > > "widely used" merely means we need to define how user agents should treat it.
> > > 
> > > > Declaring it obsolete when it's not is silly and counter productive.
> > > 
> > > Nobody in this thread would disagree with that, but then Gez's claim is that
> > > "noscript" /is/ obsolete.
> > 
> > Actually, Gez originally wanted to deprecate noscript. But as earlier comments
> > in the thread indicate, the concept of "deprecation" isn't currently supported
> > in HTML5. So Gez changed the title to obsolete but conforming, which is about
> > the closest thing we have to deprecation in HTML5. 
> > 
> > Gez will pop in and say what he wants, but he didn't claim that noscript is
> > obsolete. I suggest reading the original comment to the bug to discern his
> > original intent.
> 
> Well … I'm not quite clear on the practical significance of these distinctions
> at this point?

There are very distinct differences between deprecating something and making
something immediately obsolete.

When you deprecate an element or attribute, you're typically doing so for a
reason, such as a change in underlying direction, or in order to encourage
people to take another approach. You're not just dropping the element or
attribute without providing a sound reason, and an alternative direction.

And since the element or attribute must still be maintained by tools, people
that have used the element or attribute in their web pages can take their time
making this change--they know the element or attribute can become obsolete in
the next version of HTML, but they still have time to change their web pages.
They're warned to make the change, but the warning is useful: it provides the
new direction to take. 

Deprecation is an upgrade path, where immediately making normally compliant and
active elements obsolete is, well, dropping someone off a cliff. All we're
doing differently with "obsolete but conforming" in HTML5, is telling them to
have a nice time on the way down.

> 
> Gez's comments implies there are features or techniques that are replacing/can
> replace "noscript" and solve its class of problems significantly better, thus
> allowing the spec to push it down the obsolescence track. The question of how
> far (deprecated/obsolete-but-conforming/obsolete) we wish to push "noscript"
> down that track is academic if these superior features/techniques do not exist
> - we shouldn't be pushing it down the track at all, if they do not.
>

It is less features and more an overall design approach. Noscript is one of the
few tools available for people using graceful degradation--providing a
"fallback" if scripting or other functionality isn't available. As such, it's
primitive, and used too frequently to provide annoying messages such as, "You
don't have JavaScript turned on. Go away."

Web page developers have been abandoning graceful degradation for years in
favor of progressive enhancement: create a great page without script, and then
add script as enhancement. 

You already know this, I know. The point I'm trying to make is that deprecating
noscript would be one of the first fundamental steps to take to really ensure
that we're following the path of progressive enhancement, not graceful
degradation. That in future web development, we're using what we all know to be
the better, more accessible, more _usable_ approach.

Deprecating noscript is saying that every instance of its use has an
alternative, better approach. I happen to believe this is true. Gez does also,
as he stated when filing the bug.

> Lee, Adam, and I are suggesting that these features/techniques do not exist for
> some problems.
>

I bet, if we knew the underlying reasons -- the use cases, you mentioned
earlier-- for the use of noscript, in each and every case, we could find an
alternative that isn't dependent on noscript. 

We can't do this with usage, because we don't know _why_ individuals made the
choices they did. That's always been the problem with making decisions for
HTML5 based on random Google or the like searches. What we find are instances
of usage, not true use cases. 

> There's another viewpoint that very widely used features shouldn't be put on
> the obsolescence track even if there are better alternatives, but while I think
> this is at least reasonable and seems to have been the original justification
> for "noscript"[*], it's hardly a consistently applied principle, as the case of
> presentational markup suggests.
> 

Most definitely. 

At this point, all we can do is wait for a call for proposals--change and
otherwise--and provide the use cases and other arguments we feel justify our
choices. Interestingly enough, the proposal to keep noscript should probably be
asked for, first, because the hypothesis behind its deprecation is that there
is an alternative approach for every use case provided. The only way to prove
that is to actually see the submitted use cases (not usages).

We could also discuss these in the email lists. If so, I hope that people use
public-html-comments, so that non HTML WG members can participate. 


> [*] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-April/014396.html

-- 
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 Tuesday, 24 August 2010 12:03:43 UTC