Graphical layout is one of the most underestimated challenges in computer science. Programmers instinctively look at the problem and thing "oh, this is logical, I'll just whip up some basic principles and layout primitives and I'll have this solved in no time!"
No, you won't. Designing a layout framework is really, really hard. Designing one that is simultaneously expressive enough to handle all of the crazy corner cases that pop up on a daily basis AND simple enough to allow "normal people" to actually use and extend it is quite difficult. For example, the Android layout system is suitably expressive but totally mystifying to anyone who hasn't spent a year reading the source for View/ViewGroup/FrameLayout/ViewRootImpl.
The OP's suggestion that there is some singular, beautiful, composable layout system that we could drop in to replace CSS is, frankly, a pipe dream. Or rather, I would be far more convinced if he actually pointed to a spec or pre-existing system that we might base our new system off of [1].
I see only three real possibilities going forward, in order of increasing likelihood:
1. Someone does indeed come up with the One True Layout System (very unlikely).
2. We finally shove bytecode-level runtimes into a browser and let a thousand flowers bloom (even odds).
3. We keep incrementally improving CSS, adding support for various layout relationships that people need (probably).
[1] Elm's system looks neat, but it's not there yet.
I used to work with whacky designers who would always come up with ideas that broke the layout system for whatever toolkit we were using, so I quickly "adapted" by using canvas and doing it all myself. To that end I created Bling:
The idea is that layout in WPF is so ridiculously complicated, yet data binding could be made so ridiculously simple (hey, they are almost constraints!), that it is often easy to just "do the math" for the layout you want rather than configuring a high-level layout component to do it. The same principles probably apply to ReactJS also (which provides a nice databinding system like WPF). Elm doesn't provide for constraints directly, I think (rather without behaviors, you'd have to compose various events to simulate them in an inelegant way, but please correct me if I'm wrong).
Have you used Qt's layouts? The problem with Android's layout system (if I understand it correctly) is that you specify how things are arranged relative to each other, so you never really know where something is. Added to that you have counter-intuitive behavior from things being calculated at time of addition rather than time of display (can't remember exactly, but I ran into something like that).
Qt is more declarative. I forget the function calls but in pseudocode you can do things like
horizLayout.add(Text("abc").setFixedWith(12));
horizLayout.add(Text("XYZ").setExpand().setAlign(kCentered));
horizLayout.add(Text("").setFixedWidth(12));
and you get something like:
[abc | XYZ | ]
(where [] is the width of the layout, and | separates each element.)
I've found it to be pretty intuitive.
> The problem with Android's layout system (if I understand it correctly) is that you specify how things are arranged relative to each other, so you never really know where something is.
RelativeLayout is just one of the several layouts you can use on Android. Typical Android GUI's are usually a mix of this one and a few others. This combination is very powerful and has been instrumental in making Android GUI's scale so well to many different devices with various resolutions and DPI's, a challenge that Apple will soon face.
Have you seen http://gridstylesheets.org/, which works as a polyfill and puts the Cassowary Constraint Solver behind CSS? It doesn't solve all CSS issues, but it's better than what I'm using today [1].
1. Someone _has_ come up with the One True Layout System. It's just that most people like to pretend TeX doesn't exist or, when they grok the box-and-glue layout model, try to reinvent it from scratch.
Someone yell at me if I'm wrong, but isn't TeX designed for paged content?
That means while TeX might work amazingly for paginated content, single page apps, or really any non-paginated content, is very much a screwdriver where a hammer should be used scenario.
Overall it is, but when the above commenter mentions box-and-glue, they're talking about the building blocks of the line breaking algorithm TeX uses (you can read about it in this paper: http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/ab... ). The box-and-glue system is a way of expressing a layout as an optimization problem (in the paper, they talk mostly about determining line breaks within a paragraph, but the idea of minimizing badness can be extended to determining page breaks as well). A bigger concern for me is the performance of laying out any reasonably complex page — the performance we get from rendering a reasonably complex webpage today is generally much better than rendering a reasonably complex LaTeX document.
I've come across a feature request for Firefox where someone proposed to use the Knuth Plass line breaking algorithm just for text layout, but they didn't get very much traction: https://bugzilla.mozilla.org/show_bug.cgi?id=630181
Are there any CSS replacement proposals that are based on linear programming [1]? There are a lot of things you cannot solve with just LP (e.g. rearranging floats on a page) but it's a pretty good -- and simple -- abstraction for laying out boxes relative to each other.
Solving LP is fast, especially when many of your constraints are equality constraints (as would be when specifying tables).
I think Cassowary [1] is what you're talking about (particularly section 1.2 where they talk about some modifications to make their system very fast for incremental updates). Apple has based their constraint-based layout system, Autolayout [2], on Cassowary. There's also a project that incorporates Cassowary constraints into a CSS-like declarative syntax called GSS [3].
does TeX have responsive layout with a variable document width? For the past year my ability to use CSS alone to convert an existing HTML Website and make it work on mobile has been putting food on my table. Could I be using TeX for the same thing?
In theory, yes. TeX basically outputs DVI. DVI is meant to be a 'DeVice-Independent' format, so someone could come up with a browser layout engine that implements it, thus giving Web pages TeX-like typography and layout quality.
Designing one that is simultaneously expressive enough to handle all of the crazy corner cases that pop up on a daily basis AND simple enough to allow "normal people" to actually use and extend it is quite difficult.
Erm, ... No and yes,
OK, take old problem in designing a system, demand that it solve "all of the crazy corner cases" and viola, you have a challenging, even unsolvable problem in computer science. Indeed, such problems are not even problems of computer science, they are problems of software engineering, of human relations and so-on.
Designing a layout system isn't a hard problem but it does involve tradeoff. Like many other system, if you shop around for something that's all things to all people and assign a vast committee to create it, you'll windup with a thing a best ugly and possibly unusable. But there's nothing too specific to designing layout systems here.
I absolutely agree that the main issue is that the system can't be improved by competing concepts.
The development model is really important - what started as a private hack became a designed-by-committee mess, and now is starting to become more sane in the age of HTML5, as new useful technologies and APIs are being added.
The big issue is CSS (and Javascript is only slowly becoming better), which stems from the designed-by-committee (with bad taste) era - if it was designed today with Google etc. at the table, it probably would be a lot better.
People try to work around that by using pre-compilers like LESS and CoffeeScript, but those cannot fix the underlying issues. If people could design their own CSS engines, the development model would allow for rapid iteration and whatever people like the best would see broad adoption.
Reminds me of the BPF packet filter bytecode - limited, but fast and secure.
A few websites manage to reimplement decent scrolling today, but I have yet to see scrolling that's better than standard behavior. This sounds like a move to have everyone use their own scrolling engine.
Maybe we are at a point where there are too many novice user to care about interoperability, but I'm a big fan of the fact that my browser understands the content it renders and that I can run plugins to manipulate it. I daily highlight text to search for it, drag non-marked-up url's to the URL bar to open said links, change page layout for easier reading, translate words as my curser point to them, etc, etc. all features that flash pages used to break and a "canvas/webGl" world would appear to break as well.
I've just been watching a colleague learning HTML/CSS for the first time. HTML was easy and she has a very good handle on that, producing some nice HTML5 markup by hand very quickly. CSS has been a nightmare - mostly not because of selectors or values (that comes later), but because of basic layout issues caused by the nasty hacky layout model of CSS - in particular the concepts of floats, block and inline and unpredictable element sizes due to the box model.
But I disagree that CSS should thus become a general purpose programming language - the separation of concerns in HTML into content/style/controller is very useful and would be terrible to throw away, just because our current styling language is so lacking.
The problem with CSS is layout - properties, selectors and values could do with some work of course, but they're mostly passable if a bit underpowered. Layout is insane and it's down to assumptions made at the creation of CSS - a very simplistic doc model assuming some basic structure of heads, text and a few pics flowing in a linear fashion down a page - like a technical paper or simple book layout. Flexbox looks equally unintuitive if a bit more powerful.
It is a hard problem, but there has to be a better way than the current agglomeration of hacks upon hacks - something akin to the HTML5 movement for styling - remove or deprecate most of the overcomplex spec and refine what is actually in use. Grids are key here - they've been used in graphic design for centuries, and they are a fundamental part of organising information which is entirely missing from the CSS spec and should be the basis of layout, not an afterthought.
Indeed CSS is broken. But, if you tried to make that case several years ago during the Great War on Table-based Layout, you'd have been absolutely persecuted. Oh how we wrangled with the utter pain that is CSS layout, only to appease the tableless zealots. I can remember wrestling for hours with simple layouts that just wouldn't cooperate cross-browser. Meanwhile, I could achieve those layouts in mere minutes with tables. Not only that, the resulting table-based design HTML was an intuitive read.
The reason was as you say: Grids are key.
How many people would now honestly say that we are better off for CSS-layout vs. tables? But, it's amazing how an entire industry lurched in one direction so quickly, based on ideology. The pressure to use the "right" approach was immense. The whole thing had a very "Emperor's New Clothes" feel to it. Everybody seemed to agree that CSS layout was completely awesome, while I beat my head against the wall trying to make it work. Now, we all see that so many were actually suffering in silence.
>the separation of concerns in HTML into content/style/controller is very useful
This is a belief that I question to some extent and I've wondered whether it's a core assumption that sounds great and thus goes unchallenged, but fails to make the cut in the practical world. In particular, how much do we really need to separate content from layout? Styling is one thing, but layout tends to be intrinsically tied to the content. You can change the appearance of content without modifying its meaning, but changing its organization or layout can render it absolute nonsense. Thus, if CSS were all about colors, fonts, etc., it would actually be a somewhat reasonable approach to separating reasonably separable concerns.
But, as most now agree, it's CSS's horrible attempt at managing layout that makes it so painfully bad. And, I really wonder if the core problem is just that there's no real benefit to trying to separate layout (vs simply style) from content in the first place. What we're really saying in attempting to do so is that we want to be able to create a document wherein we have a bunch of unstructured content that we want to insert in an essentially random fashion, then create a second document that rearranges the content.
It's an unnecessary abstraction that seldom provides an ROI. How often do we later want the content to stay exactly the same, but simply want to change where it appears on the page? And, if we do, is it really easier to change the layout in an external document (CSS or otherwise) than it is to modify the document?
I have yet to hear a proposal that makes more sense than the old-table based design. The purists said that tables are strictly for presenting tabular data. Fine. So, let's create a new tag called "grid" for layout and give it the same layout flexibility as the tables of old.
Styling is one thing, but layout tends to be intrinsically tied to the content.
This is an interesting distinction - thanks. As you say there are issues with separating layout and content, because the two can be hard to separate effectively. I think it is worth the effort though, and sometimes pays off (for example reflowing content for a mobile device). An interesting thought though that we should separate style and content, not layout and content.
As to tables, I think there were two issues mixed up in that religious war - the nasty markup of table/tr/rd, sliced images etc polluting every website when it was intended for data, and grid layouts (which it made easier). Unfortunately grid layouts were thrown on to the auto-de-fé along with sliced images and table markup, and then promptly reinvented (with much pain) by entire frameworks designed to make up for the shortcomings of CSS.
There have been very recent attempts to add grids to CSS, and hopefully they'll come to something (see link above from buovjaga) - I do think they're far more intuitive and most importantly impose a sensible structure on people attempting to lay out information.
Untying styling from layout is what OOCSS does. All styling is written only with classes. This makes it easy to reuse styles. All other selectors, especially nested, are avoided, since they rely on a certain layout and can't be reused.
Good points. I think that responsive design is probably one of the biggest use cases for CSS layouts these days, though I don't know that it was a driving force or even a consideration when The Great Tableless War began. In any case, I'm not quite a believer in responsive design either. The short is that, as commonly practiced, responsive design fails to acknowledge the relationship between content and layout. I posted a lengthy comment on this thread with more on that, so I'll spare HN's bandwidth the duplication.
Image slicing was indeed nasty and I don't think it was as much a function of table-based layout as an implementation choice. Some tools were particularly nasty with this, but they were less famously also capable of outputting equally nasty CSS/div based code. So, good handcoding is really required to achieve any semblance of maintainable design, whether CSS or table-based.
But, I think you nailed the history. And, it just happened that table capabilities were remarkably useful for laying out a page. Had this been intentional vs a byproduct of that tag's function, the outcome may have been different. One could literally rename "table" to "grid", "tr" to "row", and "td" to "col" and be most of the way there. Would a separate tag of this ilk that could be additionally styled with CSS have silenced the tableless zealots? We may never know. But, if so, it's amazing to think that all of this upheaval, pain, and lost hours was the result of such simple puritanical ideology.
Such an HTML tag vs. pure CSS construct would have also pointed to the already blurred lines between HTML's suggested role as merely a data container vs. its unavoidable role in presentation. The theory that HTML represents only data still manages to sell itself when we are talking say, paragraph and list elements. This is so, in spite of the fact that, like "real" tables, even those elements are themselves completely loaded with implicit layout information.
We need to embrace the fact that a paragraph tag implies that this element will need to be offset and, yes, the details can be found in the CSS. But, when reading/writing the code, the order and structure are intuitive. We don't randomly spit out a group of paragraphs, then impose the ordering via a stylesheet. Instead, we expect the order to be as it exists in the document. Same with lists and other elements. Likewise, the fact that the structure of the document has implications on its layout even leaks through when using CSS. For instance, assigning a value of absolute to the position attribute of an element, positions it relative to its ancestor in the document structure.
But, it's when "pure" layout is involved that things become murkier. We suddenly want to disavow that the natural layout clues are already there and instead force this unnatural separation into CSS. The problem is that much like with tabular data or a series of paragraphs, all content on a page has a relationship to other content that is best expressed in a natural grid like structure. It's not just visual, but actually semantic. So, it is natural to express this relationship in the markup and leave the styling details to CSS. Perhaps more importantly, it is unnatural to spit a bunch of related content into a document in a completely unstructured fashion, then impose structure in a separate document.
So, let's not repeat the ideological mistakes of the last Great War. Ask your Congressperson to keep the grid element out of CSS (except for styling) and add it to HTML where it belongs! :)
"Not only that, the resulting table-based design HTML was an intuitive read."
Wow, Stockholm syndrome can be really messy.
It's likely possible to produce readable table-based design, but the tools at the time most assuredly did NOT produce that. Nothing sucks like spending a couple hours figuring out which of the eleventy-billion inline-styled cells Dreamweaver has bumped to 2px too wide, shattering an entire image-sliced layout.
If you're talking Dreamweaver, auto-generated inline styles, and image slicing, I think it's safe to say that you're signing up for pain irrespective of what the output is.
Still, finding a 2px misalignment would likely be a more masochistic exercise if you were wading through nested divs with no clear grid layout vs. nested tables.
But, I think your complaint is with the tool itself. Maybe that's why I sincerely know of no web devs who have implemented a serious project with Dreamweaver. My personal (brief) experience with it was that any support for real separation of concerns was so lacking that whether it generated tables vs. CSS was the least of my worries.
The root of the problem has little to do with either technology: it's related to the desire to cart application chrome around with documents, using a technology that was designed to render documents -- and documents only.
At a fundamental level, what's missing is the ability to add a link rel=chrome tag in a document's header, such that you'd only sends a header with a title, that link rel=chrome tag, and its contents within the body. The header, footer, navigation items, etc. should all be defined outside of the document itself, as part of the chrome.
Put another way, a level of abstraction is still missing in the web developer's toolkit. Over the years, we've been compensating by:
1. mixing chrome and content together in html documents
2. sending boat loads of chrome-related styles alongside
Add to this that a great many web developers received little to no education in computer science, and it's no wonder that web development is such a mess.
>a level of abstraction is still missing in the web developer's toolkit.
As CS people we kind of intuitively feel this, but I'm not sure we really are missing anything, because, basically, HTML is already at the presentation layer. Remember when the proposed solution was to use XSLT to transform XML into HTML? Terrible as that was, the motivation behind it was a nod to the fact that XML is data and HTML is presentation.
So, I also wouldn't agree that mixing chrome and content together in HTML documents was a compensation as much as simply using HTML for its purpose. The content actually starts elsewhere (XML,database, etc.). It ends up in HTML for the very purpose of presentation.
There are ways to separate out chrome and modularize it that can use pure HTML. That makes sense. But, I don't think we really need another tech, language, or abstraction.
Now, we have added CSS to further abstract and LESS on top if that for still more abstraction. It can go on ad infinitum, but at some point, we are losing value with each additional abstraction.
The chrome (nav, footer, etc.) that you mentioned is one part of the equation, but the other part is styling/layout of the content itself. That is, within a page that features chrome, there is still the need to layout other elements of the page.
So, CSS fails miserably at the latter. And, ironically, the former (i.e. chrome) can largely be handled very cleanly via other means (e.g. a templating system that modularizes the chrome and content elements).
In any event, what you're saying is true to a large extent. It is not ideal to cart around data with presentation, so it is tempting to impose some degree of additional separation by some technology.
But, the challenge is that it doesn't tend to match the real world. That is, the idea that there are or should be these agnostic HTML documents lying around filled with, effectively, unstructured data is more myth than anything. The unstructured data is in the database or elsewhere. What you're generally doing is taking all of that raw content and presenting it. That's how it ends up in HTML. And, the truth is that HTML is really a presentation language more than a document/data language. If you want the latter, then you'd move up a level to "pure" XML. But, the same problem exists: now you really do have raw content akin to DB data, so how do you now impose a visual layout on that data?
So, here, I would argue that the separation has largely occurred before you get to HTML, thus it is OK to use HTML's more intuitive layout capabilities to layout the document.
Attempting to instead remove it from the HTML is simply adding an abstraction. And, honestly, we haven't decoupled anything. We've just moved it to an interdependent, less intuitive document that must now be carted around too.
So, while CSS is onerous for layout, I think the motivation behind relocating layout responsibility must also be scrutinized. Even if a less onerous CSS replacement existed, the cost of separation must really be weighed against what is actually being gained.
I think part of the story was that people wanted to write cross-browser code and that limited your tools to the bits of CSS that IE supported at the time. I doubt any system you could design, even tables, would be considered anything less than broken when a majority of the market was indifferent or actively hostile to it.
Even today I regularly think "I wish I could just use X", then I remember that my current project is targetting IE9+ and that means often I can. It gives me that same warm glow you get when you remove shoes that are too tight or stop banging your head against a brick wall.
I tend to agree with how using table to do layout got vilified for often very little reason. On the other hand, when dealing with responsive sites, or wanting to switch layouts in javascript for a reason or another, using css is the only sane way.
Hopefully, css tables are very usable, and playing with them is nice and smooth most of the time. Being able to cleanly redeine grids of content on the fly is one of the big advances that css brought to the table I think.
I am probably an outlier in my views on responsive design, but I'm not really sold on it either. Part of the reason is that, again, I think content is more tied to layout than people acknowledge. Also, I haven't really seen a compelling implementation of responsive design.
Most of the time, I see responsive sites hiding the site nav into a pull down menu and smashing, say, a three column layout into a single column. There are also responsive sites that outright selectively hide some content on some devices.
Hiding content implies that either the content isn't that important in the first place or that a diminished experience will be delivered to a particular device. Neither of these seems desirable.
Likewise, smashing a multi-column layout into a single column is also frequently a suboptimal user experience. In these scenarios, at least one column is usually more akin to nav, which means the user must now scroll past an entire column of nav to get to content or vice-versa. In effect, the layout change has altered the meaning of the content.
So, in general, to really deliver an optimal experience per device (if device specificity is even truly required in the first place), I believe it's worthwhile to consider different sites per device. Responsive design is a compromise that tempts devs into a "reuse" approach but, in truth, neither the required CSS nor the resulting output are optimal. So, the user experience suffers and the code isn't a lot of fun to write or maintain.
In other words, the more you want to thoughtfully vary the layout per device versus, say, just cramming everything into a single column, the more CSS you'll have to write. At some point, the volume and hackiness begs for a separate-site solution. To avoid this, responsive design just sacrifices the user experience instead.
The last part of this is that responsive design feels like a kludge aimed at solving a transient problem that is increasingly being solved by better hardware and interface design at the device/browser level. For instance, bigger and more readable displays on mobile devices, combined with pinching plus auto-zoom and auto-sizing by mobile browsers means that full desktop sites are generally very presentable on mobiles now.
In that regard, responsive design feels like WAP did years ago. Smartphones with full browsers, increased bandwidth, etc. killed the need for WAP in short order. IMO, responsive design will ultimately go the same route and has already to some extent. I, for one, already request the desktop site on all of my devices and much prefer the experience.
> But I disagree that CSS should thus become a general purpose programming language - the separation of concerns in HTML into content/style/controller is very useful and would be terrible to throw away, just because our current styling language is so lacking.
Separation of concerns or technology? For example if you use React.js you have view-controller, therefore why do I need CSS in an external file? I don't, it's there only because can't be into the React.js view. I would prefer to have the styles right in the view. The colors and this stuff might be per template basis which can be changed with js.
If they still want to continue with CSS they should really make some stuff like in javascript "use strict" which works a lot as expected. No more margin:0 auto to center no more of that unintuitive rules and specifications that varies so much.
Even responsive design only cares about window width, this is not enough to design a responsive website/app. Now are preparing something that is relative to a parent, which is even more useful, but not yet working.
This could be solved with a proper javascript layout engine: like qooxdoo for example which has layouts like in flex; I don't say this is a good or bad framework but for me was just to invasive and rigid. I come back to css+react.js but no html, I also don't thing that you should think of UI based on html terms but on component terms like react.js.
Most "problems" with CSS (with the exception of vertical centering and a few others) are caused by the fact that people can't be bothered to learn CSS.
It's funny: if a programmer is told to write CSS but doesn't know how, he'll copy-and-paste from Stack Overflow, get a shit result, and say that CSS sucks. If a programmer is told to write Elm but doesn't know how, he'll learn the language, write some decent Elm, and be happy. Now, who do you think will have the better time - the person that actually learned his tools or the person that copy-pasted CSS from Stack Overflow?
Even if you assume that CSS is as horrible as the author would have you believe, the 'solution' of Elm is preposterous. As another commenter [0] said: it outputs a crazy amount of divs, all the styles are inline, you lose the CSS ecosystem, and you lose performance. Even the demos of Elm for layout are completely broken.
My instinct was to disagree with you because I've been doing CSS for so many years and still find it frustrating. Then I realized in all of those years, you were right, I never did take the time to read a book on it.
I don't want to understand CSS deeply, because the fact is I hate using it. I find it overly difficult to get right. I find it illogical at times. I used to find figuring out the differences between browsers in regards to it a nightmare (not so much anymore). But, you're right, perhaps if I read a book, it would all be much easier. The 10 hour investment in really understanding a good book, would make the many years of messing with it and hoping it works seem wasted.
The only way I've kept my sanity is through using frameworks like Bootstrap. I feel like I rather delegate the responsibility of learning what I see as a mess to the designers of a CSS framework. I figure, if I can understand so many complex things well, and using CSS is still a challenge, it must be CSS, not me. But, maybe it is me. On the other hand I feel in my gut, after many years of working with Interface Builder/Visual Studio and other IDE's GUI layout tools, there must be a better way for non-designers (and designers for that matter) to do this.
I actually learned CSS in a school. My teachers were real front-end developers.
I can honestly say that I never had any problem with CSS and that I never found it to be broken. The only issues that I think of come from trying to fix things for the old IE browsers, which are broken.
CSS itself? Mastered it in 3 months if not less.
Come on, people. You can't give me both "You are paid less because CSS is easy to learn!" and "CSS is so hard! I can't use it! We should create something new to remplace it!".
You seem new to this. Just keep centering variable height content vertically in variable height containers on different browseres until you get what's broken with CSS.
You can also try to pick up a newspaper (multicolumn) and try to replicate its layout so it behaves well with dynamic content.
I've spent ten years learning and using CSS and I still find it very hard to do even seemingly simple layout.
I spent about six months with QML before I was capable of beautiful, rich, animated graphical user interfaces. QML was a much nicer experience and I can get the results I want very quickly with few or no errors. CSS is a struggle every single time.
Is that just me not being bothered to learn CSS? Or could it possibly be that CSS really isn't that good a tool to begin with?
I've learnt many technologies over the years and I will no doubt learn many more. Your statements above don't consider the important question - the relative complexity of CSS compared to other aspects of web development.
"You can't be bothered to learn your tools" isn't terribly helpful when you've just given someone a hammerwrenchbathplug.
This all day. Take an online course on CSS, really grok the basics, pick a grid framework, and you're done. Should take less than a day to go over it, maybe a week of practice before CSS is another tool in your belt that you can wield with efficacy and ease. The more complicated stuff, it's fine to copy-paste from SO - no shame.
I've been working with CSS for a few years now, and I've read up on a lot of the intricacies, and I still find that I am constantly tweaking and searching for anything that I haven't previously solved (or that I solved a long time ago). And then when it works there's some browser that renders it a little bit differently.
I don't have that problem with any other part of the stack I use for web development.
I'm not really sure I understand what the point of this message is. The point of separation between CSS and HTML is not that "designers" are idiots. Nor is it that developers are poor designers. The idea is strictly to keep the data separate from any other concern. This is broken all of the time by all sorts of grid based elements and such. But the idea does seem decent, if a touch naive.
That is, to Spolsky's credit, the point of HTML being completely layout free is supposed to be the compelling feature. And it roughly works for basic documents. I'm actually convinced it could work decently for more complicated layouts if absolute positioning were more understood by developers and designers.
Are there better ways to go? Certainly. I'm particularly fond of the way that LaTeX gets things done. Though, that is far from a "safe" environment. (For example, you should probably never just up and run a .tex document on your computer without first scanning it yourself.) Also, it is worth noting that efforts are usually made to separate style from content there. (Not sure what the overall verdict is on those at the moment. But they do exist.)
At the end of the day, though, the dream is still a language where you can edit one file to change the way something looks on render, and another to change what it contains. Any language that lets you do both in one place will result in you doing both in one place. Such that it becomes very problematic to change the look of something without changing what is in it. And vice versa.
> That is, to Spolsky's credit, the point of HTML being completely layout free is supposed to be the compelling feature.
Except that it isn't. If you want to do anything entirely non-trivial, you have to annotate your HTML with classes and ids, and then hook into this using a complicated declarative language. But, at this point, there is no abstraction gain from
<div class="floating_figure">...</div>
over
floating_figure(...)
Functions are fine abstractions and nothing stops you from providing different implementations for different situations, and these implementations can again use abstractions to deal with a variety of output devices. Nothing here requires you to define layout specifics as part of the document [1].
Moreover, not all the world is just plain sequential text. There are mathematical formulas and syntax diagrams, for example. math.stackexchange.com falls back to Javascript (via MathJax) in order to display formulas; and Lout provides an excellent example of how one can specify the spatial relationships of syntax diagrams [2] while still abstracting over the implementation details (Lout is another functional layout/typesetting language).
[1] Of course, in practice, the world is never so clean, and you can rarely ignore layout constraints entirely; anyone who has ever written a paper containing a non-trivial mathematical formula knows that.
> But, at this point, there is no abstraction gain from
> <div class="floating_figure">...</div>
> over floating_figure(...)
There is no abstraction gain, because you are using a presentational class name.
It should not be "floating_figure", "big_red_text" or anything of the kind.
What it could probably be is "feynman_diagram" or something simmilar describing what's so special about this particular element, not the looks or placement of it.
And then it is up to your CSS to decide should it be floated, fixed, or hidden altogateher.
I said that was the point. Not that it succeeded at it. I fully acknowledge that it is broken all the time. However, if you want a loose control over the visual characteristics of a paragraph with some images, than the base html and css for floats gets the job done. Want columns? Yeah, you're screwed.
Seriously, most of the headaches from css come from trying to get it to do things that were not goals for the designers of the language. This is not a bad thing. But to believe that a turing complete language would have been a panacea is dangerous. And likely wrong.
If HTML was still just hypertext, which is text organized with links to other text, then the separation of data from appearance makes sense. But we happen to use HTML and other web technologies to create complex long-lived applications that are much more than hypertext.
Seems to me that the answer is to provide a real applications development environment. Not to shoehorn ever more crap into browsers.
I've called before for splitting Web functionality into several modes. I think it's fairly clearly the way to go, and is actually how development's been headed to a reasonable approximation for the past few years.
1. A reading / discussion oriented platform. The traditional browser, though with vastly better document management capabilities, and much simpler graphical presentation. Basically elecronic paper, similar to Pocket / Readability / Instapaper, or an eBook reader.
2. An applications development platform. Pretty much where the mobile space is now. There's Internet connectivity, and often Web elements. But what you get are freestanding apps.
3. Commerce. It's own space for security and privacy as well as function. You're seeing this with iTunes, the Play marketplace, and Amazon commerce apps.
4. Multimedia. Give me a freestanding player with its own queuing mechanisms. Again, pretty much the case on mobile.
What browser-based apps offer is a uniform platform for applications development. It's a HUGE revolution in applications space, and as much as it's frustrating to me (on both the user and developer/ops side), there's no denying its impact and significance.
Supporting a zero-install or minimal-install path, supporting all platforms from the same runtime, and providing instant updates to all users is tremendous. It's a large part of what's made smaller Web ISVs (SaaS) possible. Systems integration and platform support kill applications design in other contexts.
But those same features are also limitations. I've had multiple horrible app upgrades, apply massive amounts of styling to Web sites and apps, and _still_ run into compatibility issues, as a Linux user. And then there's the security profile.
There are a number of compromises possible, but pulling the "applications runtime environment" out of my "information delivery tool" seems an increasingly positive step.
Not that we haven't had attempts to provide that runtime, e.g., Java and ActiveX.
One problem is that the runtime itself cannot run as the same UID as the user invoking it. It's got to be fully sandboxed and separated, further by origin site or authoring authority. Possibly within its own VM. Trust of Web content is a real problem and one that will only grow.
Because no one application framework is already supported by the vast majority of Internet-capable devices, requires no "installing," and supports a standardized and ubiquitous system to link between applications.
LaTeX separation of style from content is in-principle even looser than HTML vs CSS. TeX doesn't enforce the separation at all, and lots of old style TeX documents mix it with abandon. But the culture of LaTeX users embraces the separation.
Right, I had not meant to imply otherwise. It was an example where there is nothing forcing you to separate style from document. At least, not to my knowledge.
Except, of course, for any paper you want to offer to get published somewhere that has a style file for you to use. Then, yes, you have to support that. :)
The thing is HTML is not layout free if you use it as intended.
For instance different layouts are defined for table, span or div tags. The same goes for presentation, where h1/h2/h3, input or select tags have a default presentation. You can override most of these defaults (some are still pretty hard to override), but it's still baked in; would your CSS be ignored or not loaded for any reason and you're back on the defaults.
Cleanly separating data and presentation into HTML and CSS only works if you ignore all the semantic tags and use div everywhere. I personally gave up a long time ago on semantic html, that's not the opinion I hear the most.
Either way, I think most people see HTML as base layer with data, presentation and baked in behaviors, and CSS and JS as a enhanced layer on top of that.
Presentation and semantics are not the same thing. All the default presentation is easy to override if you know what you're doing. CSS is pretty damn simple. You should learn the basics. Namely: cascading, specificity, nesting, inheritance, the _BOX_ model. If you think presentation and semantics are mutually exclusive then you're doing it wrong. Very wrong! The example you give about the default layout of elements can easily be changed using the display property: https://developer.mozilla.org/en-US/docs/Web/CSS/display
On a theorical point of view I agree with you. In practice there's a world of difference in presentation if you use the semantics for a select box or roll your own solution.
In a way I am very intersted in what Google is doing with the material UI. They seem to be ditching native components to reimplement everything.
Basic css is simple and fun. It gets hairy when you try anything mildly complex, and you start to learn magic spells when playing the "I made this screen in Photoshop, make it pixel with pixel perfect fidelity in HTML" game.
I don't think the problem is that CSS is an unnecessary approach to the problem of layout. It is more that it is a poor approach to the problem of layout.
A layout language is unnecessary given a bytcode VM a chunk of memory, code, and an output. The balance is in capability, performance, and understanding.
I have done a lot of CSS wrangling which has given me plenty of time to consider what 'a better way' could be. I doubt I'm alone in that respect.
CSS has three parts. Properties, selectors, and values. When someone is talking about how awesome CSS is they have usually done something clever with selectors. When someone is ranting about getting CSS to work right, they are usually trying to figure out what set of values to put into properties.
The properties themselves are insane. The legacy of incremental development and serving many masters. The options for values are limited. attr() would help my own usage a great deal but Firefox doesn't support it (see here someone complaining in 2011 that they've fallen behind Internet Explorer on this https://bugzilla.mozilla.org/show_bug.cgi?id=435426#c3).
Actually Properties, values and Selectors are all limited. Selectors are just the least weakest link. Properties could do with a complete breaking overhall (ie. If a document is in doubleplusgoodCSS mode it only supports the new style properties). property values should be the results of expressions in a pure functional language. Selectors should be another expression system with operators and member-check functions, the selector system is close to what it needs to be already. Just a mechanism for user defined groupings (such as attributeContainsPrimeNumberAsHex("class")) and combinators.
I fully agree with your distinction of selectors, properties and values - not all parts of CSS are bad. When you say "property values should be the results of expressions in a pure functional language" - which I think is a great idea - do you mean to use them to compute layout as well?
When I posted that comment My view was that layout would still be primarily driven by higher level style properties, but after I posted I though about it some more and I realized if done properly you could probably the css value language could theoretically do it all. If it were to generate values for the complete layout, bypassing the higher level layer, effectively telling the display engine that everything was absolutely positioned and in the right place already.
I don't think I would advocate for that to be the standard way to implement layout, but it should be at least possible.
Similarly I think the system should be capable of specifying a table where each cell has a background colour corresponding to its position in a Mandelbrot set. I don't think people should be doing that normally either, but I certainly think it should be something that is capable.
I see where you are getting into... But not pure, please, but reactive. One creates events on HTML and Javascript (there are a few by default), CSS filters, maps, and uses them.
The part of the system I was talking about would be a static component beneath the level of scripting and events.
At that level the document can be considered a static snapshot of the state. The evaluation of each of the property values would be single expressions that could draw upon the state as input and produce style properties as a result. There should be no lifetime of the execution beyond that single evaluation. As an implementation detail, this would be extremely amenable to parralelism and memoization. to make things perform well.
Even though you have things like :hover and transitions in a document that can dramatically change what you see onscreen, the Document itself is unchanging. Think of it as a many-dimentional thing. Nothing changes when you hover over an element, but your rendered viewpoint is now drawing the space in which :hover is true.
Scripts are things that can potentially change the Document itself.
Events are things that happen related to the viewpoint renderer. it would be entirely possible to define something at a lower level to indicate that an event is capable of occurring via the styling mechanism, but what actually happens would be up to the viewpoint renderer.
Consider the case of an event occurring on the end of a transition. The triggering mechanism is the viewpoint finishing the transition, and it is up to the engine driving the viewpoint to trigger the event.
The styling behaviour would merely indicate that a transition would be requested on certain elements.
Looks like we are almost in agreement, except that I see no reason to separate event handling from the overall style description. Of course, modifying the document is out of the scope of styling rules, events handlers on that level must change only styling, nothing else.
What events bring (besides generalizing the :hover-like pseudo-selectors into something more powerfull) is better separation of concerns. Instead of your Javascript touching several elements styles, it generates an event, and you describe how to handle it at the styling sheet.
In Servo we've been able to get a lot of parallelism out of the basic building blocks of CSS. Any replacement would have to have a good story here. "Just write your layout in JS" is not good enough and would be a large performance regression.
Constraints based system is the way to go. And yes, it should be native replacement for CSS- a DOM property called constraints instead of style. Unfortunately, JS has to be used for now. [1] As for parallelism, we still have web workers for the solving of constraints computations.
> As for parallelism, we still have web workers for the solving of constraints computations.
I am confident that the lack of shared memory, along with the heavyweight nature of web workers, means that any attempt to use web workers to perform parallel layout will be slower than sequential.
I'm struck by the contrast between the conventional wisdom that content and layout should be kept separate, and the recent highlighting of Mike Bostock's work at the New York Times on articles like http://www.nytimes.com/interactive/2014/07/03/world/middleea...
I've always been dubious about how well that mantra applies to web applications, but conventional wisdom certainly has it that content and layout separation works most strongly for documents; but Mike's work shows that layout can be a powerful component of messaging.
Producing pieces like the ISIS layout requires a much richer concept of separating the layers that go into the final presentation; paragraphs of text associated with geographical regions, times, and news events are the content items - not simple divs with classes, but rich objects. Choosing then how to lay those out is clearly far beyond the capabilities of CSS. And while in theory the layout logic to display a scrollable strip map with location markers could be reused for another story, in truth that layout is part of this article, not a generic 'stylesheet' that would be shared by a number of documents containing similar objects.
We need tools that facilitate creation of procedural layouts. CSS has its place in specifying typographic conventions, but it's a hindrance to making more interesting content-led layouts.
Does anyone think it'd be a good idea for browsers to support more than one toolset? Right now it's just HTML+CSS+JS, no matter what languages people build on top of that assembly.
Elm seems like a neat idea, but based on Paul's post, I dislike the fact that it compiles down to CSS. It seems a disingenuous way to present the language. I'd much rather a browser was simply told this was an application/elm or something and ran with that properly.
"Does anyone think it'd be a good idea for browsers to support more than one toolset?"
Some people do. I do. But it seems to be a minority opinion; most web developers seem to live in this weird cognitively dissonant state where the HTML DOM+CSS is always the right tool for the job because it theoretically allows for platform-independent layout to "any" browser while then spending most of their time dealing with getting their layouts to actually work on about a handful of real-world browsers which all treat the same layout code differently (in ways from subtle to large); resulting in piles of frameworks, pre-processing systems and general hackery to get everything working, mostly, most of the time.
If there were a second toolset that were more rationally designed to solve the real-world problems of modern web apps, giving you layout via binding similar to what you see in Adobe Flex, WPF, Qt/QML, etc (not advocating any of those as the specific answer, just stating that I think they are all individually more sane than HTML/CSS/JS for app/UI layout) and just accepted the fact that the vast majority of websites are designed to be laid-out in a fairly constrained way (while still allowing for responsive layout for different sizes/dpis) I think web technology would be a lot less terrible.
And just to get it out of the way, there are some good hacky solutions that help the problem I described, like React.js, Angular, Dart, etc, but they are all built on a shaky foundation which always manages to show through because we're stuck with HTML/CSS/JS.
I used to believe using something like the tools you outlined would be easier until back in 2004 I spent 6 months porting my naitive windows application to apple. I scrapped the whole thing and started rebuilding on the predecessor to xulrunner, rebuilding mozilla and using XUL was great until I started to need graphing and different fluid layouts that I realized HTML is so much better for cross platform as more people are spending more hours every day making it better on more platforms and devices and it really is write once run everywhere once you move your native app to the server - at the end of the day you are going to spend countless hours tweaking for the different target OSs anyway - the web with HTML / CSS / JS are better at this than any other native solution...
[update] we ported our native c++ components to xpcom interfaces and rebuilt the frontend in 4 months allowing us to launch our product simo health - later purchased by RevolutionHealth 4 months later... I still as recently as 3 months ago receive emails from past customers asking for updates.
More toolsets seems like the wrong way to me. The reason is that browsers barely even keep up with the current ones or even old ones.
Also browsers work because of standards. It's not about the "best", but about agreeing.
Recently I see many people trying to make one suboptimal thing by starting from scratch, removing all standards compatibility, throwing away all the knowledge that went in to a thing to make this one single thing work better, resulting only in incompatibilities, non-standards-conformance and making everything else than that one thing harder or even impossible.
You can see this with web frameworks, with system tools, etc.
Usually this stems from people knowing how to use stuff, but not understanding concepts or why things are the way they are.
This is actually also true for CSS. CSS was meant to support all kinds of output devices, regardless of being graphical or not, support screens in all sizes and nowadays people use it to only really support a low number of "pixelperfect" screen sizes with default settings. Everything else is completely broken.
Nobody even bothers to look at new CSS3 features, new HTML 5 elements (unless it is for SEO), etc. In the end nobody is interested in implementing it correctly which usually results in standards to only slowly advance and having individual vendors only implementing their favorites or even their proposals and experiments, rendering the standard itself unusable, because of it being implemented by one single vendor.
In the end we live in a world where the only thing that's really common inside the infrastructure are hacks to work around those problems.
Most developers hoped this would change after Firefox ate a big part of IEs market share, but currently it seems to be repeating.
Btw. I am not excluding myself from these things. I don't actively work into other directions and basically do the same things.
Before you disagree: If you have something about CSS in your resume. Did you ever even completely read through CSS standards?
Arguably the removal of XLST/XML from the stack of tools browsers support(ed) in favour of JSON/JavaScript (or Anything-including-XML/JavaScript) is a good thing.
I still think there are some good ideas in XML/XLST/SAX/XSD/RELAX NG -- but I think it's clear by now that web developers will not, or cannot, leverage the (rather minor) benefits XML can offer over json/javascript (richer datatypes, mostly -- javascript has gotten so fast that I don't think there's any real benefit to xml+sax over JSON in terms of memory/performance -- so once you throw away all your xml tools as well, there are little benefit remaining).
Generally you can implement pretty much anything else on top of javascript. I do think we could use a better/different rendering model -- having documents/HTML as the base isn't a very good idea. Not sure what the answer would/should be -- seeing how Apple abandoned display postscript, I don't think PDF is the way to go -- perhaps something closer to GL?
I'm a bit of a 90s luddite when it comes to "shiny web apps leveraging javascript for max bling" -- I much prefer gracefully-degrading html+css apps slightly augmented with javascript. But for better or worse, the immediate future clearly belongs to "download code over the internet;run it". Currently we're stuck with js+http+dom as the only real write-once-tweak-for-ever-run-most-places alternative. I think short time success will go to frameorsk like Elm and clojurescript that compile-to-the-browser.
And at the rate of progress we seem to have, I don't think we'll see great platform for delivering apps/objects/runable data in the near future. We appear likely to move the visual basic worms of the 90s to javascript worms of the 10s -- never gaining any decent security or privacy -- because there is no demand for it.
Luckily, well-designed "apps" based on html+css+conserative js can still be great, and have great performance, so I'll try and stick with that, and I'll let everyone else continue to design blogs that can't be read without running "actual" code on the client. For no real benefit (to the user -- to those selling ads/behavioural data the benefits are more tangible, but I'm not a user of that -- I'm just a victim of that).
Function calls and loops seem like a neat idea, but I dislike the fact they they compile down to JMP. It seems disingenuous. I'd much rather the CPU just be told this was a loop and ran with that properly.
The way we got here is interesting. In 1995, if you'd wanted to implement one of today's websites, you might have written a Tcl/Tk script that users could download and run. Tk solved pretty well all the problems people are talking about here in the 90s; it even had a safe mode for running untrusted scripts. But users in the 90s would have regarded as crazy any suggestion that they download and run random Tcl scripts from every site they visited! Lots of them turned off the early versions of Javascript, which couldn't do much apart from formatting tweaks.
Is the killer feature of CSS and Javascript simply that they undermined the frog's security assumptions so gradually that it stayed in the pot until it boiled?
TK finally got native looking skins in what, 8.5? Perhaps a set of attractive defaults combined with a cross platform package management system and we could have been talking.
That said, the web was easy for users. That makes all the difference.
I actually like CSS as it is now, and it's getting better (cough, flexbox). Am I the only one who finds CSS incredibly hard to master, though? I've been writing CSS for years and I still feel like a newbie sometimes, and feel like I'm just tinkering with random attributes until it looks right.
Suppose you want to create the largest possible square div inside the rectangle of another div. Any layout language that can't let me satisfy such a simple and obvious layout constraint is a travesty.
I'm pretty sure FlexBox solves the "Why the hell can't I center these things vertically relative to one another?!?" problem that CSS has had for a very long time. Unfortunately, that wasn't the only problem CSS has had. Now we have to wait for CSS Grids, which look awesome and all, but based on history (floats, positioning, inline-blocks, flexbox) I'm not getting my hopes up that Grids will finally make CSS layouts reasonably adequate. (I'm not even raising the bar to 'usable'.)
agreed. I've been coding for 20+ years now (shit I feel old), 15 or so years of them with HTML and friends and I still throw my hands up in the air every so often when trying to deal with something as simple as getting stuff to show in the right place on a web page. CSS really is hard to master.
Part of that could just be me. I don't really care how it works, I just figure out the smallest amount possible to get what I'm doing to work and leave it at that. Maybe it's the fact that there are many ways to do very similar things, e.g. I can access an element by id or class or another attribute and so I just really need to find one that works and move on to other more "important" parts of the app.
> I've been writing CSS for years and I still feel like a newbie sometimes, and feel like I'm just tinkering with random attributes until it looks right.
This is exactly how I work with CSS too. Not surprisingly, it's my least favorite aspect of web development.
Just like programming, a lot of time can be spent debugging. Also, just like programming, the more systematic your approach, the less time you will spend debugging.
The solution is to stay DRY by applying OOCSS/SMACSS/BEM concepts using Sass/Less.
I don't mean to be rude[0], but what do you find so difficult about it? The box model makes a lot of sense, and once you understand that you're most of the way there. I still Google for less-common syntax (e.g. adding a strikethrough style to text) from time to time, but most of it is internalized by now[1]. Code School[2] was great when I was first ramping up as a developer.
I do also have a great memory[4] for tiny, usually-trivial bits of data like: "no matter the z-index of an element, it cannot overlap an absolutely positioned element (with z-index greater than 0) unless it is also absolutely positioned". It doesn't feel like it's any different than remembering various bits of syntax or APIs, but maybe that's a more difficult thing for some people to remember than others - IANAN[3].
[0] I actually started writing this comment ~15 times before settling on an opening.
[1] It's mostly just abbreviations now: I don't think or speak (or type) "background-color", I just think "bgc<tab>". This is due to the fantastic Emmet plugin for Sublime: http://docs.emmet.io/css-abbreviations/
[2b] I also have an affiliate link if you're feeling generous: http://mbsy.co/7djLz
[3] I am not a neurologist
[4] Terrible short-term memory though - my wife constantly complains about how I can remember "all those coding things" but can't recall what she asked me to do <30 seconds ago.
The motivations behind CSS are good. And the implementation is OK for the most part. But the "usually-trivial bits of data" are examples of it's failings. Let's talk examples:
* You want to overlay a <div> to the bottom write of a container. You can use "position: absolute; bottom: 0; right: 0", but that puts it at the bottom of the page instead. You have to add "position: relative" to the container. Understanding why you'd need this property means understanding implementation details. Which defeats the purpose of being a declarative language.
* You want to float a <aside> to the right of an <article> another. Just add "float: right", to the <aside> right? Whoops, that doesn't work. You'll need to add "overflow: hidden" to the <article> as well. Why should the overflow mode (which really should affect a node's contents) affect the layout of a sibling?
* You have a <header> element which extends the width of a content column. You want it to stay fixed within the page so give it "position: fixed". Now all of a sudden it's forgotten how wide it should be and shrinks to the width of it's content.
* You have a second <header> element with "width: 100%". You make it fixed too. Instead of retaining it's original width -- or shrinking like the other header -- it extends from its original position on the x-axis off the side of the screen so that it's 100% of the width of the page.
Sure, you can learn all of these special rules, but that isn't really a productive use of your time. I work with React a lot, so the approach we use is to create generic layout components that can do all of this stuff in a consistent way.
I'm fascinated that some people here express having no trouble with CSS. I'm inclined to think it's either inexperience with more complex layout, and otherwise just a completely different approach to CSS.
Could you perhaps show some examples of websites that you have built (or send me a message privately if you're not comfortable with that)?
One explanation I can think of is that the more willing you are to stray from the 'separation of content from presentation' rule, the easier things are. Many of the CSS problems I run into would be much easier to solve if I could allow my markup to be informed by the styling, rather than the other way around.
Another possibility is that some of the people who 'like' CSS are also the ones designing the site. They might design with their CSS knowledge as a basis.
In contrast, many of us who struggle with CSS probably struggle more because 1) we try to keep the html 'pure', and 2) we are handed designs by others or don't let ourselves be constrained by our knowledge of CSS.
> "no matter the z-index of an element, it cannot overlap an absolutely positioned element (with z-index greater than 0) unless it is also absolutely positioned"
> my wife constantly complains about how I can remember "all those coding things" but can't recall what she asked me to do <30 seconds ago.
This happens to me all the time. I thought about maybe writing an app that records all the time and then will play you back the last 30 seconds when you press a button.
Probably too resource intensive to be usable though.
For example. I've just found out about flexbox where up until now I thought I'd finally mastered position relative/absolute and floats in order to get nearly everything that I want.
At the beginning html had content, layout and styling. CSS pretty cleanely excised all the styling from HTML. But it took out large part of layout functionality but lots remained. Best way to follow would be to extract layout stuff from HTML (so it can do what it does best, semantically annotate the content) and from CSS (so it can do what it does best, all the pretty colors, decorations and animations) and put it in new language that can define layout elements and bind styling and content to those elements.
A layout engine works on a different level of abstraction, putting layout features in CSS will be awkward. CSS is fine for typographic features and selectors, but layout is all about relationships.
It's meant to provide primitives that are familiar to people from graphic design working on paginated content, like columns, grids, floating containers. Like Latex, it's also has the least-bad-layout strategy, but here, this runs on the client in Javascript, so that it adapts to the screen size.
I had just stopped working on a startup based on this technology. Operationally, it was proving extremely difficult adding effects that people are taking for granted in InDesign to work in a responsive manner on top of CSS and a 20kLoC Javascript layout engine. It took around a year of development just to get to the level of layout automation sophistication comparable to what a junior layout designer would produce.
When I opened this page up, I found a form oscillating violently in Chrome (until the scroll width was adjusted). I'm not sure if that's what you were referring to :)
I like Mr. Victor a lot but I'm not sure I agree. I think the way CSS is implemented either doesn't jive with the paradigms many programmers use to approach problems or perhaps it is just laziness?
I meet a lot of programmers who are generally pretty smart and capable completely throw up their hands when it comes to laying out HTML via CSS. It's just rectangles being displayed on rectangles. It's nothing complex like displaying three or >3 dimensional information on a manifold. I am confident I could layout anything anyone threw at me, and CSS is just something I've picked up over the years.
layouts in CSS are easy while relationships between elements are simple. CSS is a poor solution for layouts that require complex constraints between elements that have no direct child/parent or sibling relationship. Think application layout as opposed to brochure website layout.
Also, CSS is quite silly. Why do I set margin:auto when I want to horizontally center something? The tricks we all learn to muscle CSS into doing what we want require a ridiculous kind of mental gymnastics. Layout should be declarative and separated from simple presentation such as color etc.
Another fault of CSS is its relationship to HTML source order. This makes designs inherently brittle in the sense that simple HTML changes can require a CSS overhaul.
CSS selectors also have their issues. Yes they're powerful and can be used to great effect, but there are holes such as no parent selectors. Here's an interesting proposal that hilights the usefulness of this feature [2]
As soon as we reach the limitation of CSS (and in a complex application layout you'll reach them quickly) then you have to reach for JS and basically create your own little layout engine!
The people developing GridStyleSheets [1] are on to a really good thing. They are working on a JS adaptation of the Cassowary constraint solver (the same one used in Apple's autolayout feature). If you're interested in finding out more, check out their website. They do a good job of illustrating CSS's shortcomings and they have a working solution to address these issues.
I'm with you - I've never understood the confusion about CSS. There are some more complicated tasks than would initially, appear, but once you grok the box model (and it's not hard) then it's pretty easy - and just use a framework for your column layout, no point in trying to reinvent Bootstrap/Foundation/[literally tens of grid frameworks]. Anything else you can't figure out, Google it.
There are some things a designer will throw at you that are very very difficult to achieve in CSS in any regular way (sans non-cross-browser-compatible hacks). But for the most part, CSS isn't too bad.
I've yet to run into those, but then again I am my company's primary designer, as well as implementing whatever I design. Perhaps as a product of that, I don't end up having to code up (m)any ridiculous designs.
I believe that's your answer. When you work with print designers who have moved to web design, but don't know thing 1 about css or html, you get some funky designs.
Really nice designs, but complicated PITAs to actually develop
It's not that it's difficult, really, but the tools are incredibly underpowered. For example:
* How do you vertically center an arbitrary element inside another where you don't know the height of any of them? Answer: The only reliable way is via "display: table-cell". It has several annoying limitations.
* How do you ensure that several horizontally adjacent boxes fill the width of the container and are all of equal height, regardless of their contents? Answer: Table again, but it's not always possible without JS because of how height percentages are calculated. (Also, all browsers including Chrome implement "height: 100%" differently.)
* How, given N elements arranged horizontally next to each other, do you ensure that they (1) fill the width of the container, (2) if they become too narrow (ie. min-width), any element(s) that don't fit will wrap below? (Note: Rule #1 must apply; when one element doesn't fit, the preceding "line" must expand to fit the full width of the container.) Answer: Not possible in CSS alone.
* How do you ensure that an element (eg., an image) of arbitrary width is always has the same height as it's width? (For example, imagine a grid which should expand to fit the window, and all cells should be quadratic.) Answer: With images, possible with an unintuitive "height: 0; padding-bottom: 100%" hack, not for other elements without JS.
* How do you center an absolutely positioned element of arbitrary width and height (think tooltip or speech balloon)? Answer: JS.
* How do absolutely position an element without specifying a width, so that the width becomes the minimum needed to display all of its contents up to a max-width? For example, a box saying "Hello" should take up the space required by that word and no more. Answer: Not possible in CSS alone, although you would have thought that "display: inline-block" would work. Firefox actually does it, Chrome/WebKit don't.
* How do you have an absolute element be the same width as another element? For example, a drop down menu should be at least the width of its menu item, and an autocomplete box should at least be the width of its input box. Answer: JS.
* How do ensure a label is vertically centered on the same text baseline as an adjacent textarea? Answer: Textareas are considered blocks, not text, so you cannot without computing the baseline and using padding or negative margins, and that is imprecise.
These are just a few basic real-world layout challenges. They should not be challenges, they should be simple to implement, but CSS doesn't help; it gets in the way more than it aids. In some cases, inconsistent browser implementations result in wildly different rendering. The result is JavaScript to fill the holes, and sometimes just to say "screw this, I will do in code".
2. Flexbox, setting flex: 1; to the boxes. Can be done vertically or horizontally.
3. Flexbox, setting flex: 1; to boxes. Setting a min-width to a flex-item takes precedence so it will be honored.
4. You got me. I remember hearing talk about an aspect-ratio property. I'm not sure if the object-fit/object-position properties get the job done. The hacks will have to continue for now.
6. width: content-width;? I don't know how the browser support is there, however. It may be possible.
7. Same width as what element? The parent? Set position: relative; to the parent and top: 0; right: 0; to the child.
8. That seems like a real edge case and maybe a bug. I'm not sure.
I hope that I got at least a few of those right but CSS and browsers are consistently getting faster and more powerful and the answer to tricky layouts is increasingly not "just use JS". Flexbox is now supported by all the browsers and solves a whole lot of layout problems that designers/developers have wrestled with.
Flexbox would solve a lot of these, but it's not supported by enough browsers to be usable, afaik. Are people using it in production?
Re #5, I managed to leave out the important part. I mentioned tooltip because I was going to write: ...where the element is placed _above_ another arbitrary element. This is impossible, and raises problems such as escaping "overflow: hidden" and what if the position goes beyond the viewport.
6: In theory, but it is apparently not supported by all browsers.
7: Not the parent, but an arbitrary element. For example, let's say I have an input field. I want to show an autocompletion dropdown box. The box should be at least the width of the input field. It must be absolutely positioned. The parent container of the input field may have "overflow: hidden", too.
(Overflow handling is really a broken concept that screws up a lot of CSS, because there is no way to escape it. Z-index is another awful one.)
Last pet-peeve: Floats depend on their order in the DOM. A float-right element must be placed before any non-float element in order to position itself vertically to be aligned with the parent box.
Right, but flexbox is fairly new. CSS sucked because it made the most common things people want to do really really difficult. Most people gave up and went back to tables because tables give you an understandable grid layout with trivial effort. CSS is just now starting to make the most common layouts easier.
Not seen famo.us before... Pretty much none of the demos work properly on my phone with the stock Android browser and 4.3.. And the amount of flickering in the browser even on my laptop was annoying. Looks to me like they have a long way to go.
The problem with the web is more fundamental: it is trying to simultaneously be two different things. One of these things -- document markup and hypertext linking -- it does pretty well. The other -- a GUI framework for remotely accessed applications -- it does horribly.
Haven't looked at Elm. It may be the cat's pajamas.
But reading this article, I'm immediately reminded of all the marketing surrounding XAML a few years back. Not particularly enamored with the results there.
Poorly-done, abstraction actively gets in the way of combination. At some point, everyone has to agree on the same abstraction if they're gonna work together; enough of CSS has been widely implemented to allow folks to build on that, while plenty of other, richer, more powerful abstractions predate it, but were never widely agreed upon.
I'd say we're getting pretty good mileage out of what we've got? CSS dominates layout for a large portion of overall screen time.
Are native app developers crying for CSS? Not exactly.
The browser window itself is a big layout impediment on the desktop. On mobile, hopefully the browser will just get out of the way, and give the app a decent way to install an icon, and some more "permanent" state.
My concern with people rolling their own layout engines is that they are reinventing the wheel (for the most part). Diverging from standards means learning how to do something I already knew how to do.
Extending CSS with things such as LESS and SASS means I don't have to relearn everything. I just have to learn about the new features that actually bring something to the table.
Html used to have style embedded into it (blink, table, align, font etc).
The idea of separating the style into a css file was born in a time when server side scripts were generating the html (hence the programmers), and the frontenders didn't want to ask for code changes nor code themselves. So they figured that if you could separate the content from the style, they could make changes without talking to programmers.
This didn't always go so well. As you all know, css quite often require wrapping divs and other content tweaks to do its wonders.
Eventually the frontenders gave up and took over responsibility for all the markup, only requiring a CRUD backend.
So now we have separation for no apparent reason. Some argue that it's a great benefit to be able to swap styles by swapping csses, but how often is this really used? And having parallell structures in your code is a known to be costly developer-wise.
If I look at how Bootstrap tries to close that gap by fixing the style of different elements and factor in the fact that all frontenders know how to code and own all the markup I think to myself: why not go back to the old system?
Html5 has already started this trend by giving explicit names to tags instead of calling them "div", "span" or "object". Btw, why have div and span in the contents, the only difference between them is style, right?
I think it's time to consider html a rendering artifact and let style be embedded.
Building eye candy with CSS is lots of fun, and I enjoy it more than in other systems (e.g. UIKit). It's text layout that is ridiculously hard.
E.g. add a second button "calculate totals" under "done", but ensure that they always have the same height if one contains a line break. Maybe it's possible with flexboxes, but no client will let me target IE 10+.
Browsers use DOM whether you like it or not. The rendering engines are built on eventing model. CSS is what they understand now. We can think of changing that, but given the history of browsers and HTML standard, I am not very optimistic that such changes can be pushed through easily in a reasonable amount of time.
"It’s true that in using a language like Elm for layout, one loses the ability to cut and paste random CSS found on Stack Overflow in cargo-cult fashion without understanding what it does. I consider this limitation a feature."
It could have been worded better, but if you consider that people will do this copy-paste out of frustration with the inability of CSS to come up with a reliable, easy to use way of doing layout, which Elm solves, then it's not entirely unreasonable.
I'm not sure using a general-purpose language is the way to go, they do that for Mac/iOS development and it's 1000 times worse than CSS. Now, perhaps the FRP nature of Elm would alleviate the pain, I don't really know.
We have a very fast internet nowadays, so we can include our own CSS engine (written in javascript) inside our webpages. It will rasterize the content into Canvas, it will look the same in all browsers.
I'm wondering how it works in practice, caniuse indicates that it can support all major recent browsers and not having to use a grid library would be nice.
The solution is simple. Let the computer understand the intent of the user (why he needs an interface), and generate a custom interface that exactly fits his needs.
There is no reason to hardcode design. Design should be dynamic, and that goes beyond "responsive" design.
Heck, even a simple card-oriented UI where every model has a manually designed layout would beat whatever we have now.
Unless you're implementing a system that generates UI dynamically based on the data to display, you don't need to touch any low-level GUI code dealing with margins, colors, animations, sizes, etc.
All of this is quite obvious and intuitive. I'm sure it's been tried many times before. Why is it not what we use today?
Because the ui of a website or program is not just an interface, it's also (and quite often primarily) presentation. Visual presentation is a justifiably complex field with a rich history that has taught us that how you present information is often just as important as the information itself. All those colors, animations, etc are an integral part of expressing authorial intent that goes far beyond simple branding.
Arguing that computer ux should solely be driven by the needs of interface without concern for presentation is like arguing that all print media should look like unillustrated pages from a research paper.
What's the purpose of a presentation, and why can't it just be generated?
If colors and animations convey meaning, there's no reason not to include them in the generated UI.
I have used many aggregators that let me use features from a handful of services, and never have I missed the diversity of presentations of all the base services.
> Arguing that computer ux should solely be driven by the needs of interface without concern for presentation is like arguing that all print media should look like unillustrated pages from a research paper.
Unless I don't understand your definition of presentation correctly, and ignoring the absurd idea of avoiding illustrations in a research paper, I don't see a problem with this.
It strikes me that CSS is pretty good, but the mess of hacks that the OP complains of are the result of crappy browser implementations, not crappy CSS?
I really like the point about designers learning to program. It got me thinking that eventually many/most professionals may need a basic grasp of programming. Then it dawned on me; why not teach EVERYONE basic programming in school?!
Heck, teach basic cooking, basic construction, basic plumbing, basic engine repair. Chances are, you're gonna need a basic understanding of all of these eventually... And if nothing else, it's an opportunity to make some aspects of basic mathematics more obviously useful to kids who are struggling to stay interested.
I think you're being downvoted because life isn't just about creating something. Basic accounting is an important tool for any adult living in this world. I would argue the knowledge of managing finances is more important than programming, because it applies to everyone, regardless of your career path.
Debt, loans, mortgages, interest, investments, retirement plans, etc. These are important things for everyone to understand. When I look around, I think a lot of people would be better off if they had a better understanding of finances, but I rarely look at people and think their lack of programming know-how is holding them back.
I have run successful companies and been fine without ever knowing basic accounting.
We are not talking about what is most important we are talking about what is most useful powerful for someone who today is in school and need to have some skills for the future.
Are you seriously telling me that if you had to choose for your kid you would tell them to learn accounting and not programming?
You're missing the point, we're not talking about career paths here, no one is advising anyone to become an accountant over a programmer. We're talking about an introduction to these subjects.
If you had one week to sit down with every person in this world, I think that time would be better spent discussing finances, investments and retirement, instead of an introduction to variables, if/then statements, and loops.
I am not missing the point since I was the one making it.
It doesn't matter what you think would be better what matters is whether programming contrary to accounting can be seen as a language or not and is the reason why it should be taught.
Just putting some arbitrary other field in there is what is missing the point whether that is accounting, CPR, sports, history and so on.
You can put anything in but programming is different since it potentially can contain all the other fields in it's ability to simulate them all.
Quick. Everybody get out their 'web standards' sticks and lets all beat this guy up. The web must be done with standards, otherwise someone might not be able to use some web pages on some device at some point in time, and that is not acceptable.
TL;DR Neither this blog post, the Elm website or Elm's example sites have a good example of something laid out well with Elm (all break horribly badly when resized.) Also, If people actually learned CSS, they would have a much easier time.
Firstly, I find it hilarious that when I opened this blog post dissing CSS the author's 'responsive' design was completely and utterly fucked. I opened the page at 50% width and 100% height on a laptop, and I was confronted with a bunch of unrelated text taking up literally the entire fold. By resizing my browser I found out that the hideous thing taking up my entire browser window was what would be the sidebar if I expanded my browser further. I then go to the Elm website and am presented with a site that's not responsive at all, and I take a look at some "example sites" built with Elm and I get this[0] site, which breaks in a ridiculous fashion when resized. Hell, if you're designing a layout language and you can't even point to one example where it works I'll really start to question it.
Secondly, I think that the vast majority of 'problems' people have with CSS would be solved if people just learnt it as they would a programming language. All the time I hear "CSS is so frustrating!" from people that write code in other languages just fine but don't know CSS. Well, just learn it! Most people don't care about learning CSS, and only copy-and-paste from Stack Overflow. You wouldn't copy-and-paste every single line of code from Stack Overflow for your C++ application, so why do you do it with CSS? I actually took the time to learn CSS a while ago, and it's been much easier to write it since. I have only had one problem in the past few years with CSS specifically: vertical centering and browser inconsistencies. I'd say having only two major problems for a language that's been designed around browser politics is excellent.
> Firstly, I find it hilarious that when I opened this blog post dissing CSS the author's 'responsive' design was completely and utterly fucked.
That kind of proves his point, though. If the foundational layout language for the web requires more than basic effort to create a responsive design, something with it is fundamentally rotten to the core.
> If the foundational layout language for the web requires more than basic effort to create a responsive design, something with it is fundamentally rotten to the core.
CSS is a language. Like Haskell, C++, or Ruby, if you only put "basic effort" into learning it when you try to write some it will be absolute shit.
> CSS is a language. Like Haskell, C++, or Ruby, if you only put "basic effort" into learning it when you try to write some it will be absolute shit.
CSS is not a general purpose programming language. A domain specific language is a failure if the most basic features of the domain cannot expressed with minimum complexity.
THERE'S NO WAY TO CENTER THINGS VERTICALLY WITHOUT FALLING BACK ON HACKS, FOR GOD'S SAKE!
Sure, it's not a general purpose language. As a result, writing decent CSS is easier than, writing, say, decent Haskell. But people have to put some effort into learning it or they'll get crap.
I agree with you entirely re:vertically centering things, but that's one of a very small number of major flaws in CSS.
No, you won't. Designing a layout framework is really, really hard. Designing one that is simultaneously expressive enough to handle all of the crazy corner cases that pop up on a daily basis AND simple enough to allow "normal people" to actually use and extend it is quite difficult. For example, the Android layout system is suitably expressive but totally mystifying to anyone who hasn't spent a year reading the source for View/ViewGroup/FrameLayout/ViewRootImpl.
The OP's suggestion that there is some singular, beautiful, composable layout system that we could drop in to replace CSS is, frankly, a pipe dream. Or rather, I would be far more convinced if he actually pointed to a spec or pre-existing system that we might base our new system off of [1].
I see only three real possibilities going forward, in order of increasing likelihood:
1. Someone does indeed come up with the One True Layout System (very unlikely).
2. We finally shove bytecode-level runtimes into a browser and let a thousand flowers bloom (even odds).
3. We keep incrementally improving CSS, adding support for various layout relationships that people need (probably).
[1] Elm's system looks neat, but it's not there yet.