can we know if the user has js on?

[Ken1]

Is there a way to know if the user has javascript on? Also, is it a
good idea to validate all input in js and php or will this slow down
the website?

 

[kday33]

To test if javascript is enbabled, try some of these links for
starters:

http://www.google.com/search?q=test javascript enabled

As a rule of thumb, always validate form data on the server side (php).
Validating at the client is only helpful if you give the user a quick
error message telling them their input is not complete or incorrect.
It's just to so that they don't have to wait for the round trip from
the server to find out they forgot a field.

 

[VK]

Is there a way to know if the user has javascript on?

<form ...>
....
<noscript>
<input type="hidden" name="NoScript" value="true">
</noscript>
....

Also, is it a
good idea to validate all input in js and php or will this slow down
the website?

It is a very good idea to have it. It is very bad idea to trust it.

 

[Randy Webb]

VK said the following on 11/30/2006 11:26 PM:

<form ...>
...
<noscript>
<input type="hidden" name="NoScript" value="true">
</noscript>
...
</form>

As long as you don't mind invalid HTML and the consequences that come
from it.

 

[Ken1]

Would it work to have an onLoad function in js which will be executed
if js IS on by using AJAX to store a temp var in the db then right away
retrieve that info from db... if the value exists, then js is on. if no
value then js is off. this way i could provide different info for those
who have js off and those who have it on... i guess the only problem is
if the js function is executed at the end of the php.

 

[VK]

As long as you don't mind invalid HTML and the consequences that come
from it.

What is not valid in here? That is block element NOSCRIPT containing
"inline" input element. I'm putting "inline" into quotes because it is
difficult to name a display type of a non-rendering element (input
type="hidden").

It is true that the current W3C Validator beta (0.7.4 at the time I'm
writting) has a bug in it so it wants extra block element for
input="hidden" which has no sense:
<noscript>
<p><input type="hidden" name="NoScript" value="true"></p>
</noscript>
makes the Validator all happy and your code all crazy So simply
disregard this error message, it's here by mistake.

btw another silly bug I still hope to be ever fixed is to stop
Validator to validate tags inside SCRIPT element. Against of specs
clearly stating that anything inside SCRIPT is not of HTML parser
business, in case like:
<script type="text/javascript" src="lib.js">
<params>
<param>
<name>par1</name>
<value>val1</value>
</param>
</params>
</script>
the Validator will start complain about params, param etc.

 

[Thomas 'PointedEars' Lahn]

What is not valid in here? That is block element NOSCRIPT containing
"inline" input element. I'm putting "inline" into quotes because it is
difficult to name a display type of a non-rendering element (input
type="hidden").

It is true that the current W3C Validator beta (0.7.4 at the time I'm
writting) has a bug in it

Yes, it has some bugs. However, this is not one of them, but simply that
kind of standard-conforming behavior you are seemingly unable to
comprehend. (I was about 6 months away and yet you have not understood.)

JFTR:

so it wants extra block element for input="hidden" which has no sense:
<noscript>
<p><input type="hidden" name="NoScript" value="true"></p>
</noscript>
makes the Validator all happy and your code all crazy So simply
disregard this error message, it's here by mistake.

The `noscript' element requires block elements for its child elements in
HTML 4.01 Strict, ISO HTML, XHTML 1.0 Strict and XHTML 1.1. For example,
the HTML 4.01 Strict DTD [1] says:

<!ELEMENT NOSCRIPT - - (%block+
-- alternate content container for non script-based rendering -->

Despite your "explanation", the `input' (X)HTML element, no matter the value
of its `type' attribute, is designated an inline element (ibid.):

<!ENTITY %
inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">

<!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">

By making the `input' element a child element of a `p' element, and that `p'
element a child element of the `noscript' element, you have simply
fulfilled that constraint (ibid.):

<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">

You could also have declared HTML 4.01 Transitional which "loose"ned you
from that constraint [2]:

<!ELEMENT NOSCRIPT - - (%flow*
-- alternate content container for non script-based rendering -->

<!ENTITY % flow "%block; | %inline;">

Please get informed once before you post. Probably someone asked that of
you before.


PointedEars
___________
[1] http://www.w3.org/TR/html401/interact/scripts.html#edef-NOSCRIPT
http://www.w3.org/TR/html4/strict.dtd
[2] http://www.w3.org/TR/html401/sgml/loosedtd.html#flow

 

[Matt Kruse]

...

Do my eyes deceive me? Could it be?

"The reports of my death are greatly exaggerated."
- PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

Yes, it has some bugs. However, this is not one of them, but simply that
kind of standard-conforming behavior you are seemingly unable to
comprehend. (I was about 6 months away and yet you have not understood.)

Your absence has been greatly appreciated.

 

[VK]

By making the `input' element a child element of a `p' element, and that `p'
element a child element of the `noscript' element, you have simply
fulfilled that constraint (ibid.):

<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">

You could also have declared HTML 4.01 Transitional which "loose"ned you
from that constraint [2]:

<!ELEMENT NOSCRIPT - - (%flow*
-- alternate content container for non script-based rendering -->

<!ENTITY % flow "%block; | %inline;">

Please get informed once before you post. Probably someone asked that of
you before.

The most interesting in here is that all profound standard-compliance
testings (by you and by Randy) were done on this text (as I did not
post anything else on the topic):

<form ...>
....
<noscript>
<input type="hidden" name="NoScript" value="true">
</noscript>
....
</form>

Could we call this fragment a bit too... fragmental... to investigate
its exact DTD? ;-)

P.S. "...Thomas will be back on Christmas..."... so the real fun may
start... :-0

Follow the white rabbit on:
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/7c4b17e65bb562dc>
and on:
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/edc1c6099a545e63>

There are some important changes with the FAQ

 

[Thomas 'PointedEars' Lahn]

By making the `input' element a child element of a `p' element, and that
`p' element a child element of the `noscript' element, you have simply
fulfilled that constraint (ibid.):

<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">

You could also have declared HTML 4.01 Transitional which "loose"ned you
from that constraint [2]:

<!ELEMENT NOSCRIPT - - (%flow*
-- alternate content container for non script-based rendering -->

<!ENTITY % flow "%block; | %inline;">

Please get informed once before you post. Probably someone asked that of
you before.

The most interesting in here is that all profound standard-compliance
testings (by you and by Randy) were done on this text (as I did not
post anything else on the topic):

<form ...>
...
<noscript>
<input type="hidden" name="NoScript" value="true">
</noscript>
...
</form>

Could we call this fragment a bit too... fragmental... to investigate
its exact DTD? ;-)

No, because you also have provided the W3C Markup Validator's result on this
and on the variant where there is a child `p' element. Since it can be
proven easily that there is no such bug in the Validator as you claimed, it
is clear that either you have told a false validation result (obviously
trying to disparage the Validator and the W3C again by falsely claiming the
Validator still being a beta version [1]) or, equally likely, that you have
still not understood HTML, and SGML-based markup languages for that matter,
yet.

[FAQ changes]

Is there any point regarding this discussion in that? Because I sure don't
see it.


PointedEars
___________
[1] http://validator.w3.org/whatsnew.html