Graceful Degradation vs. Progressive Enhancement
Starting from full JS functionality and making it degrade gracefully
We want to use the Progressive Enhancement approach.
- takes too long to load into the page
- difficult to debug
- hard to maintain/extend/refine
Basic observation: There are 4 different approaches at play in the code (confusing, hard to debug)
- Plugins – ie hydraMetadata
- Submission form currently requires ajax. Would require multiple submit buttons if ajax disabled.
- Fluid Framework is problematic
New Approach in Blacklight: (Jessie will follow up with more info)
What should be done?
- All features progressively enhanced
- Put code in consistent places
- Ensure Valid Markup!
- Section 508
- ... Julie will provide more reference info
Q: Where should you put the code that specifies which js to load for a particular page?
A: Hold off on that question. Wait and see what conventions come out of Libra.
Should we have a cucumber step definition for "And the html should be valid"?
This would rely on a network connection. Should keep that in a separate cucumber namespace.
Possibly define a single features/valid_html.feature that runs through all of the pages and runs the validity check...
Getting rid of Fluid Framework
This is revisiting an old topic. Yes we should get rid of all Fluid dependencies. They have already been removed from Libra. They should be removed from Hydrangea (and any other Hydra heads) in anticipation of the next Libra merge.
How will it be done?
Using Libra as a straw man for identifying conventions
- removed dependency on Fluid framework
- squashed bugs
- cleaned up html
- addressed some accessibility issues
Hydrus & Hypatia developers will
Meanwhile, work on a solution for Automated Testing of JS
John Scofield will proceed with setting up a solution for automated testing (HYDRA-276), trying out the solution described at http://robots.thoughtbot.com/post/1658763359/thoughtbot-and-the-holy-grail