Please login or register.

Login with username, password and session length
Advanced search  

News:

You need/want an older version of sNews ? Download an older/unsupported version here.

Author Topic: Javascript Dependency  (Read 2833 times)

centered

  • Guest
Javascript Dependency
« on: November 29, 2009, 04:18:51 PM »

Just thinking as I am doing some coding in my free time... should sNews be dependent on javascript or should provisions be made to use the system in the even that javascript isn't present?

It got me thinking as I checked up on a site for jquery info.  The beginners article had a form with a link with an javascript function attached to it.  If JS was disabled, then the link wouldn't work.  I corrected the author of the article here http://woorkup.com/2009/11/22/jquery-for-beginners-making-your-website-cool/#div-comment-3414

What does that have to do with sNews... Well in thinking, for example, if the buttons() function for a new admin doesn't work for a user w/o JS enabled, no error messages are noted and nothing is noted on the front page for admins to warn them of this (bug brewing?).  Maybe another example would be the toggle functions or the content preview function. Is this something we should plan for or start doing now (1.8?)? 
« Last Edit: November 29, 2009, 04:20:40 PM by equilni »
Logged

Joost

  • Guest
Re: Javascript Dependency
« Reply #1 on: November 29, 2009, 05:24:07 PM »

No part of the system should rely upon javascript only. So basically javascript should be a redundant layer on top of the functionality provided by xhtml and php.
I also think that forms (-processing) should be editor neutral. Right now fprms don't work well with popular editors, as input is modified by php (&).
2.0 could come with a default editor (Whizzywig for instance), but switching to another editor should be fairly simple.
Logged

centered

  • Guest
Re: Javascript Dependency
« Reply #2 on: November 29, 2009, 08:00:35 PM »

Quote
No part of the system should rely upon javascript only. So basically javascript should be a redundant layer on top of the functionality provided by xhtml and php.

Good, now that is settled, I will rethink the js approach in the re-factoring (id did and plant to do) and apply php solutions as if a js solution is not present.
Logged

Fred K

  • Still trying to learn stuff
  • ULTIMATE member
  • ******
  • Karma: 130
  • Posts: 2728
    • Personal
Re: Javascript Dependency
« Reply #3 on: November 30, 2009, 02:08:13 AM »

Joost is fundamentally right that essential functions shouldn't be javascript dependent. That said, a recent survey (I forget who published it, I have the link somewhere deep in my Twitter archive -- I think it was Smashing Magazine though) showed that a large majority of visually impaired web users -- e.g screen reader users -- do not bother with disabling javascript. Javascript enabling/disabling was in the bottom third of Important Things for impaired users. And we know that the average seeing web user typically doesn't change any browser factory setting (and the default setting in almost all modern browsers is to allow javascript to at the very least a functional degree). So, there are two sides to the coin.

Second, if 2.0 comes with a default editor it should be simple enough to disable it -- for those who do not want the extra layer of a wysiwyg editor (throws all available hands in the air, waving frantically, mouthing a desperate "me, me!") ;)
Personally I feel that any editor should be an opt-in thing, not opt-out, but I can certainly understand that many wants it by default and definitely many end users (when not the site developer) would appreciate it.
Logged

Joost

  • Guest
Re: Javascript Dependency
« Reply #4 on: November 30, 2009, 03:50:45 AM »

Joost is fundamentally right that essential functions shouldn't be javascript dependent. That said, a recent survey (I forget who published it, I have the link somewhere deep in my Twitter archive -- I think it was Smashing Magazine though) showed that a large majority of visually impaired web users -- e.g screen reader users -- do not bother with disabling javascript. Javascript enabling/disabling was in the bottom third of Important Things for impaired users.

I find it a bigger concern whether a screen reader supports the javascript that's being applied. Also readers might get disorientated by events on the page.
Some reading stuff on screenreaders and javascript

Update: Fred, you mean this article: Survey of Preferences of Screen Readers Users ?
« Last Edit: November 30, 2009, 04:02:53 AM by Joost »
Logged

Fred K

  • Still trying to learn stuff
  • ULTIMATE member
  • ******
  • Karma: 130
  • Posts: 2728
    • Personal
Re: Javascript Dependency
« Reply #5 on: November 30, 2009, 10:54:43 AM »

I find it a bigger concern whether a screen reader supports the javascript that's being applied. Also readers might get disorientated by events on the page.
Some reading stuff on screenreaders and javascript

Oh, definitely. Thing is that we generally, casually, pose the question "is js enabled or disabled and what do we do if disabled", when we should be considering how events affects users. Of course it's better to ask the casual question than not thinking at all about the impact of various details, but it might be worth thinking more deeply about the construction and what it might do to various types of users. But I'm rambling. Thanks for the link. Will read.

Update: Fred, you mean this article: Survey of Preferences of Screen Readers Users ?

Nope, it was the second one, I believe: Screen Reader User Survey Results (update)

And while on the subject of javascript, although not related to buttons or accessibility, here's an interesting piece landed in my RSS box this morning, courtesy of webfonts.info: Javascript detection of font smoothing (for @font-face contexts)
Logged

centered

  • Guest
Re: Javascript Dependency
« Reply #6 on: November 30, 2009, 01:13:43 PM »

I also think that forms (-processing) should be editor neutral. Right now fprms don't work well with popular editors, as input is modified by php (&).
2.0 could come with a default editor (Whizzywig for instance), but switching to another editor should be fairly simple.

Are you referring to these lines?
Code: [Select]
$frm_text = str_replace('&', '&', $_SESSION[_SITE.'temp']['text'] ? $_SESSION[_SITE.'temp']['text'] : $r['text']);
if(substr_count ($fulltext, '&')>0){$fulltext = str_replace('&', '&', str_replace('&', '&', $fulltext));}

If so, then seeing there is only 2 lines, this can be removed. Then with moving buttons() to a js only solution, it (in thinking....) would free up the space for other editors to be (again, in thinking) easily applied.

Could be like so:
Code: [Select]
<textarea id="txt"></textarea>
<script>
window.onload = addEditor();

function insertAfter( referenceNode, newNode ) {
referenceNode.parentNode.insertBefore(newNode, referenceNode.nextSibling);
}

function addEditor() {
var editor = document.createElement('<script>');
// Add the editor here
editor.innerHTML = 'makeWhizzyWig("edited", "all");';
var textArea = document.getElementById('txt');
insertAfter( textArea, editor );
}
</script>
Logged

Joost

  • Guest
Re: Javascript Dependency
« Reply #7 on: November 30, 2009, 01:56:36 PM »

I also think that forms (-processing) should be editor neutral. Right now fprms don't work well with popular editors, as input is modified by php (&amp;).
2.0 could come with a default editor (Whizzywig for instance), but switching to another editor should be fairly simple.

Are you referring to these lines?

I had no particular lines in mind, as there is no 2.0 version.

Just for example, here is what I did when developing Stand-alone contact form:
If required fields are empty, the form is send back to the user (including the message), who is then presented with a check list (3 attemps max), telling the user what to change or fill out. The majority of users who do have javascript enabled, will never get to see the list (except for a wrong captcha value), as a script prevents the form being sent. Although I kept the javascript functionality simple (preventing sending only), I can imagine javascript functionality that displays a check list similar to the one send by the server.

In sNooze-IC for instance, a list of selected items can be deleted. Where others might use a javascript alert box, I choose to use an xhtml checkbox with the text "You want to delete all selected items?" instead.

Logged

centered

  • Guest
Re: Javascript Dependency
« Reply #8 on: November 30, 2009, 05:12:34 PM »

I was referring to the "right now" code for &amp

Yes your solutions are ones I would most likely recommend as well.
Logged