11 ms·
Incomplete List of Mistakes in the Design of CSS
- Cshelton 11y agoThis doesn't even get to the overall design of css in the first place and the problems it has... http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...
- Turing_Machine 11y agoThe whole idea of using (at least) three separate languages (HTML, JavaScript, CSS) would seem weird if it were proposed de novo. Consider that LaTeX manages to carry out all of those functions (layout, styling, and computation) using only one language.
- stream_fusion 11y agoReact and jsx constructed dom using inline-styles brings the disparate technologies together in a composable way.
- Touche 11y agoBut without cascading, the whole point of css.
- wodenokoto 11y agoIn your latex equation, you are missing where the data goes. The idea for html/css/js is that data goes into the html, layout and styling into CDs and interactivity is defined in JavaScript. That makes sense. The problem is that we never got anything close to that.
- TheOtherHobbes 11y agoThe problem is it doesn't really make sense in 2015. Or rather, it only makes sense if you accept the technical debt inherited from HTML, which is itself the simplified stepchild of SGML, which was a 1960s idea and firmly rooted in paper publishing. Separating content and presentation isn't a bad idea. The badness happened because JavaScript - or some other web programming language - didn't appear until HTML was established. So instead of a generic object model, with tagged content containers linked to an updatable library of presentation and layout code that could be standardised and refined continuously, some semi-standard version of a sort-of-working layout library was pre-compiled into browsers and accessed through a not very coherent DSL. This made it fast enough to be usable - a very good thing, given 1990s processing speeds - but it also made it much harder to develop and fix. In 2015 CSS shouldn't really be necessary. So much layout and presentation is done with JavaScript anyway that it would make just as much sense to get rid of CSS and extend and standardise on something like jQuery-but-better to create an evolving cacheable layout library that bypasses browser quirks and uses exactly one common versioned codebase. This might seem ambitious, but writing good code that works across all common browsers now is such a nightmare for everyone that too many devs are either not bothering, or their bosses are telling them not to bother because it's too expensive. As a user, I keep finding sites that simply don't work in Chrome or Safari or IE or whatever. That's not good, especially when there's a business at the other end trying to sell things. I don't doubt the web will creak along, and some people will do amazing things. But it's still frustrating when it could be simpler, more standardised, more consistent, and much more reliable.
- gopowerranger 11y agoAs a web dev of 11 years, I don't find writing cross browser code a nightmare. And any web site that doesn't work cross browser is by amateurs at best. I don't know what web sites you visit where you have such issues but I haven't seen them in years except for the occasional goofball site.
- Ygg2 11y agoAs someone that had to support IE6 and Chrome at same time, I can't agree with this statement.
- Turing_Machine 11y agoHmm... I don't see any conceptual reason why separating those things should require completely different languages, though.
- wodenokoto 11y agoNobody bats an eye when you use Python for logic, sql for querying your database and regex for searching text. Unlike the front end, there are ample opportunities for "uniting" the backend in one language, yet nobody really seems to bother. I speculate that it's because these languages are better at certain things, just like having a non-executable language for data, helps keep the data, data only (cue angry lispers), and facilitates easier writing of prose in a mark-up language than a real programming language could facilitate. Just look at markdown. More over, we invented JSON, rather than just sending JS files between browser and server.
- afarrell 11y ago> Nobody really seems to bother I prefer writing queries using Django's ORM even though it is underpowered.
- wodenokoto 11y agoYeah, I guess I as a little hyperbolic :)
- h1762581 11y ago>that data goes into the html It's more like static content goes into the html, dynamic content goes into JSON.
- afarrell 11y agoAlthough LaTeX needs much better error messages.
- A_COMPUTER 11y agoXML to the rescue! The alternate future of the web! XML + XSLT (stylesheet)-> XSL:FO (intermediate XML language for formatting) -> FOP (program to convert formatting objects to output) -> rendered format. XML all the way down! (One mistake, zero output.)
- TabAtkins 11y agoAs a very busy CSSWG member... I agree. There are a number of benefits to the current structure, but I highly suspect that if the web were invented today, styling would a JS-mediated aspect of the DOM, not something fully separate like it is today.
- davidkpiano 11y agoThose aren't problems with CSS - those are problems with how Facebook architected _their_ CSS. A lot of those don't apply to well-architected projects.
- olavk 11y agoThese seem to be problems with Facebooks architecture rather than general CSS problems. For example they claim you have to use "global variables" like in the selector ".button-depressed". But you could just use ".button.depressed", thereby scoping the depressed-class.
- mschuster91 11y ago> Box-sizing should be border-box by default. Didn't older versions of IE do precisely that, leading to endless frustration? I hate to say it but MS did something right for once.
- audessuscest 11y agoI think you're wrong IE didn't do that
- wereHamster 11y agohttps://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug https://en.wikipedia.org/wiki/Internet_Explorer_box_model_bu... The old IE old model is exactly box-sizing:border-box;
- wvenable 11y agoKind of an interesting history: https://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug https://en.wikipedia.org/wiki/Internet_Explorer_box_model_bu...
- gopowerranger 11y agoNot exactly. The W3C spec stated the box model should work one way and everyone but Microsoft/IE did it that way. This is a new part of the spec which didn't exist back then. However, since IE had 95% market share, everyone marked up their site according to Microsoft's model instead of the W3C. It's affectionately called "quirks mode" and really screwed people up, remnants of which I still see today.
- userbinator 11y agoMS thought the spec was wrong and the W3C actually intended the more logical model, thus following that assumption when they implemented IE; and why the W3C didn't change the spec, or why other browsers didn't follow, is I think more of a political issue.
- 11y ago
- alsonote 11y ago> white-space: nowrap should be white-space: no-wrap and line wrapping behavior should not have been added to white-space > word-wrap/overflow-wrap should not exist. Instead, overflow-wrap should be a keyword on 'white-space', like nowrap (no-wrap) Well, which is the mistake?
- bsimpson 11y agoIt's so broken that you can only use text-overflow: ellipsis if you've also set white-space to nowrap.
- TabAtkins 11y agoBoth, either. ^_^ Having wrapping behavior split the way it is today is wrong - either all of it should be in white-space, or none of it should be. (Moving it all out into a separate property is probably best, so white-space can keep just being about white-space itself.)
- dmux 11y agoComplete list of mistakes in the design of CSS: 1. CSS
- okonomiyaki3000 11y agoWhen do we get to throw the whole thing out and start again?
- mey 11y agoWhen something replaces HTML holistically and isn't locked into a single vendors solution. So, probably not ever.
- Eric_WVGG 11y agoI always found it interesting that style tags were designed as <style type="text/css">, implying that new style standards could be introduced down the road. (for a while I thought <script type="text/dart"> might get real… oh sweet naivety)
- gopowerranger 11y agoThe script type is a possibility but you have to make it work. I've forgotten the details.
- toyg 11y agoSince the browser will not react to these nodes, you can add some JS code that will detect them and hand off content interpretation to other mechanisms.
- bsimpson 11y agoThat's how React's JSXTransformer worked. You can also do the same for WebGL shaders: <script type = "x-shader/x-fragment"> … </script>
- antod 11y agoBack in the day, IE4 supported both javascript and vbscript. And from memory if you installed other eg ActivePerl (and ActivePython too I think), you could use them as well.
- 11y ago
- mlvljr 11y agoreminds of http://www.raizlabs.com/graiz/2006/09/25/ten-reasons-why-css-sucks/#c2781668516785481840 http://www.raizlabs.com/graiz/2006/09/25/ten-reasons-why-css... (note the poster's name) and what he suggests reminds QML a lot, btw :)
- NickHaflinger 11y agoWhy do keywords have to end in a colon. couldn't the parser use space " " to detect the end of a word, like in C ..
- TazeTSchnitzel 11y agoC requires explicit = in variable declarations. CSS presumably uses the colon for clarity.
- gopowerranger 11y agoCSS is text files and there are no line endings.
- deleted 11y ago[deleted]
- TabAtkins 11y agoI assume you mean property names, because keywords are all over the place and don't have anything to do with colons. It's just a separator between the two semantic halves of a declaration. It could just be a space, but it wouldn't be quite as obvious. Compare "display block;" to "display:block;" It wouldn't save characters, either - you can omit spaces around the colon today and have the same number. That is, "display block" and "display:block" are both 13 chars. There is indeed nothing requiring a colon vs a space, as the grammar is unambiguous either way.
- kayamon 11y agoThis doesn't even address the fundemantal design flaw with CSS: (paraphrased badly from a quote by Casey Muratori) Layout is about the relationship between TWO THINGS. If you have a layout language that deals with only one thing at a time, then you have failed.
- hayksaakian 11y agoHtml is tree structures right? Every element is default positioned relative to the previous element.
- kayamon 11y agoUh, yes, I guess? That by itself is not especially useful. That's not what a layout language is for. A layout language needs to be able to specify "A goes 10 px to the left of B".
- est 11y agoUnless if you think about it, layout is positioned in a 2D plane (with z-index, it's a 3D space, don't mention time), not a tree structure at all.
- applecore 11y agoExcept a tree structure is the only conceptual model that works for composing a user interface (out of simple, largely stateless components). See, for example, React and JSX.
- wavefunction 11y agodefault is "statically," if I may be so <strong>
- epidemian 11y agoOn a similar note, i think this Bret Victor quote captures the frustration of the CSS experience very well: "CSS, a language for specifying visual appearance on the web, is … so complex that it has never been implemented correctly; yet, successive versions specify even more complexity. At the same time, it is so underpowered that many elementary graphic designs are impossible or prohibitively difficult, and context-sensitivity (or anything computational) must be addressed externally. Most CSS lore is dedicated to describing the tangles of brittle hacks needed to circumvent incompatibilities or approximate a desired appearance." http://worrydream.com/MagicInk/#p255 http://worrydream.com/MagicInk/#p255
- leeoniya 11y agoanother one not on the list is that any padding specified in % is always % of width. though this oddity/hack allows to responsively & proportionally scale images and backgrounds.
- kagamine 11y agoHonest question, what else could it be a %age of? Or should % not be an allowed unit of measurement of width?
- IgorPartola 11y agoHeight?
- kagamine 11y agoOh, right I see now, padding-top: 5%; is a %age of the width, not the height of the element. Yes, that makes little sense.
- andrewmcwatters 11y agoThe term "blend mode" specifically refers to color blending. It isn't just "blending" nor does the addition of the word "mode" at the end of the property indicate some sort of redundancy in the attribute name. This single slip up as an indicator of the author(s) not being familiar with a particular graphics industry term makes me question the validity of every other claim of "mistake" on the page. > rgba() and hsla() should not exist, rgb() and hsl() should have gotten an optional fourth parameter instead (and the alpha value should have used the same format as R, G, and B or S and L). Absolutely not. RGB is not RGBA. Perhaps the lack of robust rendering of webpages across most browsers is due to standards bodies, even lesser ones like csswg, not knowing anything about the fundamental graphics layers powering them.
- TabAtkins 11y agotrolololol The term "blend mode" is a term of art in the industry, yes. But "mode" is always redundant - lots of properties switch "modes", particularly the ones with keyword values. For example, we could have had "display-mode" rather than "display", but that would definitely have been redundant. The word "blend" isn't used for anything else reasonable in CSS's wheelhouse, so using it by itself would have been fine. I'm not sure what difference you think you're alluding to between RGB and RGBA. All browsers store colors as RGBA 4-tuples. Are you perhaps under the impression that "RGB" and "RGBA" refer to particular color spaces or something? They don't - nearly all color spaces are alpha-agnostic and can have an alpha value appended to their color definition. (The few exceptions are things like pre-multiplied RGBA, where the RGB components depend on the alpha. But these are rare) Given that the CSSWG's membership is largely browser implementors, I'm pretty sure we have a handle on what the fuck our graphics stack does.
- andrewmcwatters 11y agoEvery argument you made you counter-argued using my own points within your own post. 1. > The term "blend mode" is a term of art in the industry, yes. 2. > For example, we could have had "display-mode" rather than "display", but that would definitely have been redundant. 3. > The few exceptions are things like pre-multiplied RGBA, where the RGB components depend on the alpha. But these are rare. Yes, because RGB isn't RGBA. If anything it should be RGBA with an optional alpha. Because you know, that's how the _structs are formed to begin with._ And separately, > Given that the CSSWG's membership is largely browser implementors, I'm pretty sure we have a handle on what the fuck our graphics stack does. Yes, as far as the people who actually write the portions of browser code that involve placing pixels on the screen. You however, clearly do not. I'm not sure what you're doing in a spec committee; you don't sound like a person who has any experience writing low level code regarding these systems. Given this, it's worrying because I'd wager that you'd make uneducated decisions affecting others based on this lack of experience.
- xienze 11y agoAll that and nothing about variables?
- kagamine 11y agoI find myself often wishing conditionals on CSS until I remember that they aren't necessary because things like input[type="submit"]{} exist (but feel hacky as can be) and that if they did exist I would never, ever want to edit someone else's CSS file. Can you imagine the mess? It would be nice not to have to look for a style: 1. inline html 2. in the CSS file(s) 3. in JavaScript (or js library) 4. in the source code in the backend to find that one edit you need to make. I think that limitation is the most frustrating, that because CSS cannot 'see' beyond its own little home it bleeds out into other documents.
- TabAtkins 11y agoWe have variables now <https://drafts.csswg.org/css-variables/> https://drafts.csswg.org/css-variables/> so it's not a mistake that needs a time machine.
- multinglets 11y agoI can't help but wonder if the vertical margin collapsing (in general) would have seemed worth it if we weren't borrowing concepts from print media.
- TabAtkins 11y agoIt is, still. You want separation between your paragraphs and other elements; you don't want the first and last children of a box to be separated from the edges of that box. Margin-collapsing does that (sibling boxes collapse margins together, first/last collapse with parent and shift their margins "out"), but it's difficult to do otherwise. That said, you could do one-sided margins better if we hadn't had naked text in the layout model. If everything was wrapped in elements, then text at the start of a container element wouldn't require a margin-top on the first child element, while text at the bottom wouldn't require margin-bottom on the last child element. Naked text is a mistake. (And I just added it to the list. ^_^)
- toast0 11y agoI guess I was expecting a table.
- RandyRanderson 11y agoIt would be shorter to list what is good about CSS. I mean, other than it's there on the browser, is there anything else?
- _ZeD_ 11y agoit's not a css mistake, per se, but I always found difficult to reason about a way to tell "I don't really care how big this widget is, I care that this widget should be a rectangle with sizes of ratio X"; I want to be able to make a container, put a square on the top left, a 16/9 rectangle on the center and so on...
- TabAtkins 11y agoYeah, setting an explicit aspect-ratio is on the roadmap. The relevant people (me and fantasai) have too many other layout-related things on our plate atm to deal with it, but it'll show up in the next year or two.
- Oduig 11y agoIf you ask me, a layout language should have simple orthogonal concepts in it. The reason CSS gets so much hate is, in my opinion, a lack of coherence, a lack of modularity and terrible naming choices. You only have to look at vertical centering to see the problem. Situations that look almost the same require entirely different solutions, often causing a change to ripple through to parent/child/sibling elements.
- TabAtkins 11y agoYup, that's the problem with having a language that evolved slowly over 20 years, while its problem space changed enormously. CSS was originally intended as a simple way of styling text documents on the web. We're trying to fix vertical centering, at least. The alignment properties from the Align spec <https://drafts.csswg.org/css-align/> https://drafts.csswg.org/css-align/> do consistent centering (and other alignment) across layout modes. Currently they only work in Flex and Grid, but they're defined to work in Block and Abspos as well.
- kagamine 11y agoIf I had to pick a favorite it would be: > descendant combinator should have been » and indirect sibling combinator should have been ++, so there's some logical relationships among the selectors' ascii art Now, where do we stand on the omition of a parent selector? I've seen it mentioned over the years that CSS lacks an all important parent selector, eg: ul << #myDiv where the html would appear thus: <div id="myDiv"><ul>...</ul></div> This goes against the entire idea of a cascade. But with frameworks and templates all over the web it isn't always possible to define the parent tag yourself, or assign it an ID/class. For example, I use a framework that generates html from xml documents, I can't add a class or ID to the parent html tag, a parent element selector would be of value here. My concern would be that it is open to abuse.
- TabAtkins 11y agoCSS selectors always select "down the tree". Or, read in reverse (from right to left), evaluating them only requires information from further up the tree. In HTML, "further up the tree" corresponds exactly to "earlier in the text stream". This means that as soon as an element finishes parsing, we can find all the selectors that apply to it immediately, enabling better incremental display. Of course, that's no longer always true today. In particular, selectors like :nth-last-child() depend on information from later siblings. Defining a combinator or equivalent mechanism that allows direct selection based on later siblings is thus not out of the realm of possibility. And selecting a parent vs an earlier sibling is almost identical - the parent's start tag is immediately prior to the first sibling (or text), so the distance between "thing you're selecting" and "thing it needs to know about to evaluate the selector" is only incrementally larger. So a way of selecting a parent based on children is probably fine too. There are a few issues that have prevented us from doing so today. For one, it's slow. Using a single one of the "backwards" sibling pseudo-classes can kick your entire page into slow-selector mode, because it breaks optimizations. The same would be true of parent selectors, probably. For two, we have to prevent nesting - siblings usually aren't too far from each other, but the root can be very far from a descendant. (Also, siblings are usually walkable by traversing an array, while parent/descendant relationships are typically pointer-based and slower to traverse.) This makes it a bit clumsy to specify. That all said, it's on the roadmap. I plan for it show up in Selectors 5. (Oh, and note, the "cascade" in "Cascading Style Sheets" isn't about what you're referring to. It's about a "cascade" of values for a given property colliding on a single element, and figuring out which one "wins". Thus the Cascade module <https://drafts.csswg.org/css-cascade/> https://drafts.csswg.org/css-cascade/>. It's not the best name, but we're stuck with it. ^_^)
- randomsearch 11y agoThis is a totally crazy out-there idea, so be kind: Rather than trying to create a layout system that can adapt to any window or screen size, as with CSS/HTML, Java, iOS, etc., what if instead we had settled on a small number of permitted aspect ratios for screens? I'm carrying the analogy from paper sizes: A4, A5, A1, etc. So probably we would have gotten this wrong when we first defined them (see iPhone aspect changes), but presumably after a while they settle down and then we can stop testing for the old aspect ratios. Monitors, laptops, tablets, phones, would all standardise to a set of options just like most books and magazines standardise to a given size. I know there are downsides, but imagine how much easier this would be for designers. Cross-platform UI design would be much simpler. Just a radical thought I had.
- Achshar 11y agoAspect ratio isn't every thing in design. The size of the window is just as important. A 3x2 21" screen needs very different UI approach than a 3x2 3" screen. And standardizing screen sizes is not really a sensible option.
- randomsearch 11y ago> Aspect ratio isn't every thing in design. The size of the window is just as important. A 3x2 21" screen needs very different UI approach than a 3x2 3" screen. Good point. I was thinking more along the lines of the fact that design tools and tech that enable adapting to an arbitrary screen size are unlikely to be as easy to use and expressive as those targeted for a specific aspect ratio (for example, you could use absolute positioning). > And standardizing screen sizes is not really a sensible option. Suspend disbelief for a moment, or consider only from the POV a single large corporation / group (e.g. Apple or Android).
- Achshar 11y agoIt's really about the burden of the effort, it can either be easy for the users and a pain for the developers or it can be the other way around. We can standardize the ratios and sizes and that would make things easy for devs sure but then that would decrease the variety and innovation for the user. If there really were a handful of fixed sizes and ratios then that would make things like google glass, smart watches, galaxy edge or any other kind of unconventional device with non standard display that much more difficult to ship to the masses. We don't know what kind of display size and aspect ratio the next contact lens display or the next building sized display will have. So I believe it's better to keep our self open to new possibilities.