I searched for "layout" and found nothing. These are not docs I always wish I had.
InstaCSS: the CSS docs you always wish you had
81–90 of 93 posts
Re: InstaCSS: the CSS docs you always wish you had
#82Hey there, creator of instacss here. Thanks for all the feedback! I posted this as a Show HN last week, but it's nice to see that someone has re-discovered it: http://news.ycombinator.com/item?id=3222253 . Since then I've added a few features, one of which being the ability to have permalinks so that you could use it as a google chrome search. This is why I push to the url bar as you type. I'm really open to feedback…
Just add a short delay between the keypress & the search/url push, and add a check to see if the query is the same. If after a ~second or so the query is the same, do the search and update the URL.
I'd use underscore.js's _.debounce method, simples!
Re: InstaCSS: the CSS docs you always wish you had
#83Any chance of getting it to apply the filter on page load as well? It appears that it's not possible to link to a result set. i.e., if I send someone a link to http://instacss.com/#background in order for results to be shown they must perform a keypress of some sort in the search field.
edit: Apparently if you've searched something before it does display it on page load (after a brief delay)? So it seems this link might not be a good example URL. But hopefully you can just edit the URL and submit it directly to see what I'm talking about.
Re: InstaCSS: the CSS docs you always wish you had
#84Earlier quoted context omitted.
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.
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 se…
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`.
document.getElementsByTagName('html')[0].className += ' js'
.js #search-results { display:none; }
Re: InstaCSS: the CSS docs you always wish you had
#85Oh 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.
sigh
Re: InstaCSS: the CSS docs you always wish you had
#86Earlier quoted context omitted.
Screen readers support Javascript-enabled browsers these days.
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 jus…
> 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.
Re: InstaCSS: the CSS docs you always wish you had
#87Earlier quoted context omitted.
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 jus…
> 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 dece…
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 :)
Re: InstaCSS: the CSS docs you always wish you had
#88I can't take this seriously when it beings like this: "gimmeh teh CSS docs."
Re: InstaCSS: the CSS docs you always wish you had
#89Earlier quoted context omitted.
> 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 dece…
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.)
Re: InstaCSS: the CSS docs you always wish you had
#90Nice! It's great that it has detailed version support info, like: *Support for multiple, comma-separated, background images was added in Gecko 1.9.2.* but I wish it showed what fraction of web users that represents. Maybe with a little green/red fuel gauge icon.
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.