- Accessibility - Spiderability by search engines
If you want to say PE is dead please explain how these don't matter to most websites.
211–220 of 263 posts
- Accessibility - Spiderability by search engines
If you want to say PE is dead please explain how these don't matter to most websites.
Earlier quoted context omitted.
Today's reasonably-built JavaScript-based applications are built using HTML as templates. They don't use a as a button, they use a as a button. They don't invent navigation using JavaScript, they use tags and a JavaScript-based router. Take a look at discuss.emberjs.com, which uses Discourse (which is powered by Ember... INCEPTION): On the front page, every navigation, including the links on top and the links to indi…
Using as a button? Enjoy your form submission when it's inside a form element. HTML is the most frustrating thing in the universe.
This post does nothing to address the biggest reason people might have Javascript disabled: security. If I'm browsing through Tor (or whatever), I'm not going to turn on Javascript to use your site. If your site doesn't work without it, you've lost a customer. Granted, people who disable javascript are obviously vastly outnumbered, but just saying "fuck you" to security conscious (and most likely tech-savvy) users se…
1. Stop preventing middle and right clicks on JavaScript enabled links. For left clicks, sure ... control the flow.
2. Respect the fact that this is NOT a desktop environment, therefore my view of your program's "screens" should be on a per URL basis. I actually might want to view a list you generated in my own separate "window" or "screen" with the URL visible, usable, and savable in the browser.
Not a single mention of SEO on the article. I guess Google is dead too.
Try viewing meta.discourse.org without Javascript on then look under the hood - it's a pretty easy problem to solve with some tags. Other approaches use PhantomJS to create a "rendered" copy that is accessible to primitive clients/scrapers.
Then your site does not require client-side JS support.
The point is not about what technologies you use to produce documents, the point is what data you [can] serve.
Some documents, especially those using Ajax for loading content or multiple pages, make this difficult. I hate them. (Hacker News, oddly, does it too - when a discussion is archived, it becomes paged, which makes it more complicated to store.)
I wish there would be a standard way to store page offline, including all the JS changes made to its looks, all the external content etc.
Lots of absolute views in this thread. How about: If it's profitable for your site to offer a non-JS fallback, do it. If it isn't, don't.
If you don't pay that tax, you're personally contributing to a future when simple documents become full-fledged programs, and everyone lose abilities to easily manipulate and interact with them in any but author-defined ways.
There are cases where you can be exempt from that tax - if your site is not about documents, but their transformations, i.e. it's more of a process, not data. (Then you should call it app, not site). But vast majority of sites isn't.
Earlier quoted context omitted.
"99.99% of the people visiting my site have JS enabled" Do you know that for a FACT, or are you just guessing?
To add to this, generally most user data collected is through javascript. If you don't have javascript enabled...