5 ms·
Its always good to have options. As much as I'm supportive of promoting your own work its a little bit in bad taste to smash and promote your project one a subm
by bnejad 12y ago
Its always good to have options. As much as I'm supportive of promoting your own work its a little bit in bad taste to smash and promote your project one a submission like this.
- owenversteeg 12y agoWhoops. I didn't mean it in a negative way - I was hoping that the creator could mention some other advantages of using Picnic.css that I missed. I've edited the comment to focus less on the downsides of Picnic and instead focus on the differences of Picnic and Min.
- exodust 12y agoYou mention IE5.5 support four times on your homepage. Nobody is using IE5.5 anymore, so that's not an attractive selling point, and slightly odd that you think it might be a selling point. The Picnic thing has "subtle animated buttons" which may be appealing to some looking for a certain design edge out of the box. Personally I roll my own everything, I don't use grids or bootstrap, so not sure why I'm even looking at this thread. I'm not the typical frontend developer though apparently. Div class="row" is not something you'll see in my code, ever. I'm not going back to table layouts by faking rows and columns with divs. That to me is working against the grain of HTML and CSS. When you start working *with" the grain, with the native behaviour of HTML elements, suddenly a lot more is possible and easier to accomplish when it comes to responsiveness and compatibility. But anyway.. carry on with your "not table based" layouts!
- owenversteeg 12y agoThanks for the feedback! * Although "nobody" (if parts of China and governments are nobody) uses IE5.5, plenty use IE6, IE7, and IE8, which aren't supported by many CSS frameworks. * Min also has subtle animations - only of background color though. I used to have more 3D-looking buttons but those were criticized for being too prescriptive - which I agree with; IMHO you shouldn't be able to tell what CSS framework a site uses by looking at it. * You have a really interesting point about grid systems and table-based layouts. That's something I'll have to come back to when I'm slightly more awake.
- mercurial 12y ago> I'm not the typical frontend developer though apparently. Div class="row" is not something you'll see in my code, ever. I'm not going back to table layouts by faking rows and columns with divs. That to me is working against the grain of HTML and CSS. When you start working *with" the grain, with the native behaviour of HTML elements, suddenly a lot more is possible and easier to accomplish when it comes to responsiveness and compatibility. But anyway.. carry on with your "not table based" layouts! Interesting. As somebody who loathes front-end development, I'm curious to know how you work against what I consider to be the shameful lack of support for laying out elements on a page in a coherent way (something which has been present in widget toolkits for fat clients since forever). I still remember with dreads the hacks necessary to achieve a three-columns fluid layout in a cross-browser fashion, and I'm certainly not going back to that.
- poxrud 12y agoThere is no need to litter your HTML with non semantic div tags that just represent rows and columns. I'm a big fan of using a framework like Susy (there are others as well) that just lets you assign the number of columns an element spans. Something like: .logo { span (3 of 10); } nav { span(7 of 10); } So you can get columns without touching your HTML.
- mercurial 12y agoInteresting, thanks.
- brianzelip 12y ago@exodust I'm interested in digging into _with the grain_ web authoring as you say. Checked your profile but didn't find any links. Can you pass some along to share the approach?
- exodust 12y agoI'll hold off sharing links but will give you something much better... my approach and whacky theories. TL;DR - I focus on the creative layout potential of html documents. I avoid abstraction layers that force dependencies between unrelated components that may inhibit layout control and design. To use css grid frameworks in production is to me like leaving the scaffolding on permanently and calling it a feature of the building. It's like leaving your camera on fully automatic, never taking advantage of aperture. I need confidence in the HTML/CSS foundations. When kept as a "single column" the whole way, with rows or bands of div modules stacked, and whose inner divs don't share vertical alignment connections with any other band or row, suddenly you have the freedom to explore ideas on the page with as much or as little inter-connections as you design. The requirement of course is that you enjoy the craft of HTML and CSS. "Alignment" is not hard. You don't need to enforce new structural rules simply to get things to align. A lot of developers do like that grids do that work for them. But I don't, and it's probably a personal preference, and also depends on the project. I find grids afford less scope for change later. Sure, you can "add new content" but with questionable precision in placement. If nobody cares, and it saves you time, then do it. I just don't do it. It's how my brain likes it. And I really enjoy using divs in combo with positioning in combo with floats and fluid control. It's fun, healthy and good technical investment to construct the detailed behaviour of your responsive template, to own the template is to trust. Grids take away the fun of having page elements do exactly as you wish. Because you're permanently compromising, you cease to notice you're compromising as "the grid" becomes the norm. There's a forever "don't forget the grid" question mark hovering over your shoulder, and over the designer's shoulder. "But we can't break the grid" is an awful discussion to have with designers. There's personal preference at work here, and I prefer unlimited publishing and html design freedom. Not that my job in the corp environment always offers that! With incredible CSS technologies available, I don't want to cage them up.
- 12y ago