This page is to discuss & report ways how Tiki can work better in contexts where Javascript is not activated.

jQuery was added as an experimental feature of Tiki 3.0 and will become the default in 4.0 Tiki will have more & more javascript usage to improve user experience. Ideally, Tiki has a graceful fallback for when Javascript is not available. It is expected that look & feel won't be as nice, but we should strive to make it work. To test, use NoScript

Todo

1. Toolbar & Smileys rely on JS, so should not appear
   • Help should continue to be shown at bottom of page (like in 3.0)
2. Forms submitted by JS onchange event (e.g. theme switch) should always display submit button with at least "Go" when JS is off
   1. Done: theme switch shows "Switch" button when JS is off
3. profiles won't work

Enforcing JavaScript?

No

• accessibility
  • possible?
    • http://stackoverflow.com/q/21235312/2459703
    • http://stackoverflow.com/questions/21235312/accessibility-and-using-javascript
• barrier free websites
  • blind people
• machine readable sites and search engines
• legal obligations
• Tiki philosophy: make things optional
• respect the environment
• people might deactivate it or use noscript plugin (e.g. Firefox)
  • tracking of users, third party JavaScript are reasons for this behaviour
  • desktop ressources are wasted, powerusers with many browser windows and many tabs
• NGOs don't like it
• Tiki admin access should be easy
• usage of textbrowsers, e.g. lynx
• security, software bugs

Yes

• hinders progress and modernization of Tiki with features that are universally popular
• modern touchscreens and dropdown menus
• better functionality
• better user experience
• support AJAX and Tiki services
• javascript is a language not a feature - unusual to make entire languages optional
• burden on code and volunteer coders - more difficult to maintain and understand code
  • Results in significant duplication of code in some cases
• cost/benefit - benefit to small user set has not yet been proven to outweigh the cost
• wisdom of "stuck-in-time" approach to js issues is questionable and not accepted by many, including in the Tiki team
  • Other potential solutions not explored, and exploration is discouraged
  • Respect the environment which includes those who disagree with the "stuck-in-time" approach
• danger of making the most commonly used functions the most backwards - a significant overall negative for Tiki's appeal to users
  • May result since coders will be less likely to enhance or modernize with js-based enhancements in areas where js must be optional

Ruleset for coding (suggestion)

• Restrict optionality requirement to discreet actions where considered absolutely necessary
• Optionality only to be considered for most basic features and the most basic actions within those features
• Optionality not required in following areas (not an all-inclusive list):
  • Admin areas (i.e., anything requiring tiki_p_admin_xxx permission), Trackers, Perspectives (requires jQuery UI), Spreadsheets
• Basic features where optionality should be considered:
  • Wiki, File Gallery, Article, Blog, Forum
• Basic actions where js should be optional within the basic features:
  • Edit
  • Delete

Related

• Accessibility
• TemplateStylingProposals
• WebAccessibilityInitiative
• UX+Team