Edit: ugh, that doesn't actually work. It only gives you p-z. Hey instacss! Please provide us with a link to the actual document. Preferably in plain HTML so we can download it. Alternately, anybody care to scrape this thing and post it in full?
Hey, pretty cool but you should have a delay between when the user types something and when the url gets updated and a query gets made. i.e. some sort of definition of "user stopped typing". This improves usability by a ton.
Second is, maybe you should have a sidebar on the right that shows you clickable / keyboard navigatable titles of all the search results so I don't have to scroll down browsing.
I typed "^color$" and it wreaked havoc on my page history. Usually, I open the story in the same window then hit the back button to see the comments. This time it took me handful clicks before I get to my previous page.
Oh look, it's another site that loads nothing with JavaScript off. What is wrong with you? Progressively enhance, or gracefully degrade, or display something other than a completely blank page to non-JavaScript visitors. I harbor many doubts re: your competence in the realm of usability.
"Doesn't function right without JavaScript" disabled rates a shrug - JS enables lots of cool stuff. "Displays a completely blank page without JavaScript" is - well, in this case, as others have pointed out, one of the tradeoffs made in pursuit of a 24-hour project. However, in a mature site (I'm looking at certain MSDN blogs), it's very disturbing, it's a big warning flag for "lack of attention to detail."
My reactions to broken-without-JS sites spring from security, privacy, usability, and accessibility concerns. "Sites that completely break without JS" is a category that strongly correlates with "sites that have major issues in at least one of those four categories."
Except that most sites don't care about providing decent clues (correct mark-up, ARIA attributes, etc) for javascript interactions, so that's also a poor argument.
I admit I'm atypical here, but I do all my development work in emacs, and it's nice to have reference material that can also be accessed through emacs.
There is something wrong - in many countries you are mandated by law to make your site accessible :)
Of course this doesn't apply here, but I wanted to be dramatic. Should be piece of cake to just show the full content if javascript is off, since it is already loading all of it.
Accessibility is not just about screen-readers. There are hundreds of mobile browsers, consoles and a myriad of other devices with zero to broken javascript support. And even in screen-readers that do support JS, most interactions are broken unless you use proper mark-up and manage page focus and keyboard shortcuts.
The point is that it's trivial to make a site like this usable without JS, with little effort. You just have to start with the right mindset.
> There are hundreds of mobile browsers, consoles and a myriad of other devices with zero to broken javascript support.
These days, both of the major mobile browsers use WebKit and have great JavaScript support, though they may not support bleeding-edge browser functionality quite yet (for which all non-demo sites definitely need fallbacks). The unofficial mobile browsers have great JavaScript too. Consoles have decent browsers with decent JavaScript, and in any case not all sites need to expect console browsers as a remotely common case.
You have to draw the line somewhere, and not all sites need to support Lynx, Links, or Mosaic. I certainly agree that having decent fallbacks for a site like this doesn't require that much effort, but not all functionality supports graceful degradation.
These days, browsing without JavaScript seems less likely to indicate an older browser, and more likely to indicate a user with JavaScript intentionally disabled using something like NoScript. That user may get righteously offended that a document would dare to run code on their system, but that doesn't necessarily make them right.
All web features tend to follow a three-step lifecycle: too new to use at all except for demos, stable enough to use with fallbacks for older browsers, universal enough to use without fallbacks. Depending on your site and your target audience, basic JavaScript may fall in the second or the third category.
You don't have to draw a line anywhere in cases like this. The technology is there that makes it perfectly possible to have at least basic text display on any client. The "major" mobile browsers with webkit represent only 20-30% of the global market.
Anyway, it's just a couple of extra lines of code, get over it :)
Again, that works just fine in cases like this. Though note that the solutions for this site require either server-side scripting or just completely disabling the search functionality.
However, many sites use more advanced JavaScript features which do not necessarily allow for graceful degradation.
(Also, most other mobile browsers of the type you allude to consist of barely more than WAP; only the simplest of non-interactive websites has any hope of working with them. And many sites simply won't have any of those users in their target audience.)
I can't reply to your last comment, so I'm going to to it here:
> The point is that it's trivial to make a site like this usable without JS, with little effort. You just have to start with the right mindset.
How are you supposed to make a instant search usable without JS?
If it doesn't need to be instant, just normal search with a nice GET /search?q=border, one would have to program a server side script to do that search.
Or maybe you'd just want to show the whole reference on the HTML, then the JS would have to use that to do the search and hide/show the appropriate div, or you'd have to load everything twice (once in the HTML body and again via ajax). Even then, what's the point? It's a instant search. If the user can't use the only feature of it, he's better off googling.
Is there other way that I'm missing? I don't see that as "trivial".
If you read the other parts of the thread, or check the source code, you'll see that the whole content is loaded at once. There are no further requests. It's all already there with `display:none`.
Yeah, how the OP dares to shows us a prototype of something that he probably hacked in a couple of hours and doesn't even support the very specific user that has JS disabled by default.
It would be nice if it sorted by relevance; i.e. a search for background would give you the definition of the background property first instead of the -webkit-background-composite property which is almost certainly less relevant (worse match, less used).
* Default to sort by relevence: Put the more relevant matching properties at the top. For example, I type "backg" instead the highest result being the obscure "-webkit-background-composite" ... actually most relevant result "background" which should be the first result instead of the third.
* Default results list to condensed format: Instead of showing the full verbose docs for every matching result instead show a sparse summary of each result with a option to expand it. If there's only one matching result then show the complete doc for it
* Nice example palette for standard colors. How about an example palette for the standard font families?
In addition to the complaints about this flooding history, I expect the "background" style to appear first once I've typed "bac", and even with "background" there's some webkit thing first.
It would be nice to show something more useful on the front page before the user types anything into the search box. Like an index or a table of contents or so.
The OP said he's pulling the data from MDN (Mozilla Dev Network I think?), which means all the comments are only going to be Firefox-related. What I would want is for it to show all browsers and what version the feature is available in (but if he's automating the data pull, this probably isn't going to happen I imagine).
MDN has started improving that, and showing compatibility information for more than just Mozilla browsers. They already include full compatibility tables for some of the more frequently used features.
92 comments
[ 5.3 ms ] story [ 180 ms ] threadhttp://instacss.com/#a
Edit: ugh, that doesn't actually work. It only gives you p-z. Hey instacss! Please provide us with a link to the actual document. Preferably in plain HTML so we can download it. Alternately, anybody care to scrape this thing and post it in full?
Takes regular expressions as user input. Probably DOS'able.
After looking at it for a few seconds, I realised that it's doing the regex matching on the client side, so it's ok.
If you ever accept arbitrary regular expressions as user input, be very careful: https://www.owasp.org/index.php/Regular_expression_Denial_of...
Second is, maybe you should have a sidebar on the right that shows you clickable / keyboard navigatable titles of all the search results so I don't have to scroll down browsing.
There's got a be a more polite way to phrase that.
Also, while I understand the reasons for disabling JavaScript generally, is this really something to get that upset about?
My reactions to broken-without-JS sites spring from security, privacy, usability, and accessibility concerns. "Sites that completely break without JS" is a category that strongly correlates with "sites that have major issues in at least one of those four categories."
So there is nothing wrong with choosing to not support 2 out of every 100 users; that's simply a time/cost assessment. What's wrong with you?
[1] http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-...
[2] http://www.w3schools.com/browsers/browsers_stats.asp
It's OK to develop for your target audience, right?
Of course this doesn't apply here, but I wanted to be dramatic. Should be piece of cake to just show the full content if javascript is off, since it is already loading all of it.
The point is that it's trivial to make a site like this usable without JS, with little effort. You just have to start with the right mindset.
These days, both of the major mobile browsers use WebKit and have great JavaScript support, though they may not support bleeding-edge browser functionality quite yet (for which all non-demo sites definitely need fallbacks). The unofficial mobile browsers have great JavaScript too. Consoles have decent browsers with decent JavaScript, and in any case not all sites need to expect console browsers as a remotely common case.
You have to draw the line somewhere, and not all sites need to support Lynx, Links, or Mosaic. I certainly agree that having decent fallbacks for a site like this doesn't require that much effort, but not all functionality supports graceful degradation.
These days, browsing without JavaScript seems less likely to indicate an older browser, and more likely to indicate a user with JavaScript intentionally disabled using something like NoScript. That user may get righteously offended that a document would dare to run code on their system, but that doesn't necessarily make them right.
All web features tend to follow a three-step lifecycle: too new to use at all except for demos, stable enough to use with fallbacks for older browsers, universal enough to use without fallbacks. Depending on your site and your target audience, basic JavaScript may fall in the second or the third category.
Anyway, it's just a couple of extra lines of code, get over it :)
However, many sites use more advanced JavaScript features which do not necessarily allow for graceful degradation.
(Also, most other mobile browsers of the type you allude to consist of barely more than WAP; only the simplest of non-interactive websites has any hope of working with them. And many sites simply won't have any of those users in their target audience.)
> The point is that it's trivial to make a site like this usable without JS, with little effort. You just have to start with the right mindset.
How are you supposed to make a instant search usable without JS?
If it doesn't need to be instant, just normal search with a nice GET /search?q=border, one would have to program a server side script to do that search.
Or maybe you'd just want to show the whole reference on the HTML, then the JS would have to use that to do the search and hide/show the appropriate div, or you'd have to load everything twice (once in the HTML body and again via ajax). Even then, what's the point? It's a instant search. If the user can't use the only feature of it, he's better off googling.
Is there other way that I'm missing? I don't see that as "trivial".
Cut him some slack! I harbor many doubts re: your competence in the realm of friendliness.
* Default to sort by relevence: Put the more relevant matching properties at the top. For example, I type "backg" instead the highest result being the obscure "-webkit-background-composite" ... actually most relevant result "background" which should be the first result instead of the third.
* Default results list to condensed format: Instead of showing the full verbose docs for every matching result instead show a sparse summary of each result with a option to expand it. If there's only one matching result then show the complete doc for it
* Nice example palette for standard colors. How about an example palette for the standard font families?
I would also like it if the search box was in the fixed header, so I don't have to scroll back to the top to re-search.
Otherwise nice tool!
also - the automatic URL hashing of the query breaks the back button to a ridiculous degree.
cool content, bad design.