Just a small accessibility thing: having inputs with placeholder text is great, but screenreaders have not caught up with the times and you should still use a corresponding <label> tag.
Agreed. If people insist on "styling" with placeholders as labels, they should at least include <labels> that are hidden visually but accessible by screenreaders.
It also results in ugly rendering issues with browsers that save previously submitted form data, overlaying it on top of the placeholder text or replacing it even if it's the wrong data for that field type.
The issue is that the placeholder text disappears once you start typing into it. The usability assumption is that once you start typing in a value you no longer need the placeholder, but that is a bad assumption, particularly if a mistake is made as the gp is alluding to.
Also, just as a general user experience thing, not having labels can be detrimental if the field's purpose is forgotten or unknown. Having a placeholder is fine if there is no value in the field, but if I submit a long form after filling it out, only to be shown an error, what if I don't remember what that particular field was for?
Has anyone done any studies on what % of web users use/need screensreaders? Supporting such technologies can be quite cumbersome. Also, is screenreader support mandated or addressed under the Americans With Disabilities Act?
Hey guys - I'm one of the core developers of Pure. Happy to answer your questions. We officially haven't launched yet, but glad that you guys are checking it out.
One thing a lot of these projects miss: have a page or section explaining your unique benefits. Make direct comparisons to Bootstrap, Foundation, or other known frameworks and mention how your philosophy, approach, or feature set is different. I was having a hard time figuring out where to put Pure in the universe of CSS frameworks.
I would normally agree with you, but not in this case. My first thoughts after arriving at the landing page were "small" (a few Kb) and "web" (no app-like widgets like dialogs). That's really all I needed to know, the rest really is in the details.
I think this sits in a unique place, as earlier alluded to, similar to Skeleton.
Bootstrap is a large framework for application development, but perhaps you want to hand-roll most of the visual components. Bootstrap isn't very well suited to this, as it is so extensive that building from the ground up (instead of "extending") is a bit difficult to do. Sure, you can modify some of its parts and pieces fairly easily using the variables, etc, but in general, Bootstrap is Bootstrap. Pure, as it mentions on the page, builds on Normalize and gives you some much more basic pieces to work with. I would imagine this would be used by a lot of people who are doing less "app"-like experiences, and are instead leaning more towards layout-driven, brand-heavy "website"-like experiences.
I have a critique, which is your naming convention for classes. This sentence from your site highlights the issue:
'Consider pure-g to be a row or "grid", and pure-u-- to be columns, or "units"'
First, I'm not a fan of the "pure-" prefix. If I were to use your system I'd use it exclusively. An option to either specify or ditch the prefixes would be lovely.
Second, in that sentence you say "consider pure-g to be a row". Why not just call it a row? I understand Bootstrap has used that already, but there's no copyright and it's a convention everyone is used to.
The default prefix is there for maintainability. It's a pain to grep for "grid", "row", or "g" when you need to change something. But if you don't like it, you can build your own.
One good thing about vendor prefixes: easier to "refactor" one's code-base, as in: remove/replace the framework in the future when it is inevitably obsoleted / abandoned, as time marches on and other choices become more agreeable. (Great that all things web evolve so fast, but at the same time somewhat painful to keep on top of things.)
Another benefit to prefixing everything is that it makes possible an automated module selection/build system. Point it at your markup/codebase and it would select only the modules that your site uses.
I don't think Pure is big enough to warrant this, but Bootstrap sure could use it.
It won't make a difference if you use the library correctly. You're supposed to use a framework like sass or stylus and @extend from the grid classes. Don't actually give your elements classes from the lib. This is a rookie mistake I see happening with bootstrap, grid 960, etc..
For what it's worth, I really think this is great. Some questions:
By appearances this is part of YUI. What's the relationship between this project and YUI3? Will this be taking the place of YUI's css grid system? What's Yahoo's involvement in the project (stupid question, maybe, but I'm not so familiar with YUI and am curious about at what level the project is controlled by Yahoo, and to what extent its progress is community-driven)?
- Pure is not a part of the YUI Library itself, but works well with it. (See http://yeti.cx for another example of this kind of peer project built by our team.)
- Our main project, YUI Library, has a well-defined Contributor Model that makes it clear that it's a community project, not just an open-sourced chunk of code reserved for Yahoos to work on. While there isn't one adapted to Pure yet, reading YUI Library's Model will give you an idea about what kind of community involvement our team desires:
"[YUI Library] is a meritocratic, consensus-based community project. Anyone with an interest in the project can join the community, contribute to the project design and participate in technical decisions. This document describes how that participation takes place and how to set about earning merit within the project community."
It's worth mentioning that YUI has changed a lot with regards to the community involvement. There are non-Yahoo! members of YUI that review a lot of the code that lands in the library. And I'm betting we'll see more community members with commit access very soon. YUI has totally transitioned from a pure Yahoo! project to being very much community driven.
This particular project looks a lot like a fork of the CSS components of YUI. We'll have to see what direction it takes.
I've just spent the last week building a simple bookmark app (front-end and back-end) with both Foundation and Bootstrap, with the goal of getting very familiar with both of them.
In that context, Pure looks great, congratulations.
IMO the goal of these frameworks should be to enable the use of most common design patterns, while normalizing across browsers and enabling responsive design.
We used to write our own JS for these patterns (tabs, navigation etc) and then JQuery made that easier. Now these frameworks are going one step further and giving us these patterns ready-to-go. My only suggestion would be to ensure that the most common design patterns are handled by your framework.
(Based on my experience, a suggestion that would be nice to have. For reference, its the design pattern behind the menu system that Wordpress uses: a nice "menu" list as a sidebar, like on your site, that allows flyouts or accordion style behavior.)
Thanks for the feedback. Right now, Pure just handles CSS, but I've been thinking about adding some JS to add some interactivity. The fly-out menu is a good example of that. That should be up soon - probably as an example, similar to the dropdown menu.
Fantastic work with this, really. Tiny file size, yet still has all the features I need. Completely unopinionated which gives an awesome blank slate to build off of, yet at the same time looks beautiful on its own with no additional styles. I love it.
It feels like a CSS toolkit to build "flat designs", where Bootstrap forces a ton of gradients, shadows, and bevels in a lot of its base styles. Of course, you could build something of your own with less-flat design using this toolkit, which is what makes it so nice.
On the contrary, I think it's small enough that you can pull in everything. I think with larger frameworks like Bootstrap, you have to be more careful and only pick what you need.
Because hover effects benefit the other half that have pointing devices. As long as the hover effects aren't compromising the experience for touch users, why not benefit the pointing device users?
Everything looks good so far but one thing. The tables.
Unless I'm missing something here, they don't seem to be responsive. At least, in a practical sense, when dealing with larger sets of data resulting in larger tables. This is one thing I have struggled with myself, so I was wondering if you guys had any plans for that? Thanks
Bootstrap lets you pull down 1 CSS file and has a very opinionated design. It's not that easy to over-write its styles. The entire bootstrap.css minified is around 80kb, IIRC.
Pure is less than 15kb minified (< 5kb minified + gzipped). It's meant to be a starting point for your application's styles, taking care of all the hard stuff, like aligning forms, making buttons look consistent, having a common CSS base, etc. From here on, you can write your own application styles to make your app look pretty.
In the end, you end up using a lot less CSS to achieve a similar effect. in the end, they are different products. You can use Bootstrap and Pure together too (see the Extend page for an example).
Unfortunately, since it doesn't use any css preprocessor, it is impossible to create a semantic stylesheet. Now-days I would not consider any css framework that doesn't let me separate the presentation layer from the markup.
I realize this is meant to be a very lightweight framework, but in order to be usable it has to have the possibility to be extended easily without spawning classes everywhere.
Oh snap. Good point... but it really isn't that hard to just create a .less sheet, copy the styles into it and then compile that with your overrides and new classes. I have built a responsive template boilerplate with LESS on top of the html5 boilerplate using this method. Really not an issue to just add the CSS compiler or pre-processor of your choice. I do think it could be would be a viable core option for the Pure solution to offer a CSS interpreter option.
I'm pretty sure the HN reader uses the Android webview [1] to render all webpages, which is the same thing that is used in the Android Browser. Chrome Mobile is not available for download on devices before Android 4.0, and didn't become the default browser on Android until 4.2.
According to these stats [2], Android Browser has about 55x the usage of Chrome Mobile as of April 2013. This means ~97% of Android devices will likely show up as they do in my screenshot.
In short, the problem is not with my HN reader, the problem is with this CSS library on the most common Android browser.
Interesting. So I re-installed HN2 to see if I can recreate your problem, I couldn't. It works fine. And it works fine under chrome too. I also tried the Android stock browser, works fine too.
I am using SG-S3 for what its worth.
Most likely the whole css wasn't loaded completely. Could you retry couple of times to see if it happens again?
It doesn't happen every time. It happened for me for the first few pages that loaded (as I was clicking through the overlaid menu). Then it went away for a few pages, then it came back. In other words, there was no rhyme or reason, even after everything should have been cached, it would randomly happen. Usually the kind of thing you see when there's a race condition in the javascript.
It's Android's WebView [1], which is used in all apps that render web pages and also in the Android Browser, still in use on the vast majority of Android phones (see my other comment in this thread).
Why do all CSS frameworks feel like they need to mimic Foundation/bootstrap so much? Things like colour scheme, form elements and typography are all so similar.
Personally if I'm looking for an alternative to Bootstrap, these are the things I'll be looking at.
Please expand, how would you see fit a framework that isn't like the rest? I'd love to know. Personally I don't see a lot of room for innovation in design. The early 2000s had its table-based designs, and micro designs with small bitmap fonts.. that only appealed to a niche audience. Websites then were much less accessible and had horrible UX. In today's modern design, you're either flat (Foundation, etc.) or you're Bootstrap. If Yahoo didn't mimic the aesthetics of the most popular frameworks, people would complain about it being too different, and it would not gain wide-spread adoption.
It may need a bit of adjustment, but the homepage looks clear enough. It's a lightweight framework on top of which to build your own style. Bootstrap is for quick prototyping with an opinionated design. Pure is a lot more like Foundation, but much much lighter.
And as someone else mentioned, it's a very young framework (literally a couple of days old) that can still take any direction.
Because the 'skin' of the base components is not the problem most of these frameworks are trying to solve.
This framework seems to have very little to do with the look and feel you are after. Hence it's light filesize, and it's advocacy for a less opinionated style.
"...provides layout and styling for native HTML elements, plus the most common UI components. It's what you need, without the cruft."
"...minimal styles and encourages you to write your application styles on top of it. It's designed to get out of your way and makes it easy to override styles."
Bootstrap on the other hand, has a fairly opinionated design. That is to say, it does a lot of the 'look and feel' for you, and overriding those styles to create your own skin takes a fair amount of work. Pure seems to aim at making a uniform base of elements, without designing a lot of the skin... encouraging you to extend base classes more than trying to override them. And I applaud these types of frameworks.
Lastly, IMHO the solution for grid systems is different in many of these frameworks, and a lot of it comes down to personal preference and your project's requirements. This is a pretty big differentiation point for some people. Many frameworks have opinionated grid systems -- box-sizing: border-box, fluid vs. adaptive, first/last class names required on columns within a row, etc.
Speaking of class-naming, has anybody come up with a good naming-scheme for classes used to add padding (or margins) to elements?
Sometimes I've create things like this: .pad_10_5_20_10 to avoid having to declare each one separately, but I'm sure there's a more-elegant way to do it. Of course, I can always define that padding directly in a more-generic class-name like .sidebar .... but there are cases where a pad class is more-desirable.
There is too much options [0] and it's more flexible than it should be. I know , it sounds weird but with bootstrap all you have is 12 columns and when you have less options it's easy to plan.
Maybe the other problem is : Units are not in multiplies of 5 and that forces you unnecessarily to think. If it would be in fixed units like bootstrap or in multiplies of 5 ( pure-u-3-25 etc.) i would be less thinking while deciding the length of some div.
The idea is that you can combine columns of different sizes. If you want a column of 1/3 of the width and another of 2/3, then you just need to add pure-u-1-3 and pure-u-2-3. Maybe you're right and the "u" is unnecessary.
I tried to do something different with Pure. The main motivation for me was to have a small CSS framework that isn't cookie-cutter. Most sites that use Bootstrap pull in 100kb+ of CSS (minified). Pure is less than 5kb.
I love Bootstrap but it's a pain to build on top of it, because it's so opinionated in its design.
I agree that there is this sort of "cookie-cutter" style website being created all over the Internet because of Bootstrap. While I do love Bootstrap, I'll give this a go due to it's appearance to be an unobtrusive take on an HTML framework.
Not sure that 100k vs 5k is that important. Look at any major site out there. You'll find 10-17 bolt on JS widgets being loaded (i.e. Fb or G+ buttons) and tons of other JS dependencies.
I'm a fan of making things smaller and use GWT to compile and compress versions of sites for each browser and format to achieve the bare minimum, but starting out at the CSS lib might be premature optimization give that it's not where most of the fat is. Plus, next to no site is going to use just that lib and their CSS will surely grow well in excess of that 5k.
Foundation is not much different from bootstrap on the surface; yet there are use cases where foundation works alot better than bootstrap and vice versa. Diversity is good bootstrap is fast headed to becoming a mono-culture in html/css prototyping. Pure is still a very young framework and might yet end up targeting a different use case than bootstrap does.
Thin font weights, dark gray text on dark background, light gray text on white background... Are they trying to make it unreadable to sight-impaired readers/developers? I cannot be the single one out there having had a bad sight...
I'll look into this. I don't want to add 'px' rules and don't really want to hack on the core, so let me see what I can do. thanks for bringing it up. Could you file an issue?
I feel it's a little disingenuous to use a commercial typeface in an open source project. Why not switch to something people can use without a Typekit account?
Great work! I've been looking for something like this to replace my overly complex bootstrap setup.
One thing that I'd like to see is a gutter-based grid system. In your grid examples the inner elements take care of the padding so we end up with weird padding on the left and right.
You're right - this is something that I've been meaning to look in to as well, just to remove the need for more DOM elements. I also want to add offsets in.
Looks nice, although as someone who has a dark desktop (inverted colors), people need to remember to set input backgrounds to white if they are styling the border, box-shadow, etc for a white input box. The form input elements look hideous for me.
Looks great. More competition and options are always a good thing. It'll be fun to see how long pure can keep it's thin figure. Frameworks as with people inevitably seem to fatten up with age.
Looks really nice, and the HTML appears well formed at a glance. I might consider using it in an upcoming project. A few reservations, though:
- JavaScript dropdown menus. Is it not possible to get a pure CSS (get it?) solution? Without JavaScript the menu collapses into a bullet list. I understand that CSS dropdowns are slightly less responsive, but a graceful fallback would be nice.
- Buttons have no :active styling (really minor, I know). This sort of stood out to me as odd, since most default button styles have one.
Love the idea of display modularization. Bootstrap and Foundation are two alternatives but I definitely don't think that they are an end all solution. There is a distinct advantage to developing your own core set of modules that are portable across your selected platforms and projects. I am glad to see more developers going this approach and am sure this will be a great addition to the growing list of responsive solutions. Thanks for sharing.
IMHO, those grouped inputs are a very bad idea. You can only use them on a handful of items at the same time or it looks completely unusable and if you have only a handful of items, grouping them makes no sense in the first place. So - nice technical solution, not really useful in the real world.
This is beautiful - I strongly recommend increasing the text contrast. I'm on a Macbook Air and I can hardly see the form labels and subheaders, so I despair for anyone on a shitty old screen etc.
The naming conventions are a bit strange. I'm used to bootstrap and others that have similar namig conventions. Still a nice framework. Will try it out.
The only impressive example is the email one, which didn't have a lot of default components, all other examples are things easily done with other frameworks.
