26 ms·

CSS is unnecessary given a layout language

254 points by mrkibo 12y ago

saraid216 12y ago
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.
- general_failure 12y ago
  Browsers are struggling to support 1 toolset as-is. Imagine the message of multiple tool sets.
  - brandonbloom 12y ago
    Browsers are only struggling because of how complex the toolset is and how poorly defined the expected results are. There are plenty of counter-examples with simple standards and multiple implementations of a high degree of quality and interoperability.
    - recursive 12y ago
      plenty? Let's hear one.
- georgemcbay 12y ago
  "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.
  - taf2 12y ago
    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.
- Aldo_MX 12y ago
  Did someone say Shockwave, Flash, Java, Silverlight, etc.? Or maybe VBScript, JScript, Dart, etc.?
- e12e 12y ago
  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). /rant.
- johnpmayer 12y ago
  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.
- tete 12y ago
  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?
dustingetz 12y ago
So what does it look like to define a layout in elm?
- baddox 12y ago
  http://elm-lang.org/Examples.elm http://elm-lang.org/Examples.elm
- jasonlfunk 12y ago
  This is what he is saying is better than CSS? I don't think so. http://elm-lang.org/edit/examples/Intermediate/Form.elm http://elm-lang.org/edit/examples/Intermediate/Form.elm
  - seanmcdirmid 12y ago
    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 :)
  - mag487 12y ago
    That code is doing a lot more than just layout and styling.
  - CMCDragonkai 12y ago
    Beautiful to me.
  - vidarh 12y ago
    Yikes. Gives me a whole new appreciation for our current stack.
ChrisGaudreau 12y ago
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.
- undozen 12y ago
  I think you are not alone.
- taternuts 12y ago
  > 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.
  - nawitus 12y ago
    This is how everyone I know works like, myself included.
    - ArtDev 12y ago
      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.
      - goldenkey 12y ago
        It's the properties of CSS, and browser quirks that make CSS a pain. Not the ordering and markdown of files.
- Kequc 12y ago
  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.
deleted 12y ago
[deleted]
AdrianRossouw 12y ago
That's basically what I consider [1] famo.us to be. 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/ http://famo.us/ [2] - http://adnanwahab.com/Render-Tree-Visualization/ http://adnanwahab.com/Render-Tree-Visualization/
- vidarh 12y ago
  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.
Rapzid 12y ago
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?!
- sjtrny 12y ago
  What about accounting? Most professionals need a basic grasp of accounting.
  - ThomPete 12y ago
    Accounting is not a language, programming is. You can create anything with programming. Thats why it should be taught. Edit: Care to elaborate why that comment should be downvoted?
    - philix001 12y ago
      Accounting is actually a language. It's the language of finance. You're probably confusing accounting with finance.
      - ThomPete 12y ago
        Accounting HAS a language it is not a language a very limitied one. 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.
    - Throwaway0812 12y ago
      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.
taeric 12y ago
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. Right?
- eru 12y ago
  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.
  - taeric 12y ago
    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. :)
- rbehrends 12y ago
Shog9 12y ago
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.
thisrod 12y ago
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?
- ebiester 12y ago
  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.
adamconroy 12y ago
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.
Lerc 12y ago
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 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.
- MrBuddyCasino 12y ago
  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?
  - Lerc 12y ago
    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.
wavefunction 12y ago
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.
- notduncansmith 12y ago
  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.
  - girvo 12y ago
    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.
    - notduncansmith 12y ago
      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.
      - thisone 12y ago
        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
johnpmayer 12y ago
I think if you strip down this article, it's saying that something could be as powerful as CSS with fewer primitives given more composability.
norswap 12y ago
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.
ender7 12y ago
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.
- seanmcdirmid 12y ago
  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: http://bling.codeplex.com/ http://bling.codeplex.com/ 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).
  - TazeTSchnitzel 12y ago
varkson 12y ago
Yawn, just a typical engineer who can't understand CSS. Go back to the dinosaur languages like C and Haskell and leave the web to the smart guys.
tkubacki 12y ago
CSS seems too complex (and is) because you can't EASILY set boundry for rules in inner elems. This problem is solved by ShadowDOM. It's easier to think in CSS when top level css is only top layout plus theme color setting. Try PolymerJS.
pcwalton 12y ago
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.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- goldenkey 12y ago
  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. http://gridstylesheets.org http://gridstylesheets.org [1]
  - pcwalton 12y ago
    > 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.
    - goldenkey 12y ago
      You are correct. A native solution with a dedicated thread would be amazing.
miguelrochefort 12y ago
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?
- larzang 12y ago
  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.
  - miguelrochefort 12y ago
    I don't get what you mean. 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.
owenversteeg 12y ago
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. [0] http://library.elm-lang.org/ http://library.elm-lang.org/
- _pmf_ 12y ago
  > 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.
  - owenversteeg 12y ago
    > 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.
grey-area 12y ago
CSS is broken. 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.
- buovjaga 12y ago
  In addition to Flexbox, there is the CSS Grid Layout: http://www.w3.org/TR/css3-grid-layout/ http://www.w3.org/TR/css3-grid-layout/ There's a polyfill for it, following the 2012 version used by IE10: https://github.com/codler/Grid-Layout-Polyfill https://github.com/codler/Grid-Layout-Polyfill
- unclebucknasty 12y ago
  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.
owenversteeg 12y ago
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. [0] http://pchiusano.github.io/2014-07-02/css-is-unnecessary.html#comment-1466610097 http://pchiusano.github.io/2014-07-02/css-is-unnecessary.htm...
- andybak 12y ago
  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.
  - GotAnyMegadeth 12y ago
    Sorry for the OT, but, a hammer-wrench-bath-plug is a lot more fun to imagine than a hammer-wrench-bathplug
- WoodenChair 12y ago
  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.
zaroth 12y ago
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.
anuraj 12y ago
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.
jv22222 12y ago
Am I the only one who actually likes CSS? 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-feeling-html5-ios-app http://justinvincent.com/page/2043/anatomy-of-a-native-feeli... But I will admit it has taken 17 years to get to that place.
- gurkendoktor 12y ago
  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+.
Keats 12y ago
Is anyone using Flexbox in production? 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.
strictfp 12y ago
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.
tdj 12y ago
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. Actually, one really impressive engine for web layout engine is Treesaver: https://github.com/Treesaver/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.
asurty 12y ago
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.
jameshart 12y ago
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/middleeast/syria-iraq-isis-rogue-state-along-two-rivers.html 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.
IvanK_net 12y ago
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.
al2o3cr 12y ago
"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." Wow, elitist much?
- mercurial 12y ago
  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.
api 12y ago
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.
scotty79 12y ago
I'd say we still have one language too few. 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.
westiseast 12y ago
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?

254 points by mrkibo 12y ago

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.

general_failure 12y ago
Browsers are struggling to support 1 toolset as-is. Imagine the message of multiple tool sets.
- brandonbloom 12y ago
  Browsers are only struggling because of how complex the toolset is and how poorly defined the expected results are. There are plenty of counter-examples with simple standards and multiple implementations of a high degree of quality and interoperability.
  - recursive 12y ago
    plenty? Let's hear one.
georgemcbay 12y ago
"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.
- taf2 12y ago
  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.
Aldo_MX 12y ago
Did someone say Shockwave, Flash, Java, Silverlight, etc.? Or maybe VBScript, JScript, Dart, etc.?
e12e 12y ago
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). /rant.
johnpmayer 12y ago
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.
tete 12y ago
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?

dustingetz 12y ago

So what does it look like to define a layout in elm?

baddox 12y ago
http://elm-lang.org/Examples.elm http://elm-lang.org/Examples.elm
jasonlfunk 12y ago
This is what he is saying is better than CSS? I don't think so. http://elm-lang.org/edit/examples/Intermediate/Form.elm http://elm-lang.org/edit/examples/Intermediate/Form.elm
- seanmcdirmid 12y ago
  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 :)
- mag487 12y ago
  That code is doing a lot more than just layout and styling.
- CMCDragonkai 12y ago
  Beautiful to me.
- vidarh 12y ago
  Yikes. Gives me a whole new appreciation for our current stack.

ChrisGaudreau 12y ago

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.

undozen 12y ago
I think you are not alone.
taternuts 12y ago
> 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.
- nawitus 12y ago
  This is how everyone I know works like, myself included.
  - ArtDev 12y ago
    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.
    - goldenkey 12y ago
      It's the properties of CSS, and browser quirks that make CSS a pain. Not the ordering and markdown of files.
Kequc 12y ago
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.

deleted 12y ago

[deleted]

AdrianRossouw 12y ago

That's basically what I consider [1] famo.us to be. 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/ http://famo.us/ [2] - http://adnanwahab.com/Render-Tree-Visualization/ http://adnanwahab.com/Render-Tree-Visualization/

vidarh 12y ago
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.

Rapzid 12y ago

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?!

sjtrny 12y ago
What about accounting? Most professionals need a basic grasp of accounting.
- ThomPete 12y ago
  Accounting is not a language, programming is. You can create anything with programming. Thats why it should be taught. Edit: Care to elaborate why that comment should be downvoted?
  - philix001 12y ago
    Accounting is actually a language. It's the language of finance. You're probably confusing accounting with finance.
    - ThomPete 12y ago
      Accounting HAS a language it is not a language a very limitied one. 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.
  - Throwaway0812 12y ago
    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.

taeric 12y ago

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. Right?

eru 12y ago
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.
- taeric 12y ago
  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. :)
rbehrends 12y ago

Shog9 12y ago

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.

thisrod 12y ago

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?

ebiester 12y ago
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.

adamconroy 12y ago

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.

Lerc 12y ago

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 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.

MrBuddyCasino 12y ago
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?
- Lerc 12y ago
  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.

wavefunction 12y ago

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.

notduncansmith 12y ago
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.
- girvo 12y ago
  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.
  - notduncansmith 12y ago
    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.
    - thisone 12y ago
      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

johnpmayer 12y ago

I think if you strip down this article, it's saying that something could be as powerful as CSS with fewer primitives given more composability.

norswap 12y ago

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.

ender7 12y ago

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.

seanmcdirmid 12y ago
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: http://bling.codeplex.com/ http://bling.codeplex.com/ 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).
- TazeTSchnitzel 12y ago

varkson 12y ago

Yawn, just a typical engineer who can't understand CSS. Go back to the dinosaur languages like C and Haskell and leave the web to the smart guys.

tkubacki 12y ago

CSS seems too complex (and is) because you can't EASILY set boundry for rules in inner elems. This problem is solved by ShadowDOM. It's easier to think in CSS when top level css is only top layout plus theme color setting. Try PolymerJS.

pcwalton 12y ago

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.

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
goldenkey 12y ago
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. http://gridstylesheets.org http://gridstylesheets.org [1]
- pcwalton 12y ago
  > 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.
  - goldenkey 12y ago
    You are correct. A native solution with a dedicated thread would be amazing.

miguelrochefort 12y ago

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?

larzang 12y ago
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.
- miguelrochefort 12y ago
  I don't get what you mean. 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.

owenversteeg 12y ago

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. [0] http://library.elm-lang.org/ http://library.elm-lang.org/

_pmf_ 12y ago
> 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.
- owenversteeg 12y ago
  > 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.

grey-area 12y ago

CSS is broken. 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.

buovjaga 12y ago
In addition to Flexbox, there is the CSS Grid Layout: http://www.w3.org/TR/css3-grid-layout/ http://www.w3.org/TR/css3-grid-layout/ There's a polyfill for it, following the 2012 version used by IE10: https://github.com/codler/Grid-Layout-Polyfill https://github.com/codler/Grid-Layout-Polyfill
unclebucknasty 12y ago
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.

owenversteeg 12y ago

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. [0] http://pchiusano.github.io/2014-07-02/css-is-unnecessary.html#comment-1466610097 http://pchiusano.github.io/2014-07-02/css-is-unnecessary.htm...

andybak 12y ago
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.
- GotAnyMegadeth 12y ago
  Sorry for the OT, but, a hammer-wrench-bath-plug is a lot more fun to imagine than a hammer-wrench-bathplug
WoodenChair 12y ago
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.

zaroth 12y ago

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.

anuraj 12y ago

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.

jv22222 12y ago

Am I the only one who actually likes CSS? 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-feeling-html5-ios-app http://justinvincent.com/page/2043/anatomy-of-a-native-feeli... But I will admit it has taken 17 years to get to that place.

gurkendoktor 12y ago
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+.

Keats 12y ago

Is anyone using Flexbox in production? 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.

strictfp 12y ago

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.

tdj 12y ago

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. Actually, one really impressive engine for web layout engine is Treesaver: https://github.com/Treesaver/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.

asurty 12y ago

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.

jameshart 12y ago

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/middleeast/syria-iraq-isis-rogue-state-along-two-rivers.html 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.

IvanK_net 12y ago

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.

al2o3cr 12y ago

"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." Wow, elitist much?

mercurial 12y ago
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.

api 12y ago

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.

scotty79 12y ago

I'd say we still have one language too few. 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.

westiseast 12y ago

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?