CSS is unnecessary given a layout language
pchiusano.github.io
pchiusano.github.io
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.
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).
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.
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.
[1] Though I haven't used Flexbox in earnest yet.
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.
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
Solving LP is fast, especially when many of your constraints are equality constraints (as would be when specifying tables).
[1] https://www.cs.washington.edu/research/constraints/cassowary...
[2] https://developer.apple.com/library/ios/documentation/userex...
(different paper formats, two columns, two pages per one landscape paper, four pages per one portrait paper... all with the same content)
In practice, people bet the farm on CSS....
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.
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.
asm.js and PNaCl are here today. What more are you expecting?
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.
There's a polyfill for it, following the 2012 version used by IE10: https://github.com/codler/Grid-Layout-Polyfill
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.
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.
http://www.smashingmagazine.com/2011/12/12/an-introduction-t...
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! :)
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.
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.
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.
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.
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.
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.
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.
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.
Still trying to solve this pain.
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.
[0] http://pchiusano.github.io/2014-07-02/css-is-unnecessary.htm...
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 can also try to pick up a newspaper (multicolumn) and try to replicate its layout so it behaves well with dynamic content.
The problem is trying to do that for every browser.
Doing both of those things in IE6 is hard.
To me, IE6 is broken, CSS isn't.
However, most clients actually pay an extra to have us support IE7 - 8. On responsive websites. With plenty of customization and fancy graphics.
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?
"You can't be bothered to learn your tools" isn't terribly helpful when you've just given someone a hammerwrenchbathplug.
I don't have that problem with any other part of the stack I use for web development.
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.
Right?
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>
floating_figure(...)
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(...)
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.
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.
More: http://redd.it/256lxu
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.
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. :)
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.
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.
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 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.
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.
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.
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'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.
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.
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.
[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.
There are plenty of counter-examples with simple standards and multiple implementations of a high degree of quality and interoperability.
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?
Or maybe VBScript, JScript, Dart, etc.?
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).
/rant.
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?
That said, the web was easy for users. That makes all the difference.
CSS will not let you do this, even with flexbox.
Am I misinterpreting what you mean?
Yes. The red one should be a rectangle and the green one a square. In your case the red one is also a square.
FlexBox always felt like it was a direct response to a few specific cases rather than a generalized gain in flexibility.
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 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].
Give Code School a shot (go through the whole CSS Cross-Country course). You can get a 2-day free trial here: https://www.codeschool.com/hall_passes/213f3fedb6b9/claim_sh....
[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/
[2] https://www.codeschool.com/
[2a] You might be specifically interested in https://www.codeschool.com/courses/css-cross-country
[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.
* 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.
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.
Just some thoughts...
FYI: this is incorrect. https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Under...
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.
This is exactly how I work with CSS too. Not surprisingly, it's my least favorite aspect of web development.
The solution is to stay DRY by applying OOCSS/SMACSS/BEM concepts using Sass/Less.
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.
Actually, one really impressive engine for web layout engine is Treesaver: https://github.com/Treesaver/treesaver
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.
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.
* 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.
5. left: -50%; and margin-left: 25%; will work. See: http://codepen.io/bennettfeely/pen/LktDi
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.
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.
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.
[1] http://gridstylesheets.org/ [2] http://shauninman.com/archive/2008/05/05/css_qualified_selec...
Really nice designs, but complicated PITAs to actually develop
Instead of using css for the layout/positioning, just use javascript directly.
and then build a [2] proper scene graph in javascript.
[1] - http://famo.us/ [2] - http://adnanwahab.com/Render-Tree-Visualization/
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.
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.
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.
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.
I tend to find can do pretty much any design that I've been tasked with without using graphics.
For example: http://justinvincent.com/page/2043/anatomy-of-a-native-feeli...
But I will admit it has taken 17 years to get to that place.
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+.
Wow, elitist much?
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.
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?
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's easier to think in CSS when top level css is only top layout plus theme color setting. Try PolymerJS.
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.
Thats why it should be taught.
Edit: Care to elaborate why that comment should be downvoted?
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.
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?
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.
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.
You can't simulate the world in 3d with accounting, you can't create digital maps, program airplanes, music applications, steering and so on.
With programming you can simulate more or less anything you want even accounting software.
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.
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.
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!
I agree with you entirely re:vertically centering things, but that's one of a very small number of major flaws in CSS.