New Element Suggestion - Inverse of NOSCRIPT

[mskinner]

* What is the problem you are trying to solve?
There is a useful element NOSCRIPT that can display content based upon JavaScript not being enabled (or not being present if using lynx).

There doesn't appear to be an element to display content based upon JavaScript being enabled, and optionally based upon the version of JavaScript that the user agent supports. Some people get around this by using CSS visibility/display when the server serves up a page, and requiring the onload event to set the div to visible/block.

* What is the feature you are suggesting to help solve it?
I'm not sure on a suitable element name, but a workmate joked it should be YESSCRIPT. I'm completely open to suggestions for the element name and attributes...

eg:

Code: Select all

<yesscript minver="1.2"  maxver="*">
<!--Display super duper JavaScript 1.2 panel that does something cool-->
</yesscript>


* What is the processing model for that feature, including error handling?
The NOSCRIPT element would behave the same as it does currently, so lets forget about that.

User agents not supporting JavaScript, or with JavaScript disabled would need to ignore content inside the YESSCRIPT element.

User agents with JavaScript enabled should look for the optional attributes minver/maxver. If minver is 1.2 and maxver is not present (or an asterisk or something), and the user agent has JavaScript 1.5, then the user agent would render the YESSCRIPT content immediately.

I would think YESSCRIPT would contain block level elements.

* Why do you think browsers would implement this feature?
To make it easier (or more pleasant) for users to experience web sites based upon the JavaScript capabilities of said browsers.

For an example, say you loaded http://www.xhtmlized.com without JavaScript enabled, the (JavaScript dependent) pages/days sliders would not be visible - and this is made possible by an element, not by JavaScript (which isn't enabled in this case anyway).

* Why do you think authors would use this feature?
To support accessible sites supporting JavaScript and script-less operation with the same markup, and no dependency on JavaScript to hide/show content based upon the user agent's JavaScript capabilities.

* What evidence is there that this feature is desparately needed?
These days countries like AU, GB and US have DDA/508 laws requiring accessible sites. I develop an ecommerce application, and based upon the accessibility guidelines such as:

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]

we need to ensure that our application is accessible to all regardless of JavaScript being present, and the JavaScript version. Requiring JavaScript to display JavaScript specific controls/panels etc. seems like a workaround - when an element would be more elegant.

I see JavaScript getting more widespread, more governments requiring accessible content and sites paying attention to accessibility. A YESSCRIPT style element would make the lives of developers easier, and hopefully websites more usable to users.

As stated previously, I'm completely open to suggestions on the element name and attribute names. I'm interested in hearing what others think, and if there are any improvements that can be made. If it's a bad idea, or I have completely overlooked something major I'm sure you'll let me know

[zcorpan]

* What is the problem you are trying to solve?
There is a useful element NOSCRIPT that can display content based upon JavaScript not being enabled (or not being present if using lynx).

There doesn't appear to be an element to display content based upon JavaScript being enabled, and optionally based upon the version of JavaScript that the user agent supports. Some people get around this by using CSS visibility/display when the server serves up a page, and requiring the onload event to set the div to visible/block.

It's not clear to me from the above what the problem actually is.

If you want different styling when scripting is enabled or not, you can e.g. use <noscript><link rel=stylesheet></noscript> or <script> document.body.className += " js-enabled" </script> and then prefix the relevant selectors with .js-enabled.

If you want to use different markup when scripting is enabled then you can replace some parts of the DOM with scripting.

* What is the feature you are suggesting to help solve it?
I'm not sure on a suitable element name, but a workmate joked it should be YESSCRIPT. I'm completely open to suggestions for the element name and attributes...

eg:

Code: Select all

<yesscript minver="1.2"  maxver="*">
<!--Display super duper JavaScript 1.2 panel that does something cool-->
</yesscript>


* What is the processing model for that feature, including error handling?
The NOSCRIPT element would behave the same as it does currently, so lets forget about that.

User agents not supporting JavaScript, or with JavaScript disabled would need to ignore content inside the YESSCRIPT element.

How do you make it degrade in existing UAs?

User agents with JavaScript enabled should look for the optional attributes minver/maxver. If minver is 1.2 and maxver is not present (or an asterisk or something), and the user agent has JavaScript 1.5, then the user agent would render the YESSCRIPT content immediately.

I would think YESSCRIPT would contain block level elements.

* Why do you think browsers would implement this feature?
To make it easier (or more pleasant) for users to experience web sites based upon the JavaScript capabilities of said browsers.

I'm not convinced.

For an example, say you loaded http://www.xhtmlized.com without JavaScript enabled, the (JavaScript dependent) pages/days sliders would not be visible - and this is made possible by an element, not by JavaScript (which isn't enabled in this case anyway).

Without JS I still get some information, namely what it costs for 1 page in 7 days, and the sliders indicate that pages and days are variable. To make it more useful without JS you don't hide it altogether, you make a form out of it and let the server calculate the cost for other pages/days combinations (and then override it with client side script, i.e. progressive enhancement). So it's not clear to me that your proposed feature would help in this case at all.

* Why do you think authors would use this feature?
To support accessible sites supporting JavaScript and script-less operation with the same markup, and no dependency on JavaScript to hide/show content based upon the user agent's JavaScript capabilities.

Doesn't your proposed feature require different markup for the scripted and non-scripted cases? In any case, it is already possible to create accessible sites JavaScript and script-less operation with the same markup, by not using <noscript> but instead starting from functional markup involving the server to do scripted stuff and using client side script as an enhancement.

* What evidence is there that this feature is desparately needed?
These days countries like AU, GB and US have DDA/508 laws requiring accessible sites. I develop an ecommerce application, and based upon the accessibility guidelines such as:

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]

we need to ensure that our application is accessible to all regardless of JavaScript being present, and the JavaScript version. Requiring JavaScript to display JavaScript specific controls/panels etc. seems like a workaround - when an element would be more elegant.

I see JavaScript getting more widespread, more governments requiring accessible content and sites paying attention to accessibility. A YESSCRIPT style element would make the lives of developers easier, and hopefully websites more usable to users.

As stated previously, I'm completely open to suggestions on the element name and attribute names. I'm interested in hearing what others think, and if there are any improvements that can be made. If it's a bad idea, or I have completely overlooked something major I'm sure you'll let me know

Accessibility guidelines or laws don't support your proposal because it's already possible to create existing pages without it, as I mentioned above.

[mskinner]

Hi, thanks for your response.

* What is the problem you are trying to solve?
There is a useful element NOSCRIPT that can display content based upon JavaScript not being enabled (or not being present if using lynx).

There doesn't appear to be an element to display content based upon JavaScript being enabled, and optionally based upon the version of JavaScript that the user agent supports. Some people get around this by using CSS visibility/display when the server serves up a page, and requiring the onload event to set the div to visible/block.

It's not clear to me from the above what the problem actually is.

If you want different styling when scripting is enabled or not, you can e.g. use <noscript><link rel=stylesheet></noscript> or <script> document.body.className += " js-enabled" </script> and then prefix the relevant selectors with .js-enabled.

If you want to use different markup when scripting is enabled then you can replace some parts of the DOM with scripting.

I realise this, however requiring script to style the body or it's contents is not elegant, and ultimately increases the time it takes for browsers to rendering pages. We have a noscript element that displays content when scripting is not available (or disabled) - I think it makes sense to have another element that displays content if script is present and enabled - and have it optionally dependent upon script versions supported by the UA.

* What is the feature you are suggesting to help solve it?
I'm not sure on a suitable element name, but a workmate joked it should be YESSCRIPT. I'm completely open to suggestions for the element name and attributes...

eg:

Code: Select all

<yesscript minver="1.2"  maxver="*">
<!--Display super duper JavaScript 1.2 panel that does something cool-->
</yesscript>


* What is the processing model for that feature, including error handling?
The NOSCRIPT element would behave the same as it does currently, so lets forget about that.

User agents not supporting JavaScript, or with JavaScript disabled would need to ignore content inside the YESSCRIPT element.

How do you make it degrade in existing UAs?

I don't really know... anybody have any suggestions? I assume the existing UAs would ignore these elements and render the markup inside (this might be an issue or still require scripted styling).

User agents with JavaScript enabled should look for the optional attributes minver/maxver. If minver is 1.2 and maxver is not present (or an asterisk or something), and the user agent has JavaScript 1.5, then the user agent would render the YESSCRIPT content immediately.

I would think YESSCRIPT would contain block level elements.

* Why do you think browsers would implement this feature?
To make it easier (or more pleasant) for users to experience web sites based upon the JavaScript capabilities of said browsers.

I'm not convinced.

Do'h

For an example, say you loaded http://www.xhtmlized.com without JavaScript enabled, the (JavaScript dependent) pages/days sliders would not be visible - and this is made possible by an element, not by JavaScript (which isn't enabled in this case anyway).

Without JS I still get some information, namely what it costs for 1 page in 7 days, and the sliders indicate that pages and days are variable. To make it more useful without JS you don't hide it altogether, you make a form out of it and let the server calculate the cost for other pages/days combinations (and then override it with client side script, i.e. progressive enhancement). So it's not clear to me that your proposed feature would help in this case at all.

* Why do you think authors would use this feature?
To support accessible sites supporting JavaScript and script-less operation with the same markup, and no dependency on JavaScript to hide/show content based upon the user agent's JavaScript capabilities.

Doesn't your proposed feature require different markup for the scripted and non-scripted cases? In any case, it is already possible to create accessible sites JavaScript and script-less operation with the same markup, by not using <noscript> but instead starting from functional markup involving the server to do scripted stuff and using client side script as an enhancement.

I realise the server can be used, however this places more load on the server - and assumes that dynamic pages are permitted by the hosting company/environment. I just think it would be easier for the browser to decide what it should render based upon it's capabilities - without using server or client side scripting.

* What evidence is there that this feature is desparately needed?
These days countries like AU, GB and US have DDA/508 laws requiring accessible sites. I develop an ecommerce application, and based upon the accessibility guidelines such as:

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]

we need to ensure that our application is accessible to all regardless of JavaScript being present, and the JavaScript version. Requiring JavaScript to display JavaScript specific controls/panels etc. seems like a workaround - when an element would be more elegant.

I see JavaScript getting more widespread, more governments requiring accessible content and sites paying attention to accessibility. A YESSCRIPT style element would make the lives of developers easier, and hopefully websites more usable to users.

As stated previously, I'm completely open to suggestions on the element name and attribute names. I'm interested in hearing what others think, and if there are any improvements that can be made. If it's a bad idea, or I have completely overlooked something major I'm sure you'll let me know

Accessibility guidelines or laws don't support your proposal because it's already possible to create existing pages without it, as I mentioned above.

It is possible, but I don't consider it elegant - more like it's a workaround or an afterthought. Noscript is elegant - I wish I had the internet when it was first suggested so I could have suggested this. Newer/future web developers will probably find yesscript(?) easier to understand and implement.

I'm thinking this element might need a type attribute so script language and version requirements could be expressed to the UA? Seems like I still have convincing to do - I will have to put some thought into it

--Mike--

[zcorpan]

The problem is that scripting may be enabled and the version is supported but the script still uses e.g. unsupported DOM APIs. You don't know if the script is actually supported without running it, and when you run it you could replace the "noscript" content with your fancy "yesscript" content using the script. This way you can never get into a situation where you show the "yesscript" content but it doesn't work because something in the script wasn't supported after all.

You also haven't explained how it is supposed to be implemented or what the backwards compatibility story is.

[bfrohs]

Here is a possibility for backwards compatibility.

<yesscript minver="1.2" maxver="*">
<!--Display super duper JavaScript 1.2 panel that does something cool-->
</yesscript>

turns into

<!--[if jsver 1.2-*]>
<script type="text/javascript>
<!--Display super duper JavaScript 1.2 panel that does something cool-->
</script>
<![endif]-->


Also, on a side-note, I believe UAs should send what version of JavaScript they support (currently using) as well as if scripting is enabled. This would allow for PHP (or another back-end language) to send different javascript code. This would also be highly backward compatible...even more-so than the example above. If the server received the two above variables (jsver and jsenabled), it knows that it is safe to provide javascript of that version to the browser. If the UA does not provide those variables (if either is missing), the server sends non-javascript pages. It may be difficult for those just starting out in the field, but would be excellent for experienced developers/designers.

If the above feature (sending variables to server) is implemented, this would allow for UAs to catch up on current standards. I believe the UA must not send the JavaScript Version unless the UA supports all of the language version. This would enhance the experience of the visitor to the website as well as the designer/programmer.

[mskinner]

Hi Bfrohs,

Thanks for the comment.

I was thinking that the contents of yesscript would primarily be HTML elements, but script block would be acceptable too. Your HTML commented example is similar to what was used back in the day:

Code: Select all

<script language="javascript1.2">


However now the language attribute has been deprecated. Now we are using the following, which doesn't discriminate based upon the version that the UA supports (which kinda sucks):

Code: Select all

<script type="text/javascript">


I also have a feeling that the HTML conditional comments are Internet Explorer specific (please correct me if I am wrong):
http://msdn2.microsoft.com/en-us/library/ms537512.aspx

I agree that UAs sending the JS version would be neat. You could limit it to one variable - the version. A value of zero could mean that JavaScript is disabled? User agents already send the web server info on whether they accept HTML, XHTML (application/xhtml+xml), HTTP version supported and gzip/deflate compression - I don't know why JavaScript couldn't have something similar.

[bfrohs]

Yes, it is IE-specific, but it is a good idea...as much as I hate to say it, Microsoft may have something here. JavaScript would work perfectly in this case...except what we're trying to find out is if the browser even supports JS, and what version, so conditional statements would be the best way to do this browser-side.

I would prefer the UA sending the JavaScript information direction to the server though, as I have always been one for having clean code presented to the user.


As an afterthought, I can see why the language attribute was removed...As zcorpan stated above, even if a browser 'supports' a certain version, it may not support everything in that version. That is why I propose UAs must support everything in a JS version in order to claim to support it. A possibility to allow for less support than full would to release multiple versions of JavaScript...for example, one version would be a full version...another version would be some of the most used functions...another version would have functions that a mobile device could support (Cell Phone for example). It seems like a pain, but I believe in the end it would end the trouble of having broken websites. After all, we're trying to advance the web, not just make it more confusing.

[zcorpan]

As an afterthought, I can see why the language attribute was removed...As zcorpan stated above, even if a browser 'supports' a certain version, it may not support everything in that version.

Indeed. (Though that's not the reason the language attribute was deprecated, and you can still specify version using type="" by having a version parameter.)

That is why I propose UAs must support everything in a JS version in order to claim to support it.

But this doesn't work. Browsers never support everything in one go, they add support for new stuff incrementally, and even if they believe to support everything they will still have bugs, so you can never trust that if a UA declares to support X that it actually does so fully and correctly. You also have the scenario where a particular UA supports the feature you want to use but not some other feature that is in the same "version", and so won't run your script even though it would be capable.

A possibility to allow for less support than full would to release multiple versions of JavaScript...for example, one version would be a full version...another version would be some of the most used functions...another version would have functions that a mobile device could support (Cell Phone for example). It seems like a pain, but I believe in the end it would end the trouble of having broken websites. After all, we're trying to advance the web, not just make it more confusing.

This is where the idea starts to get hairy. Multiply the number of versions you introduce with the number of UAs and that is the mess you'll have to deal with.

The better approach, IMHO, is to:

1. Make the page "work" for UAs that only support HTML and HTTP (if necessary for your purpose)
2. Add client side scripting enhancements where you check that each feature is implemented and works correctly (if you think some UAs will have bugs) before you use it (rather than trusting what the UA claims it supports).

If you do this, you don't need to know what "version" the browser supports. It doesn't matter. You only check the features you use before using them. It doesn't even make a difference whether scripting is enabled or not.

Also note that the DOM has something called feature strings, where you can see whether the UA claims to support a specific feature or version of something, but no-one uses it (probably because it is unreliable -- it suffers from the same problems as this proposal).

[nog_lorp]

Maybe call it ifscript instead? Letter-runs in all lower case unspaced type is a bit of a pain.

[luzagodom]

mskinner wrote:
* What is the problem you are trying to solve?
There is a useful element NOSCRIPT that can display content based upon JavaScript not being enabled (or not being present if using lynx).

There doesn't appear to be an element to display content based upon JavaScript being enabled, and optionally based upon the version of JavaScript that the user agent supports. Some people get around this by using CSS visibility/display when the server serves up a page, and requiring the onload event to set the div to visible/block.
It's not clear to me from the above what the problem actually is.

If you want different styling when scripting is enabled or not, you can e.g. use <noscript><link rel=stylesheet></noscript> or <script> document.body.className += " js-enabled" </script> and then prefix the relevant selectors with .js-enabled.

If you want to use different markup when scripting is enabled then you can replace some parts of the DOM with scripting.

mskinner wrote:
* What is the feature you are suggesting to help solve it?
I'm not sure on a suitable element name, but a workmate joked it should be YESSCRIPT. I'm completely open to suggestions for the element name and attributes...

eg:
Code:

<yesscript minver="1.2" maxver="*">
<!--Display super duper JavaScript 1.2 panel that does something cool-->
</yesscript>



* What is the processing model for that feature, including error handling?
The NOSCRIPT element would behave the same as it does currently, so lets forget about that.

User agents not supporting JavaScript, or with JavaScript disabled would need to ignore content inside the YESSCRIPT element.
How do you make it degrade in existing UAs?

[mskinner]

This topic was concluded in 2007.