#25964 closed defect (bug) (fixed)
Appearance Themes: find a way to provide a no-js fallback
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.8 | Priority: | highest omg bbq |
Severity: | blocker | Version: | 3.8 |
Component: | Customize | Keywords: | |
Focuses: | Cc: |
Description
Right now all the views are rendered with wp.Backbone. We need to provide a functioning experience for no-js scenarios in a way that doesn't burden the normal experience excessively, nor breaks the advantage of having live views.
Attachments (1)
Change History (12)
#4
@
11 years ago
- Priority changed from high to highest omg bbq
- Severity changed from normal to blocker
- Type changed from enhancement to defect (bug)
#5
@
11 years ago
NB: <noscript>
won't suffice, because we also have to take into consideration a JS error making it such that you can't change your theme (and what if the JS error is from the theme?). Recommended approach is to do an initial PHP render, then have Backbone take over and re-render on top (resulting in no visual changes, if done right). I'm okay with Search not being done with PHP. Just the initial list of themes with the Activate buttons available should suffice.
#6
@
11 years ago
possible nojs solution, uses themes.php from 3.7.1: 25964.diff
- include a copy of themes.php from WordPress 3.7.1 renamed as themes-no-js and includes removed
- include this file wrapped in a div in new themes.php
- add JS to app startup that removes old page html from DOM
- tested a bit with js off seems to work fine, new HTML already wrapped in <script> tags so not displayed
#7
follow-up:
↓ 9
@
11 years ago
If there is a specific use case we want to support, like activating a theme that breaks JS and you can no longer deactivate it, perhaps we could constrain the no-js functionality to something small like that: Text listing of current theme and a deactivate link.
This ticket isn't the time or place to debate it, but it's interesting to think about where we draw the line functionally as wp-admin shifts to be basically a JS application passing data back and forth to PHP rather than HTML whether it's worth it to essentially write everything twice, or leave the existing legacy HTML interfaces as gradually every screen in wp-admin, and the majority of the admin codebase, becomes client-side javascript.
#8
@
11 years ago
- Owner set to nacin
- Status changed from new to accepted
I'm almost done with a patch here.
#9
in reply to:
↑ 7
@
11 years ago
Replying to matt:
If there is a specific use case we want to support, like activating a theme that breaks JS and you can no longer deactivate it, perhaps we could constrain the no-js functionality to something small like that: Text listing of current theme and a deactivate link.
This ticket isn't the time or place to debate it, but it's interesting to think about where we draw the line functionally as wp-admin shifts to be basically a JS application passing data back and forth to PHP rather than HTML whether it's worth it to essentially write everything twice, or leave the existing legacy HTML interfaces as gradually every screen in wp-admin, and the majority of the admin codebase, becomes client-side javascript.
Yea! I am all for switching the admin to primarily JS tied to a PHP backend and glad to hear you are thinking along the same lines! I can envision the day when the page never 'reloads' from the moment you hit the login screen. I agree we would be better off with nojs support of only the most basic, required features.
#11
@
11 years ago
Syncing this single 33-line template is going to be really easy. But, I see a point in the future where the same PHP file can be used as a PHP template and, with minor transformations done automatically, a Backbone template. At you can see, the syntax is nearly the same. If bracket notation was used instead of object notation in this Backbone template, it'd be even closer. Some kind of template sharing is a bit of a wheel reinvention, but it avoids us unnecessarily diving into new templating languages for the moment. For now, [26726] works as a graceful fallback. Maybe a shared template could work for more things along these lines. Just something to think about.
We've used a few different techniques when an entire legacy interface becomes JavaScript. We've left existing HTML interfaces (media), declared the whole thing a value-add you only get with JavaScript (revisions), and provided baseline behavior in no-JS mode (themes). This baseline behavior is also how the rest of WordPress already handles no-JS, and it was the clear best choice here, with the least amount of code and pain.
It appears that the only way we'll be able to do this is to render a similar output that the JS creates within a
<noscript>
tag.We may however want to investigate how screen readers and other accessibility tools access our new page, as we may want to create the no-js version as an accessibility mode instead which uses little JS.