Live data from Hacker News

Ink – Interface Kit

ink.sapo.pt

71–73 of 73 posts

Re: Ink – Interface Kit

#71

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.

Re: Ink – Interface Kit

#72

Can we please come up with a better markup for form element grouping than "div.control-group"? Specifically, HTML has always allowed nesting an inside - and that's more than enough to create either a horizontal or stacked layout. No s needed. And no "for" attribute needed with an unnecessary input ID.

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 inside ..." Source: http://www.w3.org/TR/WCAG20-TECHS/F68.html

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.

Re: Ink – Interface Kit

#73

Earlier quoted context omitted.

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.
Post reply on HN