I like the idea of having interface "skins", but I honestly could not tell this one apart from Bootstrap. I would love to see more varying interface styles, not another bootstrap clone.
I welcome the intent which I understand is to provide another point of view on css frameworks. Honestly like others, I am a little overwhelmed with multitude of css frameworks. I think the point was to have a framework to provide aggregation and organization of multiple tools you used previously.
For me Bootstrap, Zurb are currently only really interesting in a sense I would use them in projects. For a while I used Skeleton, I think it lost pace a little and I get same benefits with Zurb.
Again, I welcome your vision of organized front-end, would appreciate a page that would outline differences and specific benefits.
At this point, if your CSS framework doesn't start with "why we're different/better than Bootstrap" I'm pretty much out. I skimmed the docs and see very little here that isn't a direct "Bootstrap does that, we'll do that too".
I'm at risk of losing out if I have to go through 20 pages of documentation and compare line-for-line against Bootstrap rather than the creator going "we decided not to just re-skin Bootstrap primarily for reasons A, B, and C".
I'm going to reveal a big secret. I actually managed to find out the tidbit about IE 7 without reading it line by line.
Their primary job is not marketing. Their primary job is to build the framework.
Why do you think things like Y Combinator exists? They do some work others aren't willing to and others lose out because of it.
It's to the developer's benefit to tell you why his product is good, but it's not their duty. These guys worked on and released a free product for you. You can choose to use it if you want but they don't owe you anything or an explanation of why it's better than Bootstrap.
The immediate question that popped up when I first see their project's homepage is "How is it different from Bootstrap? Why should I use it?" I looked around and they don't offer an explanation, so I left and continue to use what I'm using.
The developers put reasonable efforts in building the website, introducing the project so that people will adopt it, so I think an article comparing their project with Bootstrap definitely helps with adoption.
Nowhere did I imply they had a duty to do so - just that it'd be to their benefit, because the people considering such a framework have dozens to choose from that all look alike. They presumably put it out there because they'd like people to use it.
IE7 was last updated over 3 years ago and doesn't even pass Acid2. Only 1.5% of internet users use IE7, and most of those are probably stuck there due to corporate governance rather than choice.
Like the other guy said, IE7 isn't that rare in Portugal. it's a sensible baseline for SAPO, which, incidentally, runs the biggest web portal in PT (I work there).
And yes, corporate governance regarding browsers does weigh in heavily in mass-market sites here, so we have to make sure the layouts don't break - Ink enables delivering a predictable, working layout that degrades gracefully down to IE7 for that reason.
Seriously now, yes, Bootstrap has always had forms. But as a developer who merely dabbles in design, I personally prefer Ink's markup because it's responsive off the bat (at least compared to BS 2.0, haven't tried 3.0).
Can we please come up with a better markup for form element grouping than "div.control-group"?
Specifically, HTML has always allowed nesting an <input> inside <label> - and that's more than enough to create either a horizontal or stacked layout. No <div>s needed. And no "for" attribute needed with an unnecessary input ID.
Sometimes introducing more markup can be better architecturally. I agree, .control-group isn't the nicest way of doing things but I don't think nesting an input inside a label is any better.
I do not see any disadvantages to nesting inputs inside labels - and it's actually quite semantic and maintainable (in part because inputs no longer need auto-generated IDs). This approach has been part of the HTML standard pretty much always, as well.
It doesn't matter much if forms are generated using a builder like Formtastic, etc. But even then less custom CSS classes is usually better. This way I have been able to write CSS for fairly complex forms using just standard tag selectors, with just one class on the root form container to separate multiple form styles.
When you put a label with text and the input inside, how would you get the text to take up 150px and the input to be to the right of that consistently across a large form? Such as here: https://www.roadreadycertified.com/order/begin/
Note: It's just an example, not promoting the site.
It's possible to do by adding a padding-right as well as position:relative on the label, and then position:absolute on the input to place it over the padded area.
Not the easiest CSS to write, but I strongly prefer clean markup (at a cost of hackish CSS) to hackish markup.
I don't really consider that cleaner markup... Now you have a single element containing a text now and another element that can not be transverse independently... As opposed to an e extra tag. You could do the label with a span and the input y though, and then mark your CSS that way as a convention... But then you aren't using a bad framework meant to have broader interoperability in mind.
To my knowledge this is incorrect. Assistive technologies don't recognize input names when nested inside of label elements, and as a result is frowned upon by the W3C. Unless you meant something else by, "...HTML has always allowed nesting an <input> inside <label>..."
The results on that page puzzle me for the nested input/label case - this is news to me. Given how browsers already forward focus for clicks on a label to the nested input, I always assumed that this takes care of programmatic association between label and input.
Maybe an aria-labelledby attribute would fix this? Heck, could still use a label "for" attribute and keep the input nested.
Either way, I meant that it is legal HTML to do that kind of nesting. Did not know that it was frowned upon, as far as standards are concerned, even assistive.
That's a fair point. Although div's are not completely necessary for this purpose from a functional perspective, the standard definitely allows one to understand/create the layout of the page more efficiently.
If everyone's wondering how Ink is different from Bootstrap, the answer is: mainly in how Ink builds layouts. Instead of the column span philosophy, Ink uses percentage based blocks. That alone is a big difference.
Don't forget to mention that although we as a default support 3 screen sizes, our grid system is configurable, so you can add or remove as many breakpoints for as many screens as necessary. All with a couple of lines of code.
One thing I like about this is that most of the class names are namespaced (as "ink-something"), unlike most of the other ui frameworks I've looked at. This makes it a lot simpler to integrate into an existing site without accidentally dealing with conflicting class names.
I like the colors and type of default theme of framework. It really looks neat. On the other hand, used markup looks less than Bootstrap. It definitely could be a selling point. Large screen concept and flexible columns also looks very good. I can give them a try.
On a unrelated note, how did this end up on as the musicbox website framework? I worked in this project a while ago (backend and frontend clients only) and had no idea who did the musicbox.sapo.pt frontend.
Well, IIRC Ink came about due to the need to quickly build out sites like that (you'll notice SAPO is involved in a bunch of other services like that), and things dovetailed together when the site was revised recently.
It feels to close to Bootstrap without bringing enough new stuff to the table to be worth it. It's nice to see people making alternatives, but it needs to be a lot more developed.
Well, like I said above, it addresses some internal issues my colleagues had. It also tries to make a lot of things simpler for web designers (especially regarding the grid system) without tying you down too much.
I may give this a shot. The way they manage columns without needing to specify the number of columns in a div seems nice.
For instance, if I want a two column layout, I put two divs inside the '.column-group' container. Now (theoretically) if I were to dynamically add a third column, it seems that Ink would automatically adjust the other two columns to fit.
With bootstrap, I would need to change the '.spanx' of each div within the '.row'
At first I thought the filepicker.io folks, who recently rebranded as Ink, had released a UI kit.
Of course they don't own those 3 letters which have a wide array of meaning, similar to words like "bootstrap", "ember", "buffer", or "backbone". I'd be hesitant to use those words in a product, open source or otherwise, however.
As someone who hasn't integrated Bootstrapped before, I have a clean slate to evaluate and use any interface kit that comes along. As long as it's more comprehensive that what's currently out there, it doesn't matter so much to me how much more of an improvement this latest project is over the prior standard.
Although it looks a lot like Bootstrap, the code is very different. For one thing they really do use LESS. The code is full of variables and mixins, much more than Bootstrap. The custom Javascript Core is interesting too.
Now just hesitating because of the end CSS size. 160KB minified is nearly twice the size of Bootstrap.
I think this is cool, so I say good job on that front. But I kind of feel like you're trying to introduce yet another low end sedan. There's already hundreds, and I've already purchased one. It's gonna take at least a few more years for me to be ready to shop for a new one.
Well, we're not actually selling, but rather giving it away :)
Seriously now, it's been in internal use for a good while because it solved problems that Bootstrap didn't address (like the particular grid flavour and some corner cases in responsive layouts), and the best way gather feedback and improve it is, of course, making it public.
It's a technical debt metaphor. Myself and the company I work for have all learned the caveats of bootstrap and how to hack through them. Now it's happily sitting in most, if not all, of our projects. It just doesn't make sense for us to change at this point.
http://ink.sapo.pt/icons#nav-textedit The link for Text Editor Icons is broken because the id for that section is set to nav-web. A copy-paste error most likely.
The icon collection is worth a look for any web project.
It's an icon font, so colours and scaling can just be done with css.
Very easily integrable with Bootstrap as well, just include the css after the Bootstrap css and it works. (All you might have to test is icons that are a different colour now since they just use the font colour)
http://fortawesome.github.io/Font-Awesome/examples/
