7 ms·
> In my initial CSS implementation in 1995 I used the “SkyBlue” constraint solver to resolve conflicting style sheet statements. (By the way, “SkyBlue” and “Cas
by cousin_it 12y ago
> In my initial CSS implementation in 1995 I used the “SkyBlue” constraint solver to resolve conflicting style sheet statements. (By the way, “SkyBlue” and “Cassowary” were both developed at the University of Washington.) Having a constraint solver allows you to express relationships between arbitrary elements and have conflicts resolved automagically. However, things can get complex when elements disappear and new ones arrive, like they do through DOM operations. Circular dependencies must also be handled gracefully. Therefore, the idea of allowing CSS to express layout constraints between any elements were dropped at an early stage.
That was the biggest mistake, IMO. John Nagle's comments here [1] express that point really well:
> With Dreamweaver 3 and tables, it wasn’t necessary to look at HTML to lay out a page. With Dreamweaver 8 and CSS, the page designer must understand CSS, HTML, and probably Javascript. That’s was a big step backwards. The CSS system is just too programmer-oriented. And I’m a programmer. (Programmer as in MSCS from Stanford, the Nagle algorithm in TCP, inventor of ragdoll technology, real-time robot vehicle control, not programmer as in “writes some Perl”. And my first web site went up in 1995.) It’s not that CSS is hard; it’s that CSS is bad.
> The worst problem with DIV-based layout is that the layout system is too weak. There’s no form of “grid” layout. There’s no way to relate a DIV to anything but its predecessor, its parent, or an absolute position. The system is just too dumb. That’s why people have to stand on their head just to get three columns to work. Tables actually are a better designed layout system. Table layouts allow table cells which span multiple rows and columns. If all tables could do were simple grids of cells, the CSS approach might make sense, but tables are more general than that.
[1] http://www.raizlabs.com/graiz/2006/09/25/ten-reasons-why-css-sucks/ http://www.raizlabs.com/graiz/2006/09/25/ten-reasons-why-css...
- agumonkey 12y agoInteresting, since table based layout gave such ugly html sources. CSS might be incomplete, and too programmer oriented, but it has some value (it abstracts halfway).
- Swizec 12y ago<div class="container"> <div class="row"> <div class="col-xs-4"> What do you mean tables produced ugly html? </div> <div class="col-xs-3"> Looks totes modern to me ... </div> </div> </div>
- agumonkey 12y agoMaybe I was conflating two things, deeply nested tables AND inline style (norm of that era).
- Swizec 12y agoAh yes, we've at least gotten over the inline css ... although we seem to have gotten back into inline javascript with various ng-click="doSomething()" thingies.
- agumonkey 12y agoSadly yes, and worse, people seem to enjoy this way. sigh
- Swizec 12y agoAs I wrote a few weeks ago[1], I hate this way but I can't argue with results. It's quicker and simpler to solve low-hanging fruit this way, which lets me spend cycles on application logic. [1] http://swizec.com/blog/i-was-wrong-about-angularjs/swizec/6602 http://swizec.com/blog/i-was-wrong-about-angularjs/swizec/66...
- DougBTX 12y agoA good talk about that is "Pete Hunt: React: Rethinking best practices -- JSConf EU 2013" http://www.youtube.com/watch?v=x7cQ3mrcKaY http://www.youtube.com/watch?v=x7cQ3mrcKaY
- ufo 12y ago
- robin_reala 12y agoThat might have been true in 2006 but we now have reasonable support cross-browser for Flexbox[1] (especially if you reduce the pain with autoprefixer[2]), and CSS Grid Layout[3] is coming. [1] http://www.w3.org/TR/css3-flexbox/ http://www.w3.org/TR/css3-flexbox/ [2] https://github.com/postcss/autoprefixer https://github.com/postcss/autoprefixer [3] http://www.w3.org/TR/css3-grid-layout/ http://www.w3.org/TR/css3-grid-layout/
- rmc 12y agoSo it only took 20 years...
- brandonbloom 12y ago...and it's more complicated and less capable.
- deleted 12y ago[deleted]
- cookiecaper 12y agoWhile you're right that the current versions of all browsers seem to support it now (though Safari still requires prefixing), it's pretty recent on some of these: http://caniuse.com/#search=flex http://caniuse.com/#search=flex. Most people still won't feel comfortable using it for probably another year or so, and this is just one element in the Flexbox specification; it doesn't necessarily imply the rest is well-supported or that implementations are reasonably consistent across browsers.
- robin_reala 12y agoOK, fair points, but if the OP can look back 8 years and apply that to now then I reserve the right to look forwards 8 years and do the same :)
- acdha 12y agoIt is recent but I'm seeing >85% of visitors to non-technical sites using a browser which supports flexbox. At that point, using something like a CSS preprocessor to manage the prefixing / older spec support and deploying flexie for older versions of Internet Explorer starts looking like a very reasonable prospect. If your goal is simply to do vertical centering, align elements with consistent sizing, or have the ability to reorder elements in different contexts without having to change the DOM order, flexbox works well in all of the browsers listed at http://caniuse.com/#feat=flexbox http://caniuse.com/#feat=flexbox. That said, it is something of a travesty that one of the most popular reasons to dive down that particular rabbit hole in 2014 is to get real vertical centering: https://gist.github.com/acdha/a91a46706de02c37566a https://gist.github.com/acdha/a91a46706de02c37566a is still 11 lines for one of the most basic layout requirements.
- xorcist 12y agoHe is very much correct in this -- but do note that without the bad parts he dislikes we wouldn't have responsive design today. It could have been implemented better, but the underlying thinking that users agents should try to programmatically position elements where possible is sound.
- blowski 12y ago"Any donkey can kick down a barn, but it takes a skilled carpenter to build one." What language would be able to support billions of websites coded by millions of developers, rendered on thousands of different types of media and be easier to code with than CSS? Until I've seen a working demo of this mythical styling language, I'll be very grateful for what I've got.
- BigChiefSmokem 12y agoYour point is valid but please don't defend CSS, we deserve something better.
- blowski 12y agoI, for one, have given almost nothing back to the CSS. I don't read the papers, get involved with testing, implementation, or any of that. I don't even deserve table-based layouts.
- Retric 12y agoHTML
- blowski 12y agoDo you remember coding rounded corners in HTML? Slicing images, putting a 3x3 table with rowspans and colspans? That was easier than `border-radius: 3px`? And I have seen no solution for how we might code responsive layouts in pure HTML.
- Retric 12y agoYour making a lot of assumptions, but to be pedantic strait text + links is both pure HTML and a responsive layout. Sure CSS is useful, but IMO most of the pain from HTML / CSS / JavaScript is trying to recreate native application's pixel perfect layouts in a webpage. Also, I think you can embed all CSS functionality into strait HTML5 the advantage is CSS is concise not necessary. Granted, not something you want to create by hand, but if your code is generating HTML anyway it's not such a big deal. EX: <style> In the end CSS was designed to allow you to swap CSS styles independent of the underlying HTML not add new functionality to HTML.