turning off javascript..

  • Thread starter The Natural Philosopher
  • Start date
T

The Natural Philosopher

Ok, this is a very general question. I am designing the public facing
part of a sales website, and want to be as compatible as I can with
everybody, as opposed to the internal side,where I used what was in
house standard to full effect.

In a way this is an odd post, because its about NOT using javascript.

Let me explain. To date, the simplest way of making anything 'do
something' when clicked, was to attach a basic event handler, and call a
URL and set one or more post variable using js.

Now, if I posit 'javascript off' I must needs do it with straight URLS,
and only GET variables embedded in it to control server side behaviour.

Or is there a way to set up one or more POST variables from a click on a
URL? I am not totally enamoured with multiple submit buttons either..
but its a possibility..

How do others approach this problem, and why?

On a similar note, I guess there is no way to have flyout menus without
a server reload..if js is off, either..

Or should I just say 'sod it: if they want to use this site, its JUST
possible without JS, but its ugly and clunky, and its there fault for
not turning it on' ?
 
J

JR

In a way this is an odd post, because its about NOT using javascript.

Let me explain. To date, the simplest way of making anything 'do
something' when clicked, was to attach a basic event handler, and call a
URL and set one or more post variable using js.

Now, if I posit 'javascript off' I must needs do it with straight URLS,
and only GET variables embedded in it to control server side behaviour.

Or is there a way to set up one or more POST variables from a click on a
URL?  I am not totally enamoured with multiple submit buttons either..
but its a possibility..

How do others approach this problem, and why?

On a similar note, I guess there is no way to have flyout menus without
a server reload..if js is off, either..

Or should I just say 'sod it: if they want to use this site, its JUST
possible without JS, but its ugly and clunky, and its there fault for
not turning it on' ?

It's possible to develop a website without using javascript in the
client-side. Take a look at Amazon and Google Maps for instance: they
don`t look `ugly and clunky` without JS. Menus can be achieved with
CSS only. But `post` can only be used within a form, I think.

Cheers,
JR
 
E

Erwin Moller

The Natural Philosopher schreef:

Hi TNP,
Ok, this is a very general question. I am designing the public facing
part of a sales website, and want to be as compatible as I can with
everybody, as opposed to the internal side,where I used what was in
house standard to full effect.

In a way this is an odd post, because its about NOT using javascript.

Let me explain. To date, the simplest way of making anything 'do
something' when clicked, was to attach a basic event handler, and call a
URL and set one or more post variable using js.

Now, if I posit 'javascript off' I must needs do it with straight URLS,
and only GET variables embedded in it to control server side behaviour.

And a lot more of course.
You have forms with all kind of elements in it: radiobutton, checkboxes,
etc. Using them smart can make things easy and intuitive for the user,
even with JavaScript disabled.

About the GET, I prefer putting everything in a POST instead of GET.
When some elements contain a lot of characters (textarea for example)
GET will get you in trouble on some setups. (If memory serves me well:
IIS used to accept 2048 characters or something as a maximum in the URL
itself).

And you can always write info from the URL inside the forms, using
hidden variables.

Or is there a way to set up one or more POST variables from a click on a
URL? I am not totally enamoured with multiple submit buttons either..
but its a possibility..


Without JavaScript you MUST solve your problems with the standard
elements in the form. So if you need more submitbuttons, do that. :)
For example:
<input type="text" name="whatever">
<input type="submit" name="submitbutton" value="update">
<input type="submit" name="submitbutton" value="delete"
style="background:#FF0000;">

is perfectly easy to understand for the user I expect.
At the server you simply get the value for submitbutton and do your stuff.
I have no problems with multiple submitbutton. Do you?

How do others approach this problem, and why?


The best approach is to code for both JavaScript enabled visitors and
disabled visitors alike.
I have been in situations where I found it easier to branch my scripts:
One for enabled, one for disabled: It is not a great solution, but I had
cases where I needed loads of happy complex (for me) JavaScript that
could drag and drop, place images over others, etc.
The JS-disabled version only needed 2 coordinates, so I thought
branching the pages I served was easier.

However, in most (even all I expect) cases it is possible to write one
page that handles both enabled and disabled JavaScript fine.

On a similar note, I guess there is no way to have flyout menus without
a server reload..if js is off, either..

That IS possible with CSS.
You don't need JavaScript at all for that.
Google for: css drop down menu no javascript

(HTML5 will support this kind of menus without css, but that is of no
use for you now.)

Or should I just say 'sod it: if they want to use this site, its JUST
possible without JS, but its ugly and clunky, and its there fault for
not turning it on' ?


In the end, that is for your client to decide.
Estimates I heard are that 2% to 8% have JavaScript disabled.
But it is hard to get reliable numbers on that I understood, so make up
your own mind.

Telling them to sod it might result in 2-8% lower sales.

I have made sites that were only usable with JavaScript enabled. If my
client wants that and don't want to spend a dime extra for the
JavaScript disbled browsers, I make it like that even tough I dislike it.

In my opinion it is often possble to code for both situations straight
away with little extra effort, like form validation.
I know you are a PHP programmer, so you do the serverside validation
anyway.
It is not hard at all to return the form with problematic fields
highlighted, and only accept at the server when they are fine.

But that is formvalidation. I am not sure what it is you are working on
excactly now, maybe there is more involved.


Just my 2 cent.

Regards,
Erwin Moller


--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
 
T

The Natural Philosopher

Erwin said:
The Natural Philosopher schreef:

Hi TNP,


And a lot more of course.
You have forms with all kind of elements in it: radiobutton, checkboxes,
etc. Using them smart can make things easy and intuitive for the user,
even with JavaScript disabled.

Oh I use all that already.
About the GET, I prefer putting everything in a POST instead of GET.
When some elements contain a lot of characters (textarea for example)
GET will get you in trouble on some setups. (If memory serves me well:
IIS used to accept 2048 characters or something as a maximum in the URL
itself).

And you can always write info from the URL inside the forms, using
hidden variables.

well no, typically without JS you cant.

You can at best set one post variable per submit button.

Not half a dozen after a lot of logic ;-)

Not insuperable..but the dirt all goes to the server.
Without JavaScript you MUST solve your problems with the standard
elements in the form. So if you need more submitbuttons, do that. :)
For example:
<input type="text" name="whatever">
<input type="submit" name="submitbutton" value="update">
<input type="submit" name="submitbutton" value="delete"
style="background:#FF0000;">

is perfectly easy to understand for the user I expect.
At the server you simply get the value for submitbutton and do your stuff.
I have no problems with multiple submitbutton. Do you?

I have a problem with submit buttons AT ALL in that they are limited in
stylistic capabilities.

And then someone hits the 'enter' key..
The best approach is to code for both JavaScript enabled visitors and
disabled visitors alike.
I have been in situations where I found it easier to branch my scripts:
One for enabled, one for disabled: It is not a great solution, but I had
cases where I needed loads of happy complex (for me) JavaScript that
could drag and drop, place images over others, etc.
The JS-disabled version only needed 2 coordinates, so I thought
branching the pages I served was easier.

Nice trick. I'll tuck that one away..for later.
However, in most (even all I expect) cases it is possible to write one
page that handles both enabled and disabled JavaScript fine.



That IS possible with CSS.
You don't need JavaScript at all for that.
Google for: css drop down menu no javascript

Hmm. how do you toggle visible/invisible without JS?
(HTML5 will support this kind of menus without css, but that is of no
use for you now.)




In the end, that is for your client to decide.
Estimates I heard are that 2% to 8% have JavaScript disabled.
But it is hard to get reliable numbers on that I understood, so make up
your own mind.

Telling them to sod it might result in 2-8% lower sales.

Ok Fairy Nuff!
I have made sites that were only usable with JavaScript enabled. If my
client wants that and don't want to spend a dime extra for the
JavaScript disbled browsers, I make it like that even tough I dislike it.

In my opinion it is often possble to code for both situations straight
away with little extra effort, like form validation.
I know you are a PHP programmer, so you do the serverside validation
anyway.
It is not hard at all to return the form with problematic fields
highlighted, and only accept at the server when they are fine.

But that is formvalidation. I am not sure what it is you are working on
excactly now, maybe there is more involved.


Just my 2 cent.

Worth a few dollars at least. As usual, thought provoking, clear and
helpful. Thanks.
 
T

The Natural Philosopher

Swifty said:
Indeed, but if you *want* the "Submit" button to look like a link, you
can do that simply enough with CSS (I could do it, which is my
definition of "simply enough").
Problem I have with the submit button, is that if you style it with an
image of non square shape, with a transparent edge to it, what shows
through is NOT the background image of the containing element, but the
plain background COLOR of the containing element. Or possibly the
background color of the button itself. Hmm. Perhaps that's the problem.


Can you set a style to 'background color: transparent ?
 
D

Doug Miller

Doug Miller wrote:
I think I dint make myself clear. With js I can fire an evfent handler.,
set any amount of post variables, and do a submit. I can even submit to
a totally different target or spawn a popup window.

With strict HTML one button=one vale,

No. The array of POST variables sent to the server includes all named input
elements in the form, regardless of how many submit buttons there are.
and unless I use two forms, one
target URL and no spaewning of windows.

With a straight URL I can spawn a window, but how to pass variables to
it? Except with 'get'
Cookies?

Use POST to pass the values to a server-side script which then generates the
code to spawn the new window. This is trivially easy with PHP.
Well I do that already. However its a page load every time, and that
gets clunky. This server for other reasons sits on a slow link.


Well Its certainly worth making the attempt I suppose. You are damned if
you do ('doesn't work properly without java script') and damned if you
dont ('its dull and old fashioned and slow')

There's no reason for a JS-free site to be dull and old-fashioned. That's
purely the result of failed site design, unrelated to the technologies used to
implement the site.
There's a LOT of sites out there than ONLY work on IE5/6/7/8

And shame on the boobs that designed and implemented them.
 
D

Doug Miller

Problem I have with the submit button, is that if you style it with an
image of non square shape, with a transparent edge to it, what shows
through is NOT the background image of the containing element, but the
plain background COLOR of the containing element. Or possibly the
background color of the button itself. Hmm. Perhaps that's the problem.

Perhaps the problem is how you've defined the button.Do you have
<input type="submit"...> or <input type="image"...> ?
 
T

Thomas 'PointedEars' Lahn

Doug said:
No. The array of POST variables sent to the server includes all named
input elements in the form, regardless of how many submit buttons there
are.

There is no "array of POST variables". The message body of an HTTP POST
request is a string, with a HTML form it is usually

name1=value1&name2=value2

etc., with names and values URL-encoded. It is only the server-side
application, e.g. PHP, that makes an (associative) array (e.g.,
$HTTP_POST_VARS or $_POST) out of it.


PointedEars
 
D

Doug Miller

There is no "array of POST variables".

From the perspective of a server-side script, there certainly is (e.g. $_POST
in PHP).
The message body of an HTTP POST
request is a string, with a HTML form it is usually

name1=value1&name2=value2

etc., with names and values URL-encoded. It is only the server-side
application, e.g. PHP, that makes an (associative) array (e.g.,
$HTTP_POST_VARS or $_POST) out of it.

I'm afraid you've missed the point altogether, which is that I was correcting
the previous poster's misapprehension that only one value could be transmitted
per submit button.
 
T

Thomas 'PointedEars' Lahn

Doug said:
From the perspective of a server-side script, there certainly is (e.g.
$_POST in PHP).

The perspective was not any server-side application here.
I'm afraid you've missed the point altogether, which is that I was
correcting the previous poster's misapprehension that only one value could
be transmitted per submit button.

No, I did notice that. Your answer was partially wrong anyway (as the
question was completely wrong).


PointedEars
 
D

Doug Miller

The perspective was not any server-side application here.

Actually, yes it was, since the OP was asking how to accomplish a task
*without* using javascript, and my discussion with him described in a general
way how to manage it using server-side scripting.
No, I did notice that. Your answer was partially wrong anyway (as the
question was completely wrong).

Wrong in what way, pray tell?
 
T

The Natural Philosopher

Doug said:
No. The array of POST variables sent to the server includes all named input
elements in the form, regardless of how many submit buttons there are.

You still misunderstand, the action of pressing the button can only, by
itself, _change_ ONE of them.

Whereas an event handler can set up as many from that one button press
as you care to code for.

Use POST to pass the values to a server-side script which then generates the
code to spawn the new window. This is trivially easy with PHP.

? eh? I dont see that. How can I get two windows where only one was
before! the broswer itself is the only entity that can spawn a new windows.

There's no reason for a JS-free site to be dull and old-fashioned. That's
purely the result of failed site design, unrelated to the technologies used to
implement the site.

Well, by using thicker clients, you can., at the expense of a slower
initial download, get a much faster context dependent experience for the
user.

To do that all server side, means a reload every time the user does
something that mandates a change in context.

e.g. one sren I have pops up the COMPLETE stock list in a series of
hierarhical fly out menus: This means selecting a stock item is very
fast: the flip side is the whole list has to be downloaded, and the
initial download takes a few tenths of a second. Fortunately it
compresses well, being mainly repetitive text.

To do it by repeated calls to the server, is a few tenths to reload the
page header stuff anyway. Iframes might work there though.



And shame on the boobs that designed and implemented them.

yeah? fair enough, but when its a mandatory site put up by one of the
largest banks in Europe. and you need the info, guess who can throw the
two fingers. Not you, the poor user.
 
T

The Natural Philosopher

Doug said:
Perhaps the problem is how you've defined the button.Do you have
<input type="submit"...> or <input type="image"...> ?

Input type submit Doug.

I've just glanced through the code, and there is no background colour at
a deeper level of nesting than the main background image: So its a
'feature' of all browsers that a styled button with transparency on its
image, doesn't honor the background image behind it.
I.e. If you have e,g.

<div class="with_background_image">
<input class="with_different_background_image_with_transparent_bits"
type="submit">
</div>

What shows through the transparent bits is the last set background
colour. Not the last set background image.
 
T

The Natural Philosopher

Thomas said:
There is no "array of POST variables".

Muy Bad, that's how they appear in PHP, of course, but you are perfectly
right.

The message body of an HTTP POST
request is a string, with a HTML form it is usually

name1=value1&name2=value2

etc., with names and values URL-encoded. It is only the server-side
application, e.g. PHP, that makes an (associative) array (e.g.,
$HTTP_POST_VARS or $_POST) out of it.

Correct, as always, Thomas. ;-)
 
T

The Natural Philosopher

Thomas said:
No, I did notice that. Your answer was partially wrong anyway (as the
question was completely wrong).

I am not sure how, philosophically speaking, a question can be *wrong*.

It may be wildly inappropriate:
"How can I eat bananas using pick-axe?"
or
"Why is Unicorn dung better than cornflakes?"

But wrong? No.
Wrongness is a property of statements about the truth or otherwise of
the stated proposition.

Unless you are implying that the question contained an implicit
statement that was wrong?

Sorry.. Been reading too much metaphsyics recently. :)
 
D

Doug Miller

You still misunderstand, the action of pressing the button can only, by
itself, _change_ ONE of them.

What?

You have multiple <input> elements in a form, and multiple submit buttons.
Click *any* of the submit buttons said:
Whereas an event handler can set up as many from that one button press
as you care to code for.

You don't need an event handler to transmit values from a form to a server.
? eh? I dont see that. How can I get two windows where only one was
before! the broswer itself is the only entity that can spawn a new windows.

Sorry, omitted one thing: target="_blank" attribute in the link.
 
J

JR

I am not sure how, philosophically speaking, a question can be *wrong*.

It may be wildly inappropriate:
  "How can I eat bananas using pick-axe?"
or
"Why is Unicorn dung better than cornflakes?"

But wrong? No.
Wrongness is a property of statements about the truth or otherwise of
the stated proposition.

Unless you are implying that the question contained an implicit
statement that was wrong?

Sorry.. Been reading too much metaphsyics recently. :)

OMFG, DFTT please.
 
J

JR

Muy Bad, that's how they appear in PHP, of course, but you are perfectly
right.

  The message body of an HTTP POST




Correct, as always, Thomas. ;-)

Correct but irrelevant, since anyway you would need a server-side
script (PHP, ASP, etc.) to retrieve the data submitted by the client.
 
J

JR

Correct but irrelevant, since anyway you would need a server-side
script (PHP, ASP, etc.) to retrieve the data submitted by the client.

Of course I'm considering that you've told us, from the beginning,
that you are "designing the public facing part of a sales website".
Therefore, you will need a server-side language and a server database
to accomplish that.

Cheers,
JR
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top