This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I think the noscript element should be deprecated, as it's better practice for developers to design pages that work without JavaScript and progressively enhance them using JavaScript, than assume JavaScript is supported and then provide some fall back content if it isn't. From the examples of noscript content we find on the Web, most contain unhelpful information such as "Your browser does not support JavaScript". It's good that it's mentioned for backwards compatibility, but it doesn't really serve a useful purpose, and developers should be discouraged from using it.
I agree with the sentiment but do not agree with the proposed solution. In section 4.3.2 the spec already states that noscript is a "blunt instrument" and that "it's generally better to avoid using noscript". An example explaining how noscript can be avoided is also included. That is far more important than declaring noscript "deprecated". Declaring a widely used blunt instrument "deprecated" will not really help to change practice. It also would not make sense without defining the meaning of "deprecated" (the term currently is only used once in the spec for presentational markup in HTML4).
(In reply to comment #1) > I agree with the sentiment but do not agree with the proposed solution. > > In section 4.3.2 the spec already states that noscript is a "blunt instrument" > and that "it's generally better to avoid using noscript". An example explaining > how noscript can be avoided is also included. > > That is far more important than declaring noscript "deprecated". Declaring a > widely used blunt instrument "deprecated" will not really help to change > practice. It also would not make sense without defining the meaning of > "deprecated" (the term currently is only used once in the spec for > presentational markup in HTML4). Words such as "blunt instrument" may be colorful, but with a specification, they're useless. When the item is deprecated, there is a specific technical meaning now associated with the item. Among the effects is that when a web page using noscript is checked for conformance, a warning is issued about the use of the item. No warning is given when colorful terms are used to describe the item in the spec, but the item is still left as valid and conforming. Unfortunately, you are correct about "deprecated", since the editor decided this well known concept does not suit HTML5. Therefore, I imagine that Gez would be willing to amend his but so that noscript is made "obsolete but conforming", which is the HTML5 only version of deprecate.
(In reply to comment #2) > (In reply to comment #1) > > I agree with the sentiment but do not agree with the proposed solution. > > > > In section 4.3.2 the spec already states that noscript is a "blunt instrument" > > and that "it's generally better to avoid using noscript". An example explaining > > how noscript can be avoided is also included. > > > > That is far more important than declaring noscript "deprecated". Declaring a > > widely used blunt instrument "deprecated" will not really help to change > > practice. It also would not make sense without defining the meaning of > > "deprecated" (the term currently is only used once in the spec for > > presentational markup in HTML4). > > Words such as "blunt instrument" may be colorful, but with a specification, > they're useless. When the item is deprecated, there is a specific technical > meaning now associated with the item. Among the effects is that when a web page > using noscript is checked for conformance, a warning is issued about the use of > the item. > > No warning is given when colorful terms are used to describe the item in the > spec, but the item is still left as valid and conforming. > > Unfortunately, you are correct about "deprecated", since the editor decided > this well known concept does not suit HTML5. Therefore, I imagine that Gez > would be willing to amend his but so that noscript is made "obsolete but > conforming", which is the HTML5 only version of deprecate. Sorry: Therefore, I imagine that Gez would be willing to amend his _bug_ ...
I just entered bug 10087 to suggest the replacement of "obsolete but conforming" by "deprecated".
(In reply to comment #0) > I think the noscript element should be deprecated, as it's better practice for > developers to design pages that work without JavaScript and progressively > enhance them using JavaScript, than assume JavaScript is supported and then > provide some fall back content if it isn't. > From the examples of noscript content we find on the Web, most contain > unhelpful information such as "Your browser does not support JavaScript". It's > good that it's mentioned for backwards compatibility, but it doesn't really > serve a useful purpose, and developers should be discouraged from using it. I understand this, but progressive enhancement means the default view in the unhelpful examples you have found will probably be "Your browser does not support JavaScript" (which is a useful purpose in a sense that it's better than saying nothing at all). And in true spirit of shoddy design, JavaScript-enabled users may see this message for a split second, before the progressive enhancement takes effect, unlike with noscript, which is invisible from the start for such users. Again this can be avoided, for example if CSS is available, but noscript takes care of this from the outset. In good examples however, we use noscript to replace print buttons and window closing buttons, saying things like "please use the print facility provided by your browser", or "you may now close this window". OK, you might be able to work around noscript, but noscript is the neatest solution for these cases. I'm absolutely aligned with your sentiments incidentally, but I think this proposal is dealing with the tool rather than the craftsman.
(In reply to comment #5) > (In reply to comment #0) > > I think the noscript element should be deprecated, as it's better practice for > > developers to design pages that work without JavaScript and progressively > > enhance them using JavaScript, than assume JavaScript is supported and then > > provide some fall back content if it isn't. > > From the examples of noscript content we find on the Web, most contain > > unhelpful information such as "Your browser does not support JavaScript". It's > > good that it's mentioned for backwards compatibility, but it doesn't really > > serve a useful purpose, and developers should be discouraged from using it. > > I understand this, but progressive enhancement means the default view in the > unhelpful examples you have found will probably be "Your browser does not > support JavaScript" (which is a useful purpose in a sense that it's better than > saying nothing at all). And in true spirit of shoddy design, > JavaScript-enabled users may see this message for a split second, before the > progressive enhancement takes effect, unlike with noscript, which is invisible > from the start for such users. Again this can be avoided, for example if CSS > is available, but noscript takes care of this from the outset. > > In good examples however, we use noscript to replace print buttons and window > closing buttons, saying things like "please use the print facility provided by > your browser", or "you may now close this window". OK, you might be able to > work around noscript, but noscript is the neatest solution for these cases. > > I'm absolutely aligned with your sentiments incidentally, but I think this > proposal is dealing with the tool rather than the craftsman. I have to disagree. I've been working with JavaScript for years, and I've never seen a good reason for noscript. Especially not when progressive enhancement showed us a better way to design a web page. Progressive enhancement means the page looks and works fine without JavaScript. Using noscript to say, "Your browser does not support JavaScript" is actually counter to progressive enhancement. You mentioned about saying something like "you can use the print facility..." That a person can use the browser print facility is a given, whether the page has JS enabled print or not. They don't need to have text providing this info. And if JS is disabled, I doubt we'll have popup windows that need to display a close button. The noscript element is not as bad a design element as blink was--nothing can be--but it's close. I just can't for the life of me think of any good reason for noscript, but I can think of a whole lot of reasons why it needs to go.
Not only is progressive enhancement a much better technique for dealing with cases where scripts are not supported in the client, it also caters for the case where the browser does support scripting, but all scripts are removed by a proxy server. In some secure environments, such as banks, scripts are removed from pages by a proxy server. In this scenario, the browser supports scripting, so the noscript content is not displayed. Not relying on noscript avoids this. I can't think of a good use case for keeping noscript. I didn't realise that deprecated was a term to be avoided, but I'm happy with "Obsolete, but conforming".
I think the objection to "deprecated" is that it implies that support will be removed in a future version. Practically speaking, we can't drop support for any feature once it's widely used on the web, so this is misleading. In the terminology that HTML5 currently uses, you could ask that noscript be non-conforming, or be conforming but raise a validator warning. "Obsolete but conforming" is a subset of the latter, and isn't necessarily what you want (is it really obsolete, or we just think it's a bad idea?).
(In reply to comment #8) > I think the objection to "deprecated" is that it implies that support will be > removed in a future version. Practically speaking, we can't drop support for > any feature once it's widely used on the web, so this is misleading. In the > terminology that HTML5 currently uses, you could ask that noscript be > non-conforming, or be conforming but raise a validator warning. "Obsolete but > conforming" is a subset of the latter, and isn't necessarily what you want (is > it really obsolete, or we just think it's a bad idea?). I believe another bug was opened on the deprecated versus obsolete but conforming terminology. Is there any way you can add your comment to that bug? I'd like to reply to your comment, but I don't want to confuse the purpose of this bug by tangential (but important) discussions on another concern about the HTML5 spec.
(In reply to comment #8) > I think the objection to "deprecated" is that it implies that support will be > removed in a future version. Practically speaking, we can't drop support for > any feature once it's widely used on the web, so this is misleading. In the > terminology that HTML5 currently uses, you could ask that noscript be > non-conforming, or be conforming but raise a validator warning. "Obsolete but > conforming" is a subset of the latter, and isn't necessarily what you want (is > it really obsolete, or we just think it's a bad idea?). Hmm, on closer reading I was wrong to ask about moving your comment. Sorry. I don't agree with the concept of making an element go directly from perfectly valid to obsolete, without an intermediate stage, which is the entire purpose behind the concept of deprecated. The use of deprecated in this regard has been very successful in many programming languages. It is a way of gracefully beginning the move to remove an element. I could agree with Gez wanting to deprecate noscript, with the intention of making it obsolete in the future. I don't think making is abruptly and suddenly obsolete is in the best interest of web developers.
(In reply to comment #6) > Using noscript to say, "Your browser does not support JavaScript" is actually > counter to progressive enhancement. Absolutely, but if an author is not interested in providing non-JavaScript support (suppose it's a game and a client-server non-JS fallback is just not viable), but the author is considerate and thinks it important to offer an explanation to visitors that they require JavaScript in order to play. That is all the fallback is going to say, via noscript, or crude progressive enhancement, nothing is going to change that, there are always going to be some instances where the non-JavaScript fallback is zero functionality. We should be grateful of any fallback at all. > You mentioned about saying something like "you can use the print facility..." > That a person can use the browser print facility is a given, whether the page > has JS enabled print or not. They don't need to have text providing this info. I agree, but I have non-minimalist clients that request "print this page" icons in their pages, they like them, they consider them to be user-friendly. They consider the possibility that their users do not know about pressing CTRL+P or where to find their print operation in their browser's menu. As most browser users these days have no reason to interact with their browser menus, some never do, some are too afraid to, petrified. But they're comfortable picking up their phones and increasing demand on call centres. For some clients, this is a real problem, they don't want to spend time educating users when most users can be given a nice icon that will work. > And if JS is disabled, I doubt we'll have popup windows that need to display a > close button. There's the target attribute, of course, but the close window link I had in mind appears on the logout page of a secure application. Again the browser provides its own close button, but some clients insist they need to instruct their employees to close the window, and the javascript link is added as a user-friendly measure. When JavaScript is not available, there is no link, (because of progressive enhancement) but my client wants instructional text in its place. I'm not going to put the instructional text in an inappropriate place then progressively enhance it away (anywhere outside of a noscript element would be inappropriate, because that content is also available to JavaScript enabled browsers). What a waste of code - I can't think of a reason to use any other technique when noscript fits the bill. > I just can't for the life of me think of any good reason for noscript, but I > can think of a whole lot of reasons why it needs to go. Well I've given two, so don't exhaust yourself! There are many instances when noscript is inappropriate, for sure, but it's not noscript's fault. Saying something should be removed because it can (and normally is) inappropriately used doesn't address the real issue. Poor craftsmanship and design is the issue, I see it often, absolutely there's a lot of abuse, they drive me insane too, but why should the tool get the blame? For making it too easy? I don't like that logic.
(In reply to comment #7) > Not only is progressive enhancement a much better technique for dealing with > cases where scripts are not supported in the client, it also caters for the > case where the browser does support scripting, but all scripts are removed by a > proxy server. This is bad craftsmanship too, such crude proxy servers ought to be handling noscript elements too. It is not the responsibility of the HTML author to anticipate and mitigate this scenario.
(In reply to comment #12) > (In reply to comment #7) > > Not only is progressive enhancement a much better technique for dealing with > > cases where scripts are not supported in the client, it also caters for the > > case where the browser does support scripting, but all scripts are removed by a > > proxy server. > > This is bad craftsmanship too, such crude proxy servers ought to be handling > noscript elements too. It is not the responsibility of the HTML author to > anticipate and mitigate this scenario. Actually it is, if they're worth being paid. HTML web developers have an obligation to ensure their applications respond gracefully in all situations, including no JavaScript support, or even scripts being stripped. That's the whole purpose behind progressive enhancement.
(In reply to comment #12) > (In reply to comment #7) > > Not only is progressive enhancement a much better technique for dealing with > > cases where scripts are not supported in the client, it also caters for the > > case where the browser does support scripting, but all scripts are removed by a > > proxy server. > > This is bad craftsmanship too, such crude proxy servers ought to be handling > noscript elements too. It is not the responsibility of the HTML author to > anticipate and mitigate this scenario. I agree it is a crude method, but it is a method that is used. In these environments, trusted scripts are allowed through the proxy, so not only is the browser capable of scripting, it is used to execute trusted scripts. The content of the noscript element is only rendered when a browser cannot execute scripts, so is not seen in these environments. The scenario can be avoided when authors avoid noscript and use progressive enhancement instead.
(In reply to comment #13) > HTML web developers have an obligation to ensure their applications respond > gracefully in all situations, including no JavaScript support, or even scripts > being stripped. > That's the whole purpose behind progressive enhancement. I agree, but not when they're responsed are being vandalised by a proxy server. Not then.
(In reply to comment #15) > (In reply to comment #13) > > HTML web developers have an obligation to ensure their applications respond > > gracefully in all situations, including no JavaScript support, or even scripts > > being stripped. > > That's the whole purpose behind progressive enhancement. > I agree, but not when they're responsed are being vandalised by a proxy server. > Not then. "their responses"
(In reply to comment #11) > (In reply to comment #6) > > Using noscript to say, "Your browser does not support JavaScript" is actually > > counter to progressive enhancement. > > Absolutely, but if an author is not interested in providing non-JavaScript > support (suppose it's a game and a client-server non-JS fallback is just not > viable), but the author is considerate and thinks it important to offer an > explanation to visitors that they require JavaScript in order to play. That is > all the fallback is going to say, via noscript, or crude progressive > enhancement, nothing is going to change that, there are always going to be some > instances where the non-JavaScript fallback is zero functionality. We should > be grateful of any fallback at all. You don't need JS for this -- if you're creating a game, you're most likely going to be opening the game in a separate page or space anyway. Before you provide the link to the game, you're going to tell people what they need. That's just good commonsense design. > > > You mentioned about saying something like "you can use the print facility..." > > That a person can use the browser print facility is a given, whether the page > > has JS enabled print or not. They don't need to have text providing this info. > > I agree, but I have non-minimalist clients that request "print this page" icons > in their pages, they like them, they consider them to be user-friendly. They > consider the possibility that their users do not know about pressing CTRL+P or > where to find their print operation in their browser's menu. As most browser > users these days have no reason to interact with their browser menus, some > never do, some are too afraid to, petrified. But they're comfortable picking > up their phones and increasing demand on call centres. For some clients, this > is a real problem, they don't want to spend time educating users when most > users can be given a nice icon that will work. > Then they can provide a block of text as default in the page to print the page using the print facility, and overlay the block with JS or enable it with JS if JS is detected. This is the basis of progressive enhancement. > > And if JS is disabled, I doubt we'll have popup windows that need to display a > > close button. > > There's the target attribute, of course, but the close window link I had in > mind appears on the logout page of a secure application. Again the browser > provides its own close button, but some clients insist they need to instruct > their employees to close the window, and the javascript link is added as a > user-friendly measure. When JavaScript is not available, there is no link, > (because of progressive enhancement) but my client wants instructional text in > its place. > See above -- block of text, close the window, hide or overlay with script. In fact, just provide the block of text, period. "Close this window when you're done". > I'm not going to put the instructional text in an inappropriate place then > progressively enhance it away (anywhere outside of a noscript element would be > inappropriate, because that content is also available to JavaScript enabled > browsers). What a waste of code - I can't think of a reason to use any other > technique when noscript fits the bill. > See above. > > I just can't for the life of me think of any good reason for noscript, but I > > can think of a whole lot of reasons why it needs to go. > > Well I've given two, so don't exhaust yourself! There are many instances when > noscript is inappropriate, for sure, but it's not noscript's fault. Saying > something should be removed because it can (and normally is) inappropriately > used doesn't address the real issue. Poor craftsmanship and design is the > issue, I see it often, absolutely there's a lot of abuse, they drive me insane > too, but why should the tool get the blame? For making it too easy? I don't > like that logic. What Gez is saying, and I agree with, is that the use of noscript is inherently bad by default. It encourages bad behavior, it simplifies bad behavior, it is used by developers as a way of routing around good development practices.
(In reply to comment #17) > You don't need JS for this -- if you're creating a game, you're most likely > going to be opening the game in a separate page or space anyway. That's a weird assumption. > Before you > provide the link to the game, you're going to tell people what they need. > That's just good commonsense design. You do understand that the game can be linked to from anywhere on the internet or even bookmarked? You still need the "requires javascript" fallback in the same response. > Then they can provide a block of text as default in the page to print the page > using the print facility, and overlay the block with JS or enable it with JS if > JS is detected. > This is the basis of progressive enhancement. I understand progressive enhancement! What I don't understand is why you assert that noscript is not a valid progressive enhancement technique when falling back to zero-functionality. > What Gez is saying, and I agree with, is that the use of noscript is inherently > bad by default. It encourages bad behavior, it simplifies bad behavior, it is > used by developers as a way of routing around good development practices. If noscript never existed, we wouldn't be any better off. Not providing noscript doesn't imply that bad developers automatically will adopt best practice. Bad developers will just do nothing, which is worse.
(In reply to comment #18) > (In reply to comment #17) > > You don't need JS for this -- if you're creating a game, you're most likely > > going to be opening the game in a separate page or space anyway. > > That's a weird assumption. > > > Before you > > provide the link to the game, you're going to tell people what they need. > > That's just good commonsense design. > > You do understand that the game can be linked to from anywhere on the internet > or even bookmarked? You still need the "requires javascript" fallback in the > same response. And the game page can have a nice block at the top saying what people need to do to play the game (have JavaScript, browsers that support certain functionality, CSS turned on, and so on). That is not unreasonable for a game. > > > Then they can provide a block of text as default in the page to print the page > > using the print facility, and overlay the block with JS or enable it with JS if > > JS is detected. > > This is the basis of progressive enhancement. > > I understand progressive enhancement! What I don't understand is why you > assert that noscript is not a valid progressive enhancement technique when > falling back to zero-functionality. > It isn't. Noscript was a component of graceful degradation. Progressive enhancement is based on the concept of creating the page without recourse to JavaScript and then progressively enhance it to include JavaScript-enabled options. Based on this, noscript makes no sense, because it is a fallback technique. In progressive enhancement, there is no "fallback". If anything, it's a "fall forward" type of concept. Don't have to take my word, look for articles such as the following: http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/ Noscript is a fundamental element of graceful degradation. It is not a component of progressive enhancement. > > What Gez is saying, and I agree with, is that the use of noscript is inherently > > bad by default. It encourages bad behavior, it simplifies bad behavior, it is > > used by developers as a way of routing around good development practices. > > If noscript never existed, we wouldn't be any better off. Not providing > noscript doesn't imply that bad developers automatically will adopt best > practice. Bad developers will just do nothing, which is worse. Actually, I think we would have. People would not have relied on what is nothing more than a lazy programming trick. They would have had to ensure their pages worked regardless of whether scripting was enabled or not. But, scripting was new when noscript was first added. That was over a decade ago -- we've progressed in that time. It is a relic of a bygone, and not missed, era.
(In reply to comment #13) > HTML web developers have an obligation to ensure their applications respond > gracefully in all situations, including no JavaScript support, or even scripts > being stripped. The more such comments on this issue I am reading the more I think that noscript should not be deprecated. Such an "obligation" does not exist. Many customers or clients do not care much (if at all) about situations where JavaScript is not available and will not pay for time spent on preparing for such situations. And they also often do not even care if the HTML-code is valid. None of that will be changed by declaring noscript deprecated.
(In reply to comment #20) > (In reply to comment #13) > > HTML web developers have an obligation to ensure their applications respond > > gracefully in all situations, including no JavaScript support, or even scripts > > being stripped. > > The more such comments on this issue I am reading the more I think that > noscript should not be deprecated. > > Such an "obligation" does not exist. > > Many customers or clients do not care much (if at all) about situations where > JavaScript is not available and will not pay for time spent on preparing for > such situations. And they also often do not even care if the HTML-code is > valid. None of that will be changed by declaring noscript deprecated. Could you provide an example of where noscript is beneficial, couldn't have been achieved using any other technique, and is robust? If people don't care, they don't care; there's not much we can do about that with or without the noscript element. The noscript element was well-intended, but in practice, hasn't worked very well. Keeping it isn't going to make web pages more robust and work when scripting isn't available. Deprecating it (or whatever the HTML5 equivalent is) will at least make those that care look at other techniques to ensure their pages do work when scripting isn't available, which is what we ultimately want to happen. The same cannot be said for keeping noscript, as it encourages people to think in terms of graceful degradation (except not very gracefully). If you have use-cases for noscript that are robust and couldn't be achieved by any other method, then I might understand your argument to keep it. I've yet to read a convincing argument for retaining it.
(In reply to comment #14) > I agree it is a crude method, but it is a method that is used. In these > environments, trusted scripts are allowed through the proxy, so not only is the > browser capable of scripting, it is used to execute trusted scripts. The > content of the noscript element is only rendered when a browser cannot execute > scripts, so is not seen in these environments. The scenario can be avoided when > authors avoid noscript and use progressive enhancement instead. Because a scenario can be avoided, doesn't mean the HTML author is obliged to. If perfect progressive enhancement was commonplace, there'd be no need for such proxies to trust any scripts, because the scripts would not be necessary. The issue in this scenario still isn't noscript, it's poor proxying. The lack of visible fallback content isn't a big enough deal to redesign, after all, the organisations adopting such proxies can still close their browser windows, or print their documents, and probably shouldn't be playing games whilst at work.
(In reply to comment #19) > And the game page can have a nice block at the top saying what people need to > do to play the game (have JavaScript, browsers that support certain > functionality, CSS turned on, and so on). That is not unreasonable for a game. No thanks. It certainly is unreasonable, especially at the top. Most visitors don't know what JavaScript or CSS is let alone how to turn it on. It's much more reasonable to just list supported browsers on a troubleshooting page, and have fallback content for instances where the required technologies are not available. Gaming interfaces strive to be clean with optimal use of space. > Noscript was a component of graceful degradation. Progressive enhancement is > based on the concept of creating the page without recourse to JavaScript and > then progressively enhance it to include JavaScript-enabled options. Based on > this, noscript makes no sense, because it is a fallback technique. In > progressive enhancement, there is no "fallback". If anything, it's a "fall > forward" type of concept. Be careful. The only difference between PE and GD is perspective. PE is considered to be layering an optional technology over the top of another in a non-obtrusive fashion. GD is having a usable experience when such technology is not available. Therefore GD is a benefit of PE. There is no X is a DG component whereas Y is a PE component. I'm not advocating the use of noscript for GD, for GD, use PE. I'm advocating the use of noscript to provide non-functional fallback content, in pretty much the same way as the alt attribute is for images. PE is invalid for fallback content. You can't enhance fallback content, that's not enhancement, that's replacement, why go to all that trouble? I assert that one must enhance something that is functional in order to claim PE, if it doesn't GD, it isn't PE. > Don't have to take my word, look for articles such as the following: > http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/ The relevant noscript example in this argument is an example of bad craftsmanship, a situation where noscript should not be used, not a reason for removing noscript from existence. The irrelevant noscript example is an example of disgraceful degradation (therefore is not discussing GD), where functionality that can be provided without using JavaScript isn't. This is an example of bad craftsmanship. > Noscript is a fundamental element of graceful degradation. If you beleive that, then I understand why you want it removed. The noscript element should not be used for GD, just non-functional fallback content only. > Actually, I think we would have. People would not have relied on what is > nothing more than a lazy programming trick. They would have had to ensure their > pages worked regardless of whether scripting was enabled or not. That doesn't explain the abundance of JavaScript dependant applications that do not use noscript at all.
(In reply to comment #21) > Could you provide an example of where noscript is beneficial, couldn't have > been achieved using any other technique, and is robust? Did you find anything wrong with my two? Beneficial: Users without JavaScript receive guidance about closing windows or printing. Couldn't be achieved using any other technique: This is assuming any other way would be preferable, at any cost. Just because other ways are possible, doesn't mean they're automatically better. I'm not going to write JS to replace fallback content, there's no point. Noscript already provides what I want to acheive. Robust: Poor-proxy-proof? That might be your requirement, but I don't see why one should be bending-over-backwards for poor proxies to be frank. It #1 sets a precedent and #2 is fixing a problem in the wrong place. In the sense that the user can still print or close a window, it's robust, because it's just fallback content, not functionality. > The noscript element was well-intended, but in practice, > hasn't worked very well. The noscript element works very well, too well. It's just not being used very well. This is not the same thing. I don't like it when people use a flathead screwdriver on a cross-drive screw. Confiscating their flat-head screwdrivers isn't the solution, education is, because despite the growing pouplarity of cross-head screws, a flat-head screwdriver is sometimes required. > Keeping it isn't going to make web pages more robust > and work when scripting isn't available. Neither will removing it. You need education for that, I love education, having the examples in the spec of appropriate noscript use, and not for functional graceful degredation would be a good thing. > Deprecating it (or whatever the HTML5 > equivalent is) will at least make those that care look at other techniques to > ensure their pages do work when scripting isn't available, which is what we > ultimately want to happen. I want that too, but sometimes there is no functional fallback. As a user who is still stuck with IE6 at work, I'm afraid this is just not happening, fewer and fewer sites are staying functional over time. Some are actively excluding IE6, yes, they wave the progressive enhancement banner when it suits, but even they have their limits. I suppose it just sucks to be me. > The same cannot be said for keeping noscript, as it > encourages people to think in terms of graceful degradation (except not very > gracefully). It's the encouragement that you should challenge then, isn't it? I don't view noscript in terms of graceful degradation, but absolute degradation, a last resort. Most real-world uses of the alt attribute are abysmal, nobody is suggesting we deprecate the alt attribute. Everybody is advocating providing guidance and enducation. > If you have use-cases for noscript that are robust and couldn't be achieved by > any other method, then I might understand your argument to keep it. Well, if you insist on the "couldn't be achieved by any other method" clause, you're onto a winner there. I personally see no benefit on insisting on such clauses. Especially when the "any other method" might be just a waste of effort because we already have noscript which does what the author wants.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: <noscript> is indeed blunt, but it still serves a valid purpose. What problem does making it obsolete solve?
(In reply to comment #25) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Change Description: no spec change > Rationale: <noscript> is indeed blunt, but it still serves a valid purpose. > What problem does making it obsolete solve? Interesting. One is moved to ask, then, what problem does making longdesc obsolete solve, if that's the question that must be asked for removing existing elements and attributes. Anyway, I had thought I provided reasons for removing the attribute, earlier. However, in case the writing isn't clear enough, I'm not asking to make it obsolete; I'm asking to deprecating the attribute. No valid attribute and element in HTML4 should be immediately shifted to obsolete, without an interim period to allow people time to remove the element/attribute. Deprecating noscript would encourage people to move towards progressive enhancement and not rely on graceful degradation, which was the purpose of noscript. The two examples where noscript could be used, provided earlier, does not account for the fact that all instances of no script being supported actually signal noscript to work. Depending on noscript means, then, that the fallback functionality is not available. This will have to be pushed to an issue, then.
(In reply to comment #25) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Change Description: no spec change > Rationale: <noscript> is indeed blunt, but it still serves a valid purpose. > What problem does making it obsolete solve? What is the valid purpose that noscript provides? Your rationale didn't provide this.
(In reply to comment #25) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Change Description: no spec change > Rationale: <noscript> is indeed blunt, but it still serves a valid purpose. > What problem does making it obsolete solve? Note, this is Gez's bug, and he may not want to pursue this as an issue. If he's not interested in pursuing this as an issue, I am.
(In reply to comment #26) > The two examples where noscript could be used, provided earlier, does > not account for the fact that [not?] all instances of no script being supported > actually signal noscript to work. Depending on noscript means, then, that the > fallback functionality is not available. I was asserting that noscript is useful when there is no fallback functionality. There's no point in using progressive enhancement if there's no functionality to gracefully degrade to.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: <noscript> is used a lot, and used for its purpose. longdesc="" is used rarely, and used badly when used at all. That's the difference between those two. <noscript> is used for all kinds of things, such as showing links that would be made dynamic by script, or showing a warning that script is required, or all kinds of other things. Just look around the Web, it's used a lot.
See http://www.w3.org/html/wg/tracker/issues/117
> See http://www.w3.org/html/wg/tracker/issues/117 Sigh.
(In reply to comment #32) > > See http://www.w3.org/html/wg/tracker/issues/117 > > Sigh. Care to explain your expression of ennui and why you felt it is a necessary piece of information to record in the bugzilla database? I'd like to ensure your response is addressed in any change proposal I write.
> Care to explain your expression of ennui and why you felt it is a necessary > piece of information to record in the bugzilla database? I'd like to ensure > your response is addressed in any change proposal I write. Sure. I'll send an email to the list.
(In reply to comment #34) > > Care to explain your expression of ennui and why you felt it is a necessary > > piece of information to record in the bugzilla database? I'd like to ensure > > your response is addressed in any change proposal I write. > > Sure. I'll send an email to the list. 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.
> 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.
(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.
Woah there cowboy. To pick a random site, I went to Facebook and looked at how they're using <noscript>. They use it twice on the page I happened to look at: <noscript><meta http-equiv=refresh content="0; URL=/home.php?_fb_noscript=1" /></noscript> <noscript><meta http-equiv="X-Frame-Options" content="deny"/></noscript> Both of these uses are quite reasonable and, AFAIK, cannot be achieved any other way.
> You say firewall stripping of script is "BS" Having a firewall or proxy vandalise your content is something for which one just cannot prepare. PE is no guarantee, because you don't know the criteria such firewalls employ, if you have multiple scripts on a page (likely if using API's directly from provider domains) you'll have no idea if all your scripts are available on the client. Although you could super-defensively code around most of it, you'd eventually have to draw a line at catering for the ridiculous. PE is also an unhelpful suggestion for those unprepared to provide a fall-back.
Thanks for the examples. I'm assuming you'll be putting those into a zero-change proposal. Hopefully the co-chairs will call for all change proposals at once. Otherwise, we'll be hear until the middle of next summer.
Sorry, here, not hear.
(In reply to comment #38) There may well be good examples of "noscript" use; I'm not sure about Adam's examples. > <noscript><meta http-equiv=refresh content="0; URL=/home.php?_fb_noscript=1" > /></noscript> Adam, would you mind joining the dots for this one? I can see what this does, but what is it for and how is "noscript" helping here? <noscript><meta http-equiv="X-Frame-Options" content="deny"/></noscript> "X-Frame-Options" is an invalid "http-equiv" value in the current editor's draft: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv But even if it were valid, how does "noscript" help here? Shouldn't "X-Frame-Options" always be sent as a real HTTP header? http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
(In reply to comment #0) > I think the noscript element should be deprecated, as it's better practice for > developers to design pages that work without JavaScript and progressively > enhance them using JavaScript, than assume JavaScript is supported and then > provide some fall back content if it isn't. A common pattern in web analytics is to insert a tracking pixel gathering information only available to JS (such as whether a browser has Flash available) with a "script" element, but fall back to a less informative pixel with "noscript". For example, Google Analytics uses this pattern. Advertisements often use the same pattern, for example putting an image in "noscript" and a rich media ad in "script". This pattern only requires *one* HTTP request for tracking, but I think progressive enhancement would require services to fire a second pixel with additional information. Progressive enhancement might be somewhat more robust, but suffering some inaccuracy or loss of impressions introduced by corporate filters may be preferable to increasing the number of HTTP requests - with associated bandwidth costs to end-users, performance costs to publishers, and processing costs to analytics/advertising services. Can anyone proposing the deprecation of "noscript" suggest how such services could avoid two HTTP requests for tracking? In the absence of an alternative, I don't think I'd support deprecation, but I do think web linters should provide advice about the tradeoffs involved with "noscript".
> There may well be good examples of "noscript" use; I'm not sure about Adam's > examples. I wasn't making a value judgement. Those are real-world examples (from Facebook) of authors using <noscript> to solve problems that they have no other way of solving. Claiming something is obsolete or deprecated without giving authors better tools for solving their problems is waste of time. > > <noscript><meta http-equiv=refresh content="0; URL=/home.php?_fb_noscript=1" > > /></noscript> > > Adam, would you mind joining the dots for this one? I can see what this does, > but what is it for and how is "noscript" helping here? <noscript> limits the meta refresh to only those situations when script is disabled. > <noscript><meta http-equiv="X-Frame-Options" content="deny"/></noscript> > > "X-Frame-Options" is an invalid "http-equiv" value in the current editor's > draft: So? > http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv > > But even if it were valid, how does "noscript" help here? Shouldn't > "X-Frame-Options" always be sent as a real HTTP header? > > http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx That would apply the directive unconditionally. The problem Facebook is solving here is that they have a script-based clickjacking defense that seems to work for them, but they want to be protected even if script is disabled. Consequently, they wish to apply the X-Frame-Options directive only when script is disabled, hence the use of <noscript>. All this talk of "progressive enhancement using JavaScript" ignore the actual problems folks use <noscript> to solve.
(In reply to comment #44) > > > <noscript><meta http-equiv=refresh content="0; URL=/home.php?_fb_noscript=1" > > > /></noscript> > > > > Adam, would you mind joining the dots for this one? I can see what this does, > > but what is it for and how is "noscript" helping here? > > <noscript> limits the meta refresh to only those situations when script is > disabled. Obviously. But what actual problem does this solve? > > http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv > > > > But even if it were valid, how does "noscript" help here? Shouldn't > > "X-Frame-Options" always be sent as a real HTTP header? > > > > http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx > > That would apply the directive unconditionally. The problem Facebook is > solving here is that they have a script-based clickjacking defense that seems > to work for them, but they want to be protected even if script is disabled. > Consequently, they wish to apply the X-Frame-Options directive only when script > is disabled, hence the use of <noscript>. The Microsoft blog post I cited says: "Send the content as an HTTP Header the directive is ignored if specified in a META tag". *If* that's accurate (I haven't tested), then Facebook's directive does not work. (I wouldn't be surprised by error in either direction.) But - assuming for the sake of discussion it *does* work - is the purpose of attempting to limit "X-Frame-Options" to script-less scenarios to enable the content to be iframed when JS *is* enabled? Are they trying to balance integrations options with security concerns or what? Is the loss of robustness acceptable with respect to end-user security, as I've suggested it might be in the case of tracking? > All this talk of "progressive enhancement using JavaScript" ignore the actual > problems folks use <noscript> to solve. I think it's a reaction to the fact that people often use "noscript" to solve problems badly that progressive enhancement solves better. I've tried to explain how the use of "noscript" for tracking purposes might solve that class of problems better (albeit still with a tradeoff), but without context it's hard to know how well your examples solve whatever problems they are trying to solve: a usage example is not the same as a use case.
> I think it's a reaction to the fact that people often use "noscript" to solve > problems badly that progressive enhancement solves better. I've tried to > explain how the use of "noscript" for tracking purposes might solve that class > of problems better (albeit still with a tradeoff), but without context it's > hard to know how well your examples solve whatever problems they are trying to > solve: a usage example is not the same as a use case. I don't want to step on an interesting discussion (and it is interesting), but I wanted to thank you for saying that a usage example is not a use case. Mistaking one (usage) for the other (use case) has actually figured in a lot of decisions lately--and I think this is a very good technical argument that can used when objecting to these decisions.
>> <noscript> limits the meta refresh to only those situations when script is >> disabled. > > Obviously. But what actual problem does this solve? Redirecting folks who don't have JavaScript turned on to a version of the site that works for them. > The Microsoft blog post I cited says: "Send the content as an HTTP Header the > directive is ignored if specified in a META tag". *If* that's accurate (I > haven't tested), then Facebook's directive does not work. (I wouldn't be > surprised by error in either direction.) I think you'll get more accurate results by testing what actually happens then by reading a blog post. > But - assuming for the sake of discussion it *does* work - is the purpose of > attempting to limit "X-Frame-Options" to script-less scenarios to enable the > content to be iframed when JS *is* enabled? They have some other solution for clickjacking when JS is enabled. For whatever reason, they'd rather use that than X-Frame-Options. However, they still want to use X-Frame-Options in the case when there's no script. > Are they trying to balance integrations options with security concerns or what? I don't think you or I should sit in judgement of these decisions. The point is only that <noscript> is a useful, widely used element that does things that no other element can do. Declaring it obsolete when it's not is silly and counter productive. > a usage example is not the same as a use case. Usage, however, is evidence that the feature solves a problem in a useful way. I'm tired of arguing. Bottom line: we shouldn't declare something obsolete that's used by a very large number of important web sites.
(In reply to comment #43) > A common pattern in web analytics is to insert a tracking pixel gathering > information only available to JS (such as whether a browser has Flash > available) with a "script" element, but fall back to a less informative pixel > with "noscript". For example, Google Analytics uses this pattern. Correction, I got confused. Google Conversion Tracking does use this pattern but Analytics just uses a "script" with no fallback.
(In reply to comment #47) > I'm tired of arguing. Bottom line: we shouldn't declare something obsolete > that's used by a very large number of important web sites. By that standard, presentational markup also shouldn't be declared obsolete. Do you agree with that?
(In reply to comment #49) > (In reply to comment #47) > > I'm tired of arguing. Bottom line: we shouldn't declare something obsolete > > that's used by a very large number of important web sites. > > By that standard, presentational markup also shouldn't be declared obsolete. > Do you agree with that? I don't see a <font> tag when I click view-source on Facebook.
(In reply to comment #47) > >> <noscript> limits the meta refresh to only those situations when script is > >> disabled. > > > > Obviously. But what actual problem does this solve? > > Redirecting folks who don't have JavaScript turned on to a version of the site > that works for them. > Neither here nor there in the discussion, but it actually doesn't. I tried it with JS turned off (the Facebook login page uses the two noscript elements), and the redirected page is little different than the original page, and the content isn't displayed. > > The Microsoft blog post I cited says: "Send the content as an HTTP Header the > > directive is ignored if specified in a META tag". *If* that's accurate (I > > haven't tested), then Facebook's directive does not work. (I wouldn't be > > surprised by error in either direction.) > > I think you'll get more accurate results by testing what actually happens then > by reading a blog post. > > > But - assuming for the sake of discussion it *does* work - is the purpose of > > attempting to limit "X-Frame-Options" to script-less scenarios to enable the > > content to be iframed when JS *is* enabled? > > They have some other solution for clickjacking when JS is enabled. For > whatever reason, they'd rather use that than X-Frame-Options. However, they > still want to use X-Frame-Options in the case when there's no script. > Not knowing the Facebook developer's mind, or the purposes, but isn't the whole point of X-Frame-Options to prevent the clickjacking that scripting wasn't preventing? In other words, why integrate X-Frame-Options for non-scripting when it's purpose is for all pages? We don't know, and we can't know just from looking at usage. > > Are they trying to balance integrations options with security concerns or what? > > I don't think you or I should sit in judgement of these decisions. The point > is only that <noscript> is a useful, widely used element that does things that > no other element can do. Declaring it obsolete when it's not is silly and > counter productive. > Circular argument: the usage demonstrates a use case, and the use case is the fact that it's being used. And I am not asking it to be declared obsolete--I'm asking for it to be deprecated. > > a usage example is not the same as a use case. > > Usage, however, is evidence that the feature solves a problem in a useful way. > > I'm tired of arguing. Bottom line: we shouldn't declare something obsolete > that's used by a very large number of important web sites. Important sites make mistakes, the same as other sites. When Google rolled out its use of X-Frame-Options, it actually broke some of its functionality, to the company's embarrassment. And who is to say that Facebook will continue its use of noscript. Five months from now, it may stop using noscript.
(In reply to comment #50) > (In reply to comment #49) > > (In reply to comment #47) > > > I'm tired of arguing. Bottom line: we shouldn't declare something obsolete > > > that's used by a very large number of important web sites. > > > > By that standard, presentational markup also shouldn't be declared obsolete. > > Do you agree with that? > > I don't see a <font> tag when I click view-source on Facebook. Google's home page uses bgcolor="", text="", link="", vlink="", alink="", <u>, width="", <center>, clear="", cellpadding="", cellspacing="", border="", align="", valign="", and yes, <font>. And more.
(In reply to comment #47) > >> <noscript> limits the meta refresh to only those situations when script is > >> disabled. > > > > Obviously. But what actual problem does this solve? > > Redirecting folks who don't have JavaScript turned on to a version of the site > that works for them. So precisely the problem that progressive enhancement solves so much better. > > The Microsoft blog post I cited says: "Send the content as an HTTP Header the > > directive is ignored if specified in a META tag". *If* that's accurate (I > > haven't tested), then Facebook's directive does not work. (I wouldn't be > > surprised by error in either direction.) > > I think you'll get more accurate results by testing what actually happens then > by reading a blog post. Obviously, hence the caveats. Have you tested it? > > But - assuming for the sake of discussion it *does* work - is the purpose of > > attempting to limit "X-Frame-Options" to script-less scenarios to enable the > > content to be iframed when JS *is* enabled? > > They have some other solution for clickjacking when JS is enabled. For > whatever reason, they'd rather use that than X-Frame-Options. However, they > still want to use X-Frame-Options in the case when there's no script. > > > Are they trying to balance integrations options with security concerns or what? > > I don't think you or I should sit in judgement of these decisions. I don't see how you can judge use-cases without making these sorts of judgements. HTML5 could avoid making such judgements except for feature additions by simply treating all existing features as conforming; but it doesn't. > The point is only that <noscript> is a useful, widely used element that does things that > no other element can do. "useful" seems to be what HTML5 requires for a feature to be conforming. I think usefulness can be demonstrated in this case, and have attempted to do so. "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. > > a usage example is not the same as a use case. > > Usage, however, is evidence that the feature solves a problem in a useful way. It's suggestive, sure. :) > Bottom line: we shouldn't declare something obsolete that's used by a very large number of important web sites. Are you saying it should be conforming (as well as specified) even if it's useless or causes active harm? And if you're not saying that, then why do you say this the bottom line? "If browsers don't widely implement a feature, or if authors don't use a feature, or *if the uses of the feature are inconsequential or fundamentally wrong or damaging*, then, after due consideration, features will be removed." (my emphasis) http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F (Not that anyone's proposing to /remove/ "noscript", just to change its conformance status.)
(In reply to comment #52) > Google's home page uses bgcolor="", text="", link="", vlink="", alink="", <u>, > width="", <center>, clear="", cellpadding="", cellspacing="", border="", > align="", valign="", and yes, <font>. And more. Indeed. Facebook's homepage doesn't use "font" but it does use "cellpadding" and "border" on layout tables.
(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.
(In reply to comment #44) > ... > I wasn't making a value judgement. Those are real-world examples (from > Facebook) of authors using <noscript> to solve problems that they have no other > way of solving. Claiming something is obsolete or deprecated without giving > authors better tools for solving their problems is waste of time. > ... Hey. Can we quote you on that in other threads? > ... > > <noscript><meta http-equiv="X-Frame-Options" content="deny"/></noscript> > > > > "X-Frame-Options" is an invalid "http-equiv" value in the current editor's > > draft: > > So? > ... (Advocatus Diaboli) Why does it matter when <noscript> gets deprecated when the whole construct was non-conforming (because of X-Frame-Options) anyway?
> Hey. Can we quote you on that in other threads? Sure. > (Advocatus Diaboli) Why does it matter when <noscript> gets deprecated when the > whole construct was non-conforming (because of X-Frame-Options) anyway? That's exactly the point. Deprecated something that authors find useful without providing an alternative just means authors will ignore these warnings as validator spam. Worse, folks that pay attention to validator warning will be SOL.
(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? 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. Lee, Adam, and I are suggesting that these features/techniques do not exist for some problems. 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. [*] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-April/014396.html
(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
(In reply to comment #59) > There are very distinct differences between deprecating something and making > something immediately obsolete. It says, "suggest making noscript obsolete but conforming", I don't see how those are compatible then. > As such, it's > primitive, and used too frequently to provide annoying messages such as, "You > don't have JavaScript turned on. Go away." This is annoying when the JS functionality can be easily implemented in HTML or on the server, but if this is not viable (e.g. arcade games). Then the only option you have is to tell the user they'll need JavaScript if they'd like to use the feature. If your issue is that the NOSCRIPT element is used too frequently to provide this message, whilst I agree this is probably the case, I don't see how not having NOSCRIPT would improve it. You're treating a technique as a scapegoat. If it was commonplace for sites to provide such annoying messages as a default and use progressive enhancement to enable everything, would such messages suck less? No. Would PE start to get a bad reputation and people advocate that it must not be used? I hope not. Is the overall user experience any better just because PE was used? Of course not. > Deprecating noscript is saying that every instance of its use has an > alternative, better approach. > 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. Just because it is possible to use PE to upgrade away from the annoying message, is no justification for doing so. Let's face it, using PE from a non-functional starting point is just not the spirit of progressive enhancement, because there's nothing progressive about it at all. Insisting that if something is possible to do using PE then it must be, is going to lead to same abuse of PE that NOSCRIPT receives, or lead people to realise that it wasn't NOSCRIPT that was bad after all, it was the web page developers. > 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. I don't understand this logic. Why do we need a proposal to keep something? There are probably alternatives to every use case for toasters or the ball-point pen, people should definitely not use them.
(In reply to comment #60) > (In reply to comment #59) > > There are very distinct differences between deprecating something and making > > something immediately obsolete. > > It says, "suggest making noscript obsolete but conforming", I don't see how > those are compatible then. > Please read my note earlier about why the title says what it says. > > As such, it's > > primitive, and used too frequently to provide annoying messages such as, "You > > don't have JavaScript turned on. Go away." > > This is annoying when the JS functionality can be easily implemented in HTML or > on the server, but if this is not viable (e.g. arcade games). Then the only > option you have is to tell the user they'll need JavaScript if they'd like to > use the feature. > Certainly shouldn't use noscript for this. There should be an intro page that describes the game, the rules, and what you need to have to play. > If your issue is that the NOSCRIPT element is used too frequently to provide > this message, whilst I agree this is probably the case, I don't see how not > having NOSCRIPT would improve it. > > You're treating a technique as a scapegoat. If it was commonplace for sites to > provide such annoying messages as a default and use progressive enhancement to > enable everything, would such messages suck less? No. Would PE start to get a > bad reputation and people advocate that it must not be used? I hope not. Is > the overall user experience any better just because PE was used? Of course > not. > We could say the same about font, or any other presentational attribute, can't we? After all, when we deprecated these items, we were making the techniques into a scapegoat. Weren't we? > > Deprecating noscript is saying that every instance of its use has an > > alternative, better approach. > > 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. > > Just because it is possible to use PE to upgrade away from the annoying > message, is no justification for doing so. Let's face it, using PE from a > non-functional starting point is just not the spirit of progressive > enhancement, because there's nothing progressive about it at all. > No justification for doing so? In other words, we should defend crappy techniques, and sloppy coding? Creating unusable web pages that perform poorly? Progressive enhancement is a starting point. It is a design principle. It is a philosophy, a technique, and an approach to building web pages. You can't get more "starting point" then this. > Insisting that if something is possible to do using PE then it must be, is > going to lead to same abuse of PE that NOSCRIPT receives, or lead people to > realise that it wasn't NOSCRIPT that was bad after all, it was the web page > developers. > Sorry, you really lost me here. > > 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. > > I don't understand this logic. Why do we need a proposal to keep something? > Well, they don't have to provide any. Which means that the change proposal probably is accepted by default. > There are probably alternatives to every use case for toasters or the > ball-point pen, people should definitely not use them. What?
(In reply to comment #61) > > This is annoying when the JS functionality can be easily implemented in HTML or > > on the server, but if this is not viable (e.g. arcade games). Then the only > > option you have is to tell the user they'll need JavaScript if they'd like to > > use the feature. > > > Certainly shouldn't use noscript for this. There should be an intro page that > describes the game, the rules, and what you need to have to play. Right, and on the game page, what if somebody goes straight to that? > > You're treating a technique as a scapegoat. If it was commonplace for sites to > > provide such annoying messages as a default and use progressive enhancement to > > enable everything, would such messages suck less? No. Would PE start to get a > > bad reputation and people advocate that it must not be used? I hope not. Is > > the overall user experience any better just because PE was used? Of course > > not. > > > We could say the same about font, or any other presentational attribute, can't > we? After all, when we deprecated these items, we were making the techniques > into a scapegoat. Weren't we? I haven't seen anybody accusing those techniques for annoying messages. > > Just because it is possible to use PE to upgrade away from the annoying > > message, is no justification for doing so. Let's face it, using PE from a > > non-functional starting point is just not the spirit of progressive > > enhancement, because there's nothing progressive about it at all. > > > No justification for doing so? In other words, we should defend crappy > techniques, and sloppy coding? Creating unusable web pages that perform poorly? Creating something that depends on JavaScript, if appropriate, does not infer that the technique will be crappy, the coding sloppy, the page unusable or the performace poor. Nor does using PE infer that the opposite will be true. > Progressive enhancement is a starting point. It is a design principle. It is a > philosophy, a technique, and an approach to building web pages. You can't get > more "starting point" then this. No, the starting point is the annoying message. It's an annoying message despite the method it arrived at the users screen. > > Insisting that if something is possible to do using PE then it must be, is > > going to lead to same abuse of PE that NOSCRIPT receives, or lead people to > > realise that it wasn't NOSCRIPT that was bad after all, it was the web page > > developers. > > > Sorry, you really lost me here. You were blaming NOSCRIPT for annoying messages... > > > Interestingly enough, the proposal to keep noscript should probably be > > > asked for, first, > > > > I don't understand this logic. Why do we need a proposal to keep something? > > > Well, they don't have to provide any. Which means that the change proposal > probably is accepted by default. I admit I don't really know the process, but can a change proposal can not be challenged directly? A counter-proposal must be raised otherwise the change proposal is automatically accepted? Oh well, it's just a proposal I suppose. > > > because the hypothesis behind its deprecation is that there > > > is an alternative approach for every use case provided. > > There are probably alternatives to every use case for toasters or the > > ball-point pen, people should definitely not use them. > What? Just because there are alternatives to something doesn't make that thing useless. Having alternatives also doesn't automatically mean the alternatives will be better. The existence of alternative approaches isn't in itself a rational argument to deprecate anything. I don't consider having a fallback "you need javascript" message as the default response, then progressively enhancing the functionality over the top of it to be a very elegant use of PE. I'd consider that particular use of PE to be a waste, and frankly, a display of lack of knowledge of what PE is and should be used for. I personally do not consider NOSCRIPT to be an element of graceful degradation (I certainly don't use it as such), but that of fallback content, just like the alt attribute. So I do not argue that we have PE therefore we don't need NOSCRIPT.
(In reply to comment #62) > (In reply to comment #61) > > > This is annoying when the JS functionality can be easily implemented in HTML or > > > on the server, but if this is not viable (e.g. arcade games). Then the only > > > option you have is to tell the user they'll need JavaScript if they'd like to > > > use the feature. > > > > > Certainly shouldn't use noscript for this. There should be an intro page that > > describes the game, the rules, and what you need to have to play. > > Right, and on the game page, what if somebody goes straight to that? It's simple enough to provide fallback content that is removed with JavaScript without the need for a noscript element: Markup: <div id="nojs"> <h2>JavaScript Required</h2> <p>Unfortunately, Javascript is required to use this application. Alternatively, you can use the <a href="...">Flash version of XYZ</a> or <a href="...">some other version</a> of the game we have lovingly prepared for you.</p> </div> JavaScript: var objRemove = document.getElementById('nojs'); objRemove.parentElement.removeChild(objRemove);
(In reply to comment #63) > It's simple enough to provide fallback content that is removed with JavaScript > without the need for a noscript element: > Markup: > <div id="nojs"> > <h2>JavaScript Required</h2> > <p>Unfortunately, Javascript is required to use this application. > Alternatively, you can use the <a href="...">Flash version of XYZ</a> or <a > href="...">some other version</a> of the game we have lovingly prepared for > you.</p> > </div> > JavaScript: > var objRemove = document.getElementById('nojs'); > objRemove.parentElement.removeChild(objRemove); Hmm, or just use NOSCRIPT. I'd say NOSCRIPT was more semantically appropriate personally. I see no issue using NOSCRIPT unless the author is thinking of duplicating functionality within it, *then* use progressive enhancement instead. But that is an issue I have with maintainability, design and best practice, not against the NOSCRIPT element.
(In reply to comment #63) > It's simple enough to provide fallback content that is removed with JavaScript > without the need for a noscript element: > > Markup: > <div id="nojs"> > <h2>JavaScript Required</h2> > <p>Unfortunately, Javascript is required to use this application. > Alternatively, you can use the <a href="...">Flash version of XYZ</a> or <a > href="...">some other version</a> of the game we have lovingly prepared for > you.</p> > </div> > > JavaScript: > var objRemove = document.getElementById('nojs'); > objRemove.parentElement.removeChild(objRemove); Then the content will briefly appear on page load before disappearing. You could solve this by something like <script>document.write("<style>.nojs { display: none }</style>");</script> and then use class="nojs", but <noscript> is easier and more standard, and has no disadvantages that I'm aware of. The major use-case here is something like a game that can have no meaningful graceful degradation -- what's the point in forcing authors to roll their own <noscript> in that case? As your code demonstrates, non-<noscript> ways to do this are likely to be buggy or flawed.
(In reply to comment #65) > (In reply to comment #63) > > It's simple enough to provide fallback content that is removed with JavaScript > > without the need for a noscript element: > > > > Markup: > > <div id="nojs"> > > <h2>JavaScript Required</h2> > > <p>Unfortunately, Javascript is required to use this application. > > Alternatively, you can use the <a href="...">Flash version of XYZ</a> or <a > > href="...">some other version</a> of the game we have lovingly prepared for > > you.</p> > > </div> > > > > JavaScript: > > var objRemove = document.getElementById('nojs'); > > objRemove.parentElement.removeChild(objRemove); > > Then the content will briefly appear on page load before disappearing. You > could solve this by something like > > <script>document.write("<style>.nojs { display: none }</style>");</script> > > and then use class="nojs", but <noscript> is easier and more standard, and has > no disadvantages that I'm aware of. The major use-case here is something like > a game that can have no meaningful graceful degradation -- what's the point in > forcing authors to roll their own <noscript> in that case? As your code > demonstrates, non-<noscript> ways to do this are likely to be buggy or flawed. I turned off JS and tested about 20 or so games. None of them used noscript. If you access the pages with no JS, the games just don't play. So I don't see that the gaming community is going to tear its collective hair out if noscript is deprecated. JavaScript games are an edge case. Even for these edge cases, I provided a solution that is more elegant--you provide a intro page that has rules, requirements, etc and then include a link to the game. If people link directly to the game, so what? Seriously, so what? Oh my god, the web as we know is going to end because people access a javascript game with JS turned off, and it doesn't play? Horrors! Sorry, unbecoming sarcasm. I just don't think we should determine the course of HTML based on edge cases, and JavaScript games ARE edge cases. People use JS all the time to change the appearance of the page after the page is loaded. It is the basis of progressive enhancement, which really is considered the preferable approach to JS development now. And yes, you could be using an old Windows 98 machine that actually shows the change taking place, but you know, I imagine the people using the Windows 98 machine have worst problems. Pages changing after loading? That's all you find on the web today, as twitter boxes, and Google ads, and Digg this, and Reddit that slow up page loadings and flip things around to the point where you can't even access the content until two minutes have passed. I'd think a slight flicker on some older machines just isn't that big a deal. And there's ways to even limit the flicker, and doing so doesn't require uber JS skills. I have to ask: is this conversation going anywhere? I'm not going to speak for Gez (who is more polite than me), but I'm not going to change my mind. The editor has spoken, and an issue created. We could take this to an email list and try to compromise, but this really isn't a compromise situation: either we deprecate noscript, or we don't. There really isn't a lot of give. Should we not just move on to the Decision Process at this point?
(In reply to comment #66) > I turned off JS and tested about 20 or so games. None of them used noscript. Gosh, the first one I looked at did use noscript: http://www.travians.com/, and the third one http://www.rebelideas.co.uk/games/invamars/ is using noscript to redirect to the system requirements (which unfortunately resulted in a 404!), this can't be done using PE. > JavaScript games are an edge case. Games were not the case, they were the example, the case is when an author, for whatever reason, chooses to do anything that is dependant on JS, not just games, without fallback. Some people develop for specific platforms only, in many areas of computing, it's not a crime, we cannot force them provide a non-JS alternative, but if they did want to, I'd insist they use PE. > Even for these edge cases, I provided a > solution that is more elegant--you provide a intro page that has rules, > requirements, etc and then include a link to the game. If people link directly > to the game, so what? So what? It would be confusing, social bookmarking will inevitably bypass this good intention, users will have not a clue what JavaScript is anyway, so they'll just try it all the same, such users just need a little message to assure them the page isn't going to spring to life any time soon, so not to bother waiting. > And yes, you could be > using an old Windows 98 machine that actually shows the change taking place, > but you know, I imagine the people using the Windows 98 machine have worst > problems. The cause is not usually that the client is under-performing, but usually that PE has been implemented imperfectly. E.g. when such scripts are triggered on the body onload event which won't fire until all the page's artefacts have finished downloading, or general domready bottlenecks. There are ways around this, such as inline script immediately after the fallback content, or script in the head to add a class name to the HTML element so it can be hidden in CSS upfront (CSS support permitting) but even that is unnecessary, just use noscript! I'm not really all that bothered about the rearrangement of pages whilst they load, that has become quite usual these days, especially with page contents coming from multiple sources. I'm just not in agreement that we should use PE merely for the sake of it. PE only provides a benefit when the fallback is also functional, allowing the user to carry out their task despite incomplete capabilities. If there is no such benefit, there's no advantage to be gained by using PE. > We could take this to an email list > and try to compromise, but this really isn't a compromise situation: either we > deprecate noscript, or we don't. There really isn't a lot of give. There isn't? My ideal situation would be that the noscript section give guidance as to how to use it appropriately, it already does, but if it explicitly advised that these days it's only really suitable for fallback content and not to duplicate functionality, I think that's reasonable. Although it's not really the job of a specification to describe the process of writing maintainable code.
(In reply to comment #59) > There are very distinct differences between deprecating something and making > something immediately obsolete. But these distinctions reflect general concerns about the HTML obsolescence track itself, rather than making a material difference in the case of "noscript" *in particular*, right? > Deprecating noscript is saying that every instance of its use has an > alternative, better approach. Indeed. > I happen to believe this is true. Gez does also, as he stated when filing the bug. I tried to describe an analytics use case for "noscript" in comment #43: record the maximum information available about a user or user interaction with a single HTTP request (trading the loss of information for a small proportion of users for performance and cost gains). Nobody has given grounds for dismissing that use case, requested specific additional information, suggested any "better approach", or conceded that "noscript" is arguably appropriate for that use case. Would anyone who favours moving "noscript" along the obsolescence track care to comment one way or the other?
(In reply to comment #68) > I tried to describe an analytics use case for "noscript" in comment #43: record > the maximum information available about a user or user interaction with a > single HTTP request (trading the loss of information for a small proportion of > users for performance and cost gains). > > Nobody has given grounds for dismissing that use case, requested specific > additional information, suggested any "better approach", or conceded that > "noscript" is arguably appropriate for that use case. Would anyone who favours > moving "noscript" along the obsolescence track care to comment one way or the > other? I can't think of a way of doing that with a single HTTP request, but I don't think it's unreasonable to always have the tracking image present to track basic information and use the script for more detailed information.
(In reply to comment #68) > (In reply to comment #59) > > There are very distinct differences between deprecating something and making > > something immediately obsolete. > > But these distinctions reflect general concerns about the HTML obsolescence > track itself, rather than making a material difference in the case of > "noscript" *in particular*, right? > > > Deprecating noscript is saying that every instance of its use has an > > alternative, better approach. > > Indeed. > > > I happen to believe this is true. Gez does also, as he stated when filing the bug. > > I tried to describe an analytics use case for "noscript" in comment #43: record > the maximum information available about a user or user interaction with a > single HTTP request (trading the loss of information for a small proportion of > users for performance and cost gains). > > Nobody has given grounds for dismissing that use case, requested specific > additional information, suggested any "better approach", or conceded that > "noscript" is arguably appropriate for that use case. Would anyone who favours > moving "noscript" along the obsolescence track care to comment one way or the > other? You sure about Google Analytics using noscript? I know that Google discourages the use of noscript[1] because it has been so badly abused. I checked out the code for Google Analytics, and I don't see the use of noscript. [1] http://www.google.com/support/forum/p/Webmasters/thread?tid=371b9ed951f93d9d&hl=en
(In reply to comment #70) > You sure about Google Analytics using noscript? I know that Google discourages the use of noscript[1] because it has been so badly abused. I checked out the code for Google Analytics, and I don't see the use of noscript. > > [1] http://www.google.com/support/forum/p/Webmasters/thread?tid=371b9ed951f93d9d&hl=en Google Analytics itself does not use "noscript" (or support JS-stripping or JS-disabled scenarios at all) - see my correction in comment #43. You're citing a suggestion by a Google Employee for a non-analytics use-case, not an official recommendation by Google for all use-cases. Google themselves *do* provide code that uses "noscript", including for analytics use-cases such as conversion tracking: http://adwords.google.com/support/aw/bin/answer.py?hl=en&answer=115794 They also employ "noscript" on the Google Search page, the Gmail inbox, and the very forum page you cited - though not necessarily in ways I would recommend! Also note the rather idiosyncratic use of "noscript" in Web Optimizer: http://www.google.com/support/websiteoptimizer/bin/answer.py?answer=61149#m3 http://www.google.com/support/websiteoptimizer/bin/answer.py?hl=en-au&answer=64418 This blogpost explains how its use in Web Optimizer works, in case anyone's wondering: http://www.gwotricks.com/2009/05/server-side-dynamic-section-variations.html
(In reply to comment #71) > see my correction in comment #43. Sorry comment #48.
(In reply to comment #71) > (In reply to comment #70) > > You sure about Google Analytics using noscript? I know that Google discourages the use of noscript[1] because it has been so badly abused. I checked out the code for Google Analytics, and I don't see the use of noscript. > > > > [1] http://www.google.com/support/forum/p/Webmasters/thread?tid=371b9ed951f93d9d&hl=en > > Google Analytics itself does not use "noscript" (or support JS-stripping or > JS-disabled scenarios at all) - see my correction in comment #43. > > You're citing a suggestion by a Google Employee for a non-analytics use-case, > not an official recommendation by Google for all use-cases. > However, Google has been known to penalize the use of noscript, so I think that this person's opinion is a pretty reliable look at how Google views noscript. > Google themselves *do* provide code that uses "noscript", including for > analytics use-cases such as conversion tracking: > > http://adwords.google.com/support/aw/bin/answer.py?hl=en&answer=115794 > And the use, as Gez pointed out, could be altered so as to not use noscript. And I also believe that one of the NoScript functions it provides is to strip out this type of tracking use, anyway, because it's considered invasive. Being able to track people isn't necessarily a _good_ use of the technology, to my way of thinking. > They also employ "noscript" on the Google Search page, the Gmail inbox, and the > very forum page you cited - though not necessarily in ways I would recommend! > If I remember correctly, Google also uses font and a host of other interesting elements. The point I was making is that Google has penalized the use of noscript in the past, and does look on its use with suspicion. > Also note the rather idiosyncratic use of "noscript" in Web Optimizer: > > http://www.google.com/support/websiteoptimizer/bin/answer.py?answer=61149#m3 > > http://www.google.com/support/websiteoptimizer/bin/answer.py?hl=en-au&answer=64418 > > This blogpost explains how its use in Web Optimizer works, in case anyone's > wondering: > > http://www.gwotricks.com/2009/05/server-side-dynamic-section-variations.html I do note your concerns, and if I write a change proposal, will include references to same. I'm sure if anyone else writes a change proposal, they'll also appreciate your concerns, and your examples. I hope that you might consider writing a proposal to keep the element active.
This isn't the first time the idea of deprecating noscript has come up. There have been several emails on this in the WhatWG email list. Eventually, Ian Hickson answered the lot with the following[1]: "I've left <noscript> conforming in text/html, because while it's true that it isn't overly useful these days, it's not especially _harmful_ either, and we have to support it anyway, so removing it doesn't gain us much. Removing it _would_, however, introduce spurious and annoying conformance error messages in legacy content updated to use HTML5 features." I compare this with recent activity to remove longdesc and table summary--except as people have pointed out, there are unique uses for these two attributes that justify keeping them conforming. Much more viable than being able to add an incorrectly used img tag in order to invade people's privacy and track their movements. Regardless of the use cases, the same logic applies: though they may not be useful to everyone, and yes, used incorrectly in the past, removing them would introduce spurious and annoying conformance error messages in legacy content updated to use HTML5 features. Why are we only concerned about "introducing spurious and annoying conformance error messages" for one object, but not others? No, I feel a change proposal is more than justified. And based on the co-chair decisions about longdesc, would have a reasonable chance for success.
Oops, I always forget the links: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-April/014396.html