gistfile1.md

Preferential ordering of server and browser capabilities to determine if client- side routing should happen and enhance an application's user experience.

Format: (app has capable server) && (browser has pushState) => (should route)

1. server && html5 //=> routes
2. server && !html5 //=> !routes
3. !server && html //=> routes
4. !server && !html5 //=> routes

Note: When the application has a server capable of servicing requests, but the browser does not have the HTML5 History APIs (pushState); then the app should degrade to let the server handle all full-page requests.

Names for a flag on Y.App that denotes that the application has a server-side component that is capable of handling HTTP requests. The default will be to assume the developer is a good developer and their client-side application can gracefully degrade to sending all full-page requests to the server.

Possible candidates, format: (name): (default)

• degradable: true
• isDegradable: true
• degrades: true
• canDegrade: true
• hasServer: true
• clientOnly: false
• Others??

• selfServe: true
• serverRoutes: true / serverRouting: true
• serverCanRoute: true

I'll add more if I can think of any...

+1 for serverRouting, selfServe is a bit silly.

I like serverRouting too, it makes the attribute feel both like it is configurable and describes the server's capabilities. Even if the server is capable of routing, the developer can choose to turn it off and have URLs degrade to hash-based in non-HTML5 browsers.