JS or not JS, that is the question

[JM Simonet]

Discussed with Mark yesterday and we agreed that this should go to list.

We committed 2 days ago http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=29786

We also had to correct the front-end single contact view as the addPanel function in bootstrap.php was indeed incomplete (Thanks Tim for the patch) and forced all core to use much more complex code to get the same results.

It was the only place in core where was used this addPanel function.

Look at master to see the changes in contact view.

This made me think more about the use of js in Joomla.

1. BACKEND

We know JS is compulsory in back-end. Nothing would work without JS enabled in the browser, whether for Isis or Hathor.

My question here will therefore be:

Shall we now use addPanel in backend instead of the complex way tabs are now created?

It would show the best use of bootstrap to developers and make our code leaner.

The matter is not if it would work or not (it does as one can see for the contact layout), it is rather: would this have a good/bad/no impact on accessibility?

If no specific problem for accessibility I volunteer to patch all admin ( about 20 pages)

2. FRONTEND

Display for the single contact.

In Beez3 JS disabled means that one has to choose Plain as layout for the single contact (sliders are broken and tabs are not even a possibility in the present code.) This will work.

In Protostar, one would also have to choose plain for single contact display.

In both cases, choosing sliders or tabs does not degrade gracefully if JS is not allowed in browser.

Any solution to this? Could we check if the method is enabled and, if not, swicth to plain as layout?

Where we get into a real problem is Editing an article, submit a Weblink.

In Beez3, as no sliders or tabs are used, the edit layout displays fine.

No WYSIWYG editor evidently.

But no way to Save, Cancel, + modals broken for insert article, image, pagebreak, etc.

In Protostar it gets even worse as tabs don't work at all and the drodown icon to choose Print, Mail, Edit is also broken.

So, shall we just give up allowing Joomla frontend to work when Javascript is disabled in browser with the usual <noscript> and make JS a requirement in J3?

Or is there a coding solution to solve these problems?

Thanks for your feedback
JM

-- 

Please keep the Subject wording in your answers

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the
intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies.

-----------------------------------------------------------

Jean-Marie Simonet  /  infograf768

Joomla Production Working group

Joomla! Translation Coordination Team 

[brian teeman]

webaim which is one of the most respected voices in the accessibility world run a survey each year of screen reader users  which you can see in full here http://webaim.org/projects/screenreadersurvey4/

Their latest survey showed that 98.6% of respondents had javascript enabled. When you take into account that traditionally represented the larger part  in the no javascript statistics I feel that the days of providing full site control without javascript are over.

[Matt Thomas]

Those are good numbers to know Brian, thanks.

Thanks for bringing this up on list JM and Mark.

In my opinion, part of responsible web development (responsible responsive web design) is to keep the page load to a minimal. That means not including JavaScript unless absolutely necessary.

@JM - When you write:

"So, shall we just give up allowing Joomla frontend to work when Javascript is disabled in browser with the usual <noscript> and make JS a requirement in J3?"

Would that be limited to only content editing functions, or would that open the door to JavaScript being used throughout the frontend?

Having JavaScript enabled is one thing, but forcing the user to load an entire JS library is another issue.

Other than adding to the page load, my biggest concern is the CMS frontend developing a dependency and tight coupling with JavaScript, whish could even make template overrides even more difficult.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[brian teeman]

There definitely is a massive difference between 

1. requiring JS for the site to function (not in favour of that)

and

2. requiring JS to administer the site and create content (not that bothered)

[Bakual]

I agree with Brian on this.

1. Should not happen. Sites should work without JS for most part.

2. don't mind if editing requires JS.

[JM Simonet]

The examples I talked about (single contact display and creating/editing articles and Weblinks) are the only ones I think of for the site part.

Quite a few libraries are loaded though. + added js in <head>. Look at source.

JM

[Michael Babker]

So long as all JavaScript use is left to overridable areas (i.e. Layouts), then that dependency only exists in the core use and templates and still be decoupled.

IMO, it would be great if JHtml elements were easier to override, at least for their markup or script dependencies.  That's where that unwanted use of memory is basically forced on users right now.  JHtml is in a mixed state in the CMS, and with a couple of requests, you easily have MooTools, Bootstrap (with it's jQuery dependency), and whatever other support scripts are called, as well as your own homegrown scripts.  Aside from JHtml, there isn't much left in the CMS that can't be quickly overridden.  Yes, it adds burden to template designers, but it's a fair tradeoff if you want total control of your markup and what dependencies you want to use in your template.

[Seth Warburton]

+1000 Matt. These assets should absolutely not be loaded if they are not required. 

In the case of contact layouts, for example, I believe (as these are presentational layer items) their method of implementation should be controlled from within the template. We can then have the elegant scenario where, though Protostar may require JS to display contact sliders or tabs, Beez (for example) does not and users seeking a JS free front-end can then simply make a choice appropriate to their requirements. This provides a best-of-both worlds approach and leaves the end user free to decide.

I understand, of course, that it isn't the case at the moment but both tabs and sliders can be implemented solely with css. It's my opinion that this is something that should be done at the template level though, with the core simply outputting a unordered list of contacts with a couple of extra divs thrown in to implement sliders/divs. In this scenario, even with both JS and css disabled the front-end gets a list of contacts.

Similarly, there's no real reason why basic front-end editing cannot work without JS. Expecting a full WYSIWYG is out of the question of course, but I think any user could understand this: 

.has-js? --> Bell & whistles. .no-js? --> Basic functionality.

What users will never understand is this:

.no-js (thing that I never heard of) ---> Totally broken.

Providing a fall-back, .no-js, scenarios isn't simply about catering for users who may have JS disabled (or who may not be able to choose), it's also about building robustness. Any script error on a site (even from an external source) can break a site, dropping it into a .no-js state, this is almost inevitable. Planning for inevitable script failures, and allowing functionality to adopt a graceful fall-back makes us good developers. 

Not planning for .no-js events gives the impression we're bad developers who would rather blame end users than question our own false assumptions.

Personally, I'd like to see full functionality (including basic editing) on the front-end with JS disabled. It's certainly possible and it would provide a rock-solid base from which to progressively enhance with Bells+Whistles as may be required. Nothing would be lost and we'd never have to blame a user's broken site on their own browser settings.

Best regards,

Seth

 

On Saturday, 16 February 2013 11:38:56 UTC, Matt Thomas wrote:

[Seth Warburton]

Completely agree. Though I would go further and say that 100% of *basic* functionality on the front-end should operate without JS. 

It's long been troubling me that something so simple as article print/e-mail links, for example, requires JS in J3. I find that impossible to reconcile with user requirements.

Best,

Seth

[Ove]

@Seth Warburton

Back to the old days then? You forgot 3.d Party extensions. --- Dear
developer load any JS library you find nice? For your component, for
your modules and for your plug-ins. You can't be sure what or if Joomla
loads any JS. ---

Template developers will not be able to support every extension at the
level you suggest.
Quote "that this is something that should be done at the template level

though, with the core simply outputting a unordered list of contacts"

And the very majority of (private) users are not able to modify an
output-php. i.e. the developer has to present "THE" solution.

I have though nothing against parameters turning JS on or off on any
level - system, template, extension. In future for parts of a JS
library. But please standardised!


Ove

[Seth Warburton]

Trying to ensure Joomla's core front-end functions are never broken is not 'a return to the old days'.

I've not forgotten 3rd party extensions, if an asset is needed, load it. It's in everyone's best interest to have some fall-back planning though. 3rd party developers are free to think about that or not.

And, in the cases of the examples discussed here, contacts, front-end editing, etc. Javascript shouldn't be required. Filling in and submitting a form does not inherently require Javascript, to require it simply adds fragility to the system.

"Template developers will not be able to support every extension at the 

level you suggest. "

I've suggested no such thing. 

It is unreasonable to expect that a complex 3rd-party extension (e-commerce, subscriptions, whatever) will function without JS, but it is not unreasonable to expect to be able to use the print/email links or a simple contact form.

Best,

Seth

[JM Simonet]

Concening Email and Print, as far as I know, there are ways in html5 and CSS3 to create modals without JS, including the Close functionnality.

There is no way though to replace window.print, but it could be gracefully degraded to replace the code when no js to advise the user to use his Browser print window.

The issue is less obstrusive in Beez3 as we do not have the Protostar dropdown to display these functions.

I tried unsuccessfully to force single contact display to use back-end params when JS was on and display as "plain" when not.

Patches welcome.

JM

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[elin]

Incidentally in the reusable layouts feature that people need to test so it can be merged  the icon block is one of the reusable layouts so a templater can easily handle those as desired (not to mention that we can pop them into the other components easily). One of the reasons that was an early focus was to address the issues with the boot strap icons being hard to override. 

I kind of feel people know how to use their browser to print so if we have a raw pop up and they don't have access to our print icon I think they are okay. 

I guess also that in terms of the edior-xtd buttons that if you really want no bells and whistles you have editor:none and you type html including <img> and <hr> tags.    

Elin

[Angie Radtke]

>
> 1. BACKEND
> We know JS is compulsory in back-end. Nothing would work without JS
> enabled in the browser, whether for Isis or Hathor.
> My question here will therefore be:
> Shall we now use addPanel in backend instead of the complex way tabs
> are now created?
> It would show the best use of bootstrap to developers and make our
> code leaner.

Hi Jm

I tested your patch and I think this solution is cleaner. Both are not
working without js enabled.
#
Case disabled JS:

The difference is that the solution we have now is showing the tabs-ul,
but we can't use them. In your new solution the tabs will not be
displayed, so this more consequent, because they can't be used. .-)


bye Angie

[Seth Warburton]

I kind of feel people know how to use their browser to print so if we have a raw pop up and they don't have access to our print icon I think they are okay. 

Agreed, I don't really see much of a use case for maintaining either option now, as I think they are far less relevant than they once might have been. Having un-usable buttons is poor UX though. In UX terms, it would be best to have no links without JS than to have a button that doesn't work.

 

I guess also that in terms of the edior-xtd buttons that if you really want no bells and whistles you have editor:none and you type html including <img> and <hr> tags.

I always use editor:none, front and back, there's no issue there. The issue is that the save and cancel buttons don't work without JS.

Best, 

Seth