Hacker News new | comments | ask | show | jobs | submit login
Incomplete List of Mistakes in the Design of CSS (csswg.org)
196 points by zdw 3 months ago | hide | past | web | favorite | 150 comments



I don't think things like syntax and schemes are the real bad parts. The real bad part is that CSS is in no way designed to be interacted with by anything but CSS.

Just yesterday I was making a music player position bar, and using CSS transitions to have it smoothely update itself. Set the duration of the transition and it goes on.

But what about when the transition takes effect? JS doesn't know when a style is actually updated and can then have a new property overwriting it to make the transition happen. If you do properties too quickly the transition won't happen. Such as if a user clicks on the bar to change the position, I have to hack in a 100ms setTimeout to set the new transition duration after stopping the transition with transition:none;

Why can't I control a transitions location? Chrome's animation viewer can go back and forth in time easily.

Why isn't interactivity seperate from CSS? CSS elements cannot effect those outside of its scope. You require JS for just dumb simple things that should be natively supportable. For instance you can make CSS do things based upon URL hash names like #somename, but you can't set them in CSS. You can't change attributes on elements, or classes or anything like that.

I think we've gotten to the point where JS is the 'programming language' of a webpage that has intentions far beyond rendering and interactivity. Perhaps we need a newer kind of CSS that's made for dynamic interactions. That way great UI's can be built in a safer css-like environment.


Yep yep. CSS in JS removes some of the pain points but still, fundamentally, CSS cannot communicate with JS in a universal, elegant way. Honestly, CSS in general is awful. How did we only just get decent centering with flexbox? How is flexbox still inconsistent across browsers? (Try setting a child of a flexbox container to 100% height.) The days of needing separate constructs because of bandwidth are over. We need something to unify CSS and HTML and JS into a UI builder that doesn't make you want to tear your hair out when you have to center a div over another div and give it an animation.


> Try setting a child of a flexbox container to 100% height.

Isn't this the default?

   align-items: stretch
--- https://css-tricks.com/snippets/css/a-guide-to-flexbox/

> The days of needing separate constructs because of bandwidth are over

That wasn't the reason for stylesheets. It was for ease of changes. For example, to change the color of the headings on all of your HTML pages, you would change just the stylesheet. This was when each web page was a static HTML file. Few websites used programming languages to render pages. So the benefit today is less.

But I guess if you don't care about that nor bandwidth then you can use inline style attributes.


https://stackoverflow.com/questions/33636796/chrome-safari-n...

I'm referring to this. Got bitten by it recently.

> That wasn't the reason for stylesheets. It was for ease of changes. For example, to change the color of the headings on all of your HTML pages, you would change just the stylesheet. This was when each web page was a static HTML file. Few websites used programming languages to render pages. So the benefit today is less.

Interesting, I didn't know that. Still, CSS doesn't make a whole lot of sense to me. Here's a bunch of global state, some of which is hidden in gigantic minified files, now edit it!


Back when CSS was useful for changing the color of all your headlines without changing all your HTML, it wasn't delivered in giant minified files, it was a couple dozen lines written by hand.


>Here's a bunch of global state, some of which is hidden in gigantic minified files, now edit it!

Well, there's your problem. I'd recommend reading about things like atomic css, BEM, OMACSS, etc.


That's why I use CSS in JS :D. But we're just putting abstractions/stopgaps over a fundamentally flawed design. Not to mention, since everybody uses a different standard for isolation, CSS in JS is not compatible with BEM is not compatible with SASS, etc.


CSS was originally designed with the idea that you would have one css file for your whole site, and it would be maybe 300 lines max.

We've obviously gone well off the rails. Selector specificity was supposed to be the scoping mechanism. And it works great in the original envisaged usescase: a single person making a single website. it just doesn't scale to large teams, and ancient software projects, with complicated layouts.


It never worked well in the original envisaged usecase. CSS 1 didn’t work properly with tables which meant I used to have to inline style attributes for tables as well as set a CAS file. It’s always been garbage for centering things, in the early days that meant using the <center> tag. Then you have all the different browser extensions (o-, mo-, etc) the inconsistent preferences for font-face, etc.

CSS was a great idea but it’s always been a garbage execution of that with no single browser following the spec correctly for years then each browser going off and adding their own crap when the spec ended up languishing (thank you W3C for sleeping while the web leapfrogged into the future).

I’m not a fan of HTML (I think that was good for it’s time but could use deprecation) nor JavaScript (but I’ll concede this is personal preference - however wouldn’t it be nice to have browsers run byte code so you could have a choice of languages rather than having compile everything down to JavaScript?) but CSS is easily the worst of a bad bunch in my personal opinion.

Frankly I don’t even get why people are defending it. Any programming tool that reduces the developer down to hours of trial and error just to do basic things is clearly a misstep. Sure, expert front end developers with years of experience and using bloated frameworks cope fine; but why have we allowed ourselves to get into this kind of mess in the first place?

I would honestly welcome a ground up complete reimplementation of the web if browser vendors all decided to work together on one.


Learn CSS Layout the pedantic way at:

http://book.mixu.net/css/

can help with the trial and error bit. It impossible to get an intuitive feel for nearly 400 keywords IMHO.


That's great reference (thank you for the link) but one of the great - if not the single greatest - accomplishments of the web was that it allowed anyone with a text editor and access to the internet to publish content with ease. I get that commercialisation of any platform will lead to specialities in that field; however the tools shouldn't make it objectively harder for new comers to contribute. Let alone discriminate against hobbyists who might not want to spend several hours of their life learning CSS (never-mind HTML, perhaps Javascript, how cookies work and any regional legislations, OWASP should they dare to have any user submission forms, etc).

Talking personally, I published my first website in 1994 when there wasn't different layout modes. Now it is suggested that I read a multi-chapter book just to learn what's changed in CSS so I can publish the same content I had before but in a "web 3.0" (for want a better description) format.

I appreciate my comments are very ranty / preachy and do value your comment as I hadn't seen that link before; so my comments are not directed at you in any negative way at all! What I'm essentially just trying to say is web development has become very frustrating for anyone outside of the webdev community. Heck, I find it frustrating and I used to specialise in hardening web servers so have worked quite close to that community.


It is as simple as it ever was to do what could be done 15 years ago with a simple text editor and access to the internet. Any adjoining aspect has gotten easier and cheaper by a magnitude.

It's just that what people want has gotten a lot harder to build.


The removal of the <center> tag in place of CSS black magic is definitely not "easier" than it was 15 years ago. However I suspect this is going to be one of those debates that we have to agree to disagree on.

I should add that I don't disagree with the deprecation of <center> from a language purists perspective. However it was still a step backwards in terms of ease of development when centring stuff in CSS is so clunky in comparison.


though i resisted for a long time, bootstrap brings back some of the old ways. <div class=“d-flex justify-content-center”>centered</div>


>I would honestly welcome a ground up complete reimplementation of the web if browser vendors all decided to work together on one.

Was that the sound of a pig flying by, or the sound of hell freezing over? Any time specs can be interpreted, there will always be these differences in browsers. Maybe we could not call them specs, and just call them suggestions?


Ostensibly I do agree with you however that is the reason I phrased it "browser vendors working together" rather than "a new spec being written".

However, as you said, the chances of that happening are remote. Even putting personal agendas aside (eg Google wanting to control content via AMP), the web in it's current form is "good enough" that there's no real drive to reinvent the wheel for something with such deep market penetration already.


> wouldn’t it be nice to have browsers run byte code so you could have a choice of languages rather than having compile everything down to JavaScript?

How are those two situations different? You're compiling one language to another language. Does it matter if one of them is called "bytecode"?


The Javascript equivalent of byte code would be web assembly and that is still a long way from being ready for primetime.


The question is, why isn't "the javascript equivalent of bytecode" just javascript? Why do you think there's a difference between "javascript" and "bytecode"?


The spec has changed on multiple occasions around whether flex items are definite sized or not, which is part of what of what's caused the lack of interop here.

The problem here is specifically having a percentage sized child of a flex item (and Chrome and Safari don't match the current spec, as the flex item is indefinite sized in too many cases; Firefox doesn't either, as the flex item is definite sized in too many cases!); to make the flex item definite sized everywhere you can typically just add height: 0.


> The days of needing separate constructs because of bandwidth are over

> It was for ease of changes.

Wat? Not solely. CSS had many goals, the primary reason was a separate styling language that could be universally interpreted and expanded, without involving HTML (or any other standard like ECMA). HTML versions were already bogged down in semantic squabbles.


The thing i hate about CSS is how unstructured it can be. You just sorta list whatever you want and it's suddenly a style sheet. No headers, no footers, no must includes.... DO I use quotes around this value? Do I not? Does white space matter? It's the most intimidating language I've ever used just because it feels so open and uncontrolled and nonsensical... I always thought CSS was some leftover abomination from the days of Netscape.


LESS is more how CSS should look like for styling. It's amazing we don't have embedding of rules yet.

parent {

   child {

    }
}

is just so much more development friendly than

parent {

}

parent child {

}


The CSS WG earlier this year resolved to take on a spec defining this, and there's implementer interest, so it's highly likely to happen.

(This is https://github.com/w3c/csswg-drafts/issues/2701 .)


Agreed, and hoping that scss or less influences future versions of css!


I believe the why is that as soon as you have any invalid syntax everything else is ignored. I forget the level of scope, I think it's until the next complete rule?


with PostCSS and the postcss-nested you can nest loads of stuff like mediaqueries, which makes it bearable IMHO.


Plus the error handling is abysmal.


Yes, this is all right on. And it's being solved in modern component libraries that combine JS, HTML, and CSS into modular building blocks for UI's.

The key difference IMO in how to think about CSS nowadays is to move away from the paradigm of CSS as a global system, and instead, use it locally scoped to components. I like to think of CSS classes as a kind of local state. Most often, in layout components and whatnot, its static. Otherwise, in more dynamic situations, rather than messing with css properties directly (or passing vars via css-in-js), the component's js manages the "state" of the classes being applied by adding/removing.

When you start to think in this composable component framework, styles are just another component. And js is used to manage changes in state, which it is much more apt to do.


Off the top of my head, there are transition events, requestAnimationFrame, and most importantly the Web Animations API. So what you're saying seems to be false.


>JS doesn't know when a style is actually updated and can then have a new property overwriting it to make the transition happen.

It's not easy, but it's possible. All animated/transioned elements emit lifecycle events like animationstart/transitionstart so you can use those to orchestrate complex animations. This is AFAIK how ng-animate works internally.


> But what about when the transition takes effect? JS doesn't know when a style is actually updated and can then have a new property overwriting it to make the transition happen. If you do properties too quickly the transition won't happen. Such as if a user clicks on the bar to change the position, I have to hack in a 100ms setTimeout to set the new transition duration after stopping the transition with transition:none;

There's a slightly more reliable and less ugly hack than using a timeout, which I _think_ is applicable to the scenario you're describing: instead, force a reflow by reading the element's .offsetHeight. I wrote about this on Stack Overflow years ago: https://stackoverflow.com/a/16575811/1709587

Not disagreeing with the overall thesis of this post, just pointing out a slightly less annoying way to work around the problems from application-developer-land.


>The real bad part is that CSS is in no way designed to be interacted with by anything but CSS.

Am I the only person who thinks this is a feature, and that the "bad part" is CSS supporting animations and transitions?

I mean - HTML for markup, CSS for layout and colors, JS for logic and animation. There was a very clear and well defined separation of concerns to the web, why did we have to go and ruin it by making CSS almost Turing complete then having everyone generate CSS and HTML with javascript?


even HTML cannot communicate with JS, you are talking about collective Web page behaviour running in JS/CSS/HTML/Browser. CSS is standalone, it doesn't have logical brain. It don't think. That is part of JS. I don't agree with your idea, if we add logic to all HTML and CSS then it is like batman doing killing.


Most of these are nitpicks. Some are preferences that I would oppose.

CSS is inspired by the style sheets of yore, of typeset publications made by ink-smeared metal pressed into paper. A magazine or newspaper might have a "style sheet" that said things like, "Paragraphs shall be 10-point Caslon" and "all second-level headings shall be hanging headings, outdented 5 picas." Before web browsers got a hold of them, stylesheets had already entered the electronic world in desktop-publishing software like QuarkXPress and even Microsoft Word.

The problem they were trying to solve was, how do you update the look and feel your website easily? This was in the days when most websites were static HTML files, and updating all your articles meant changing a file for every page. The most famous and beautiful example of the power of Cascading Style Sheets is CSS Zen Garden. In 2003 Dave Shea provided an unstyled page of HTML, and then designers from around the world contributed stylesheets that transformed the page into wildly different designs (http://www.csszengarden.com/).


> CSS is inspired by the style sheets of yore

Which is in my opinion the reason why it sucks for most of its current use cases. Layout of a paper document and layout of a web page are very different. The web "page" often isn't even a page but rather a GUI for a computer program.


From the beginning, CSS tutorials said just what you said, that the web is not the printed page and that you should not strive for pixel-perfect layout.


Which is exactly what anyone that I've talked to that gets paid to write CSS in any aspect is expected to do with it; pixel-perfect layouts.


I already had the "pleasure" of being in a project whose customer was refusing to pay as it was pixel perfect with their Powerpoint designs and across all major browsers and OSes. :(


It's not necessarily about pixel perfect. Even basic things like "two divs horizontally" are not intuitive in CSS, especially pre-flex-box.


  div { display:inline-block }
was that really so hard?


CSS grid is a big improvement here though.


Use spans then...


The selling point of CSS tho is that layout change should not require change in html.


here's my pet peeves:

1. CSS should not have adopted a hyphenated naming scheme for properties, since it makes it difficult to access css properties from javascript or other languages.

2. CSS should never have been used for layout, and nobody should have suggested it should be. CSS defines properties on individual elements, while layout fundamentally needs to define relationships between elements, which requires really icky hacks and implied relationships in a language like CSS, e.g. the definition of percentage units (percentage of what?) being mostly arbitrary and context sensitive, So you are forced to learn what all those context rules are to get the desired outcome.

What does height: 80% mean? 80% of the parent element's width? 80% of the parent element's height? 80% of the window width? who knows?

3. The naming of properties and values is entirely inconsistent. Sometimes "none" works. sometimes it doesn't. What even is going on with "white-space"?

4. Who allowed Microsoft to add "pointer-events" properties to css? This is a tragedy.

5. em based font sizing seems like a really good idea until you use it in some system that will arbitrarily nest component elements until the innermost reply to a comments thread is either microscopic or 3 characters per line.


> CSS defines properties on individual elements, while layout fundamentally needs to define relationships between elements

I couldn't agree more! Does anyone know a language/toolkit/something that gets layout right? I remember getting excited by Grid Stylesheets [1] but the project seems dead now...

[1] https://github.com/gss/


The layout constraints system on iOS works pretty well once you understand that it uses a global constraint solver:

https://developer.apple.com/library/archive/documentation/Us...


I wonder if CSS could be translated/compiled to sets of linear constraints? Obviously just the parts that affect layout would be relevant for this translation. But I wonder if it's possible to come up with a formalised mathematical relationship between the byzantine context sensitive rules of CSS layout, and the smaller set of building blocks that cassowary supplies.

And then, I wonder how much could be round tripped? Do flexbox and grid fill enough of the gaps to make systems of linear constraints fully expressible in terms of flexbox/grid? If not, where are the remaining gaps, and are they useful enough "real world" usecases that you couldn't practically make constraints->css a (potentially) lossy translation. It kinda looks like GSS attempted this, but I wonder if GSS can be improved upon to rely less on JS for filling the gaps in 2018?


AutoLayout on iOS and macOS.

It’s a modern incarnation of the Cassowary constraint solver: https://dl.acm.org/citation.cfm?id=504705

Mind you, people who don’t understand linear constraint systems (typically web devs) will find it hard to use (and they usually complain about this endlessly, because in their opinion Apple should “just use flexbox” - which is ironically just a special case of a linear constraint layout).

I’m afraid CSS (and the web in general) is just another case of the “Worse is better” paradigm.



I do. It's CSS. There is a nifty feature display: grid. And also display: flex.


This is not what I mean. Flex and Grid are simply defining layout in terms properties on an individual element, and what it expects its children to do. Still no way to represent relationships between elements (except the implied relationship between siblings, only indirectly accessible by setting properties on their parent, or setting properties on a child that affect the implicit relationship between it and its parent and or siblings, such as, eg, "margin")

These things at least make certain things that were simply impossible to do before now possible, but they're doing it in a bolted on, unnatural, overcomplicated way.

And still there are things that are only possible by rearranging the HTML to accomodate the implied relationships these layout systems expect.


I’m still missing xaml every time I need to position something on a webpage.


6. display:none and position:fixed need to die in a raging inferno, or at least get moved to a seperate property that can be *{be-full-of-shit:no-dammit!important;}'d away in userContent.css or equivalent.

(See also pointer-events:auto!important;.)

7. Anything nontrivial involving tables/tds seems to be impossible to do properly and pointlessly obnoxious to do at all. Eg:

  <td>
   <tdtag>foo</tdtag><!--put this edge-aligned in any corner-->
   Put this in the center as if tdtag wasn't here.
  </td>


For #5 use rem which is based off the document font-size rather than the current elements font size. </pedantic> What really needs to stop is the use of pixels and absolute font sizes for sizing everything as they never work on more than 1 device/zoom level/default font size.

Breaking layout into its own thing has its ups and downs. Basically you would have to break out what flexbox and grid do into a "layout" file, and come up with syntax that makes describing relationships easier than they currently are in CSS/LESS/etc. The downside to this would be that you have to chase UI bugs through 3 files rather than the current 2.

What CSS could use is a good clean as its grown organically for quite some time.


That's all well and good but rems only became broadly usable relatively recently, and I've had to make web pages a lot longer than that. And also fix webpages written well before that.


rems don't work either because there are instances where you need to have things line up exactly. For example, if you have 3 columns. You will be one pixel out. There are no good ways to fix this. See [0]

https://johnresig.com/blog/sub-pixel-problems-in-css/

CSS should only be used to appease those ppl in your org that read/write more blog posts than code. Use JS if in doubt. You're welcome.


I tried and failed to recreate that example (from 2008). Modern browsers do seem to do a reasonable amount of sub pixel rendering. Maybe rems are bad but that article does not demonstrate it.


Did you try it on ie11? That was the only one we experienced it on. Of course we had to support ie, which meant a layout re-write. :<


pointer-events: none; is actually pretty useful in many cases when you temporarily need to disable interactions, like drag/drop


It's useful as long as every browser supports it. When it doesn't, and you want to polyfill, the polyfill needs to download all linked CSS files a second time, implement a CSS parser to find the pointer-events properties, and after all that, patch in not entirely identical behaviour with javascript.

But then, this is behavior. what's it doing in a language that's supposed to be strictly about style/presentation? Why isn't it an html attribute instead?


Out of curiosity, what browser do you need to support that doesn't support pointer-events?

Internet Explorer 10? No longer supported by the vendor, other than for Windows Server 2012 which likely won't be used by your user.

Opera Mini? What is your usecase? Opera Mini works very differently to other browsers. You can select the text whanever it's visible on the screen, even if it's covered by another element - as for this browser, the layout doesn't really exist. Disabling forms isn't as necessary, as Opera Mini waits for a script to finish once you press something.


i did not get the memo that safari and chrome supports them now


> It's useful as long as every browser supports it.

sure, but the same can be said of every web api and other open standard with multiple implementations.

https://caniuse.com/#feat=pointer-events

> But then, this is behavior.

there's not always a clean separation. what about opacity:0 and visibility: hidden? this affects intractability despite being presentation, right?


Would be nice to have that polyfill at the webpack build level instead of the browser. Generate css files specifically for older browsers.


1. hyphenated for css, camelCase for javascript, underscores for API (i.e. php or ruby). Makes it easy to differentiate what's what.


If that's a serious problem for you, setup your vim to use a different color for variables based on the current filetype.


It’s not a serious problem to work around, but it is another instance where the web architects designed all these different languages without thinking all that deeply about how they would work together. and so i need

    .style[“background-color”]

    .style.width=mywidth+”px”
and (sigh)

    href=“/search?q=hello%20world&amp;another=query%20parameter”
the latter of which is, while it's the correct way to write html, is so stupid that most browsers silently error correct the less insane (but technically wrong) version

    href=“/search?q=hello world&another=query parameter”


El.style.backgroundColor = Foo;

That works. Js automatically allows use by camelCase.


Can you explain why it's technically wrong?


Tl;dr: Because you can not have spaces in a URL.

[RFC #2396](https://tools.ietf.org/html/rfc2396) defines an official standard for URIs.

Spaces are not an allowed character within a URI. Since many symbols (such as a space, which is an invisible symbol) are not allowed in a URI, then a technique called "escaped octet" was introduced to allow you to pass ASCII symbols (such as a space, among many others) in the URI without breaking the URI.

The percentage sign (%) followed by the two hexadecimal digits representing the octet code correspond to ASCII symbols. This is the official way to pass a non-allowed symbol into a URI string.

Now let's say you want to add a space to your URI for some reason (this really shouldn't be necessary, but let's run with it). Since a space is not allowed in the URI, we instead would _represent_ a space with "%20" which is the escaped octet that corresponds with a space. Browsers and server side languages would then translate this effectively to a space character.

Old browsers would break if you attempted to add spaces or other non-allowed symbols to a URL in the address bar. This required you to manually encode these symbols yourself, such as in his first example where he writes:

    href=“/search?q=hello%20world&amp;another=query%20parameter”
These queries would get passed to the server as `q: "hello world"` and `another: "query parameter"`.

However in more modern browsers, we have attempted to make it easier for people to understand and write URLs. So browsers now correct errors made in your URI syntax for you by looking for those non-allowed characters and encoding them for you automatically before they actually submit the request.

So now typing:

    href=“/search?q=hello world&another=query parameter”
will succeed in modern browsers thanks to the fact that the browser is secretly encoding this for you.

Most people, even a surprising amount of web developers, have grown up in a time when they never had to fully understand the fundamentals of URI structure and uniform standards because browsers have protected them from making mistakes. This is similar to how many new developers don't understand memory management in apps, because many tools have handled this for them in recent years.


The main point I was making here was also that there's actually TWO DIFFERENT ESCAPING MECHANISMS at work here. percent encoding AND html entity encoding. If this was a javascript property assignment, I might even need to add in backslash encoding. You're supposed to entity encode the ampersand in a query string as &amp;. If you don't, some text editors will even highlight it as a syntax error for you.

the fact that ampersand was chosen as a query term seperator for URLs, knowing that they're also a special character in html that introduce entitity encodings, seems like it was a bit shortsighted. Browsers won't complain about an unencoded ampersand in a URL, but the the html validators will.

Historically, semicolon ; is also supposed to work as a query term seperator, (in particular, for map coordinates!), and you wouldn't need to entity encode it. but this is such an obscure and historical factoid that it is not consistently implemented, and you can only use it if you know everything handling that url will definitely cope with it correctly.

fun factoid: I once broke Ruby On Rails by convincing DHH using semicolons in query strings was a good idea. Apparently some older versions of safari, and certain proxies broke down when encountering them.


It's merely a bonus.


I came here to post what you already did on (2)

Couldn't agree more.

The problem is that we are stuck with it, looks like web technologies are set in stone.

Here's how it should have been:

https://constraints.cs.washington.edu/web/ccss-uwtr.pdf


A lot of the complaining in this thread is not what the article is about but I always find that too many people look at CSS usage from too high a vantage point without understanding the fundamental workings. It is that issue where people find themselves in trouble getting properties to interact with each other as expected.

One example, and not the best one, is 'width'. People want 'width' to be the total width of an element as displayed in the viewport but 'width' was never specified that way. It is the width of the content, such as text, exclusive of padding, borders and margin. But people don't read the specification, then struggle getting layout to look as they wish and blame CSS as not working "as it should".

Quite frankly, in most cases, CSS works exactly as it is specified and most of one's problems go away once that is understood.


There are legitimate grounds to argue that the way CSS was specified is wrong.

The fact that people find it so confusing is one. If people intuitively think that "width" is the total width of an element (an entirely reasonable assumption, mind), then that would imply that CSS chose an unnecessarily confusing name.

Another is from the mental load perspective. If I'm doing a layout, I want to figure out how things fit by looking at the total space they take up. _That_ is the width I care about. Leaving margin out of it makes sense, but having to mentally add the padding and border to get from "width" to "no really width" is annoying.


Today, many people want to modularize components/elements for placement in an arbitrary way. That is, they want to be able to plunk down an element on any page and make it all work together. However, if one uses 'width' as the total width of the element, including margin, borders and padding, it could mean the spacing between the content, pre-arranged in that way, may not fit the design of the page giving it too much margin or padding making it look awkward. Then the designer is stuck with that if he doesn't have access to changing the elements margin/padding.

If `width` only means the content, then a designer can plunk that same element down and adjust padding/margin to fit any design easily.

This is one example of an issue others would complain about.


These kinds of tradeoffs can be handled better, though.

It's worth taking a look at how Windows Presentation Foundation does things, for example. It places the decision of whether to size individual elements according to their content size, the size of the container they're being placed into, or their total width front and center, in a way that, IMO, leads to less head scratching and compromises.

I think the issue here is that CSS was originally envisioned primarily as a styling tool, and layout functionality was bolted on as an afterthought, through a design-by-committee process. So, yes, it works, and anyone can learn it, but it would be nice if the overall effect were one of a technology that had a clear plan all along.


> The fact that people find it so confusing is one.

Problem is that they never learned it. They jump in thinking "I know how to code, everything should make sense to me" and hit a wall. CSS is not like regular coding.

I went to a technical college and one of the class was on CSS. It's the class that everyone aced. Even the people who would fail miserably in every other parts of the industry.

CSS is not hard but it requires some memorization.


Logic in many cases is preferable to memorization. Not only you need to memorize less upfront, you can expect new additions to follow it, and not need to memorize much to start using them.

Compare how easy it is to pick up e.g. Spanish writing vs English writing vs Chinese writing, assuming that you already can speak it.


There's logic in CSS. Selector specificity, cascade, inheritance, display types, etc.

Once you grasp the few parts that requires understanding you only need to remember the syntax and the declarations.

Then the real challenge is to organize your stylesheets in such as way that allows your styles to grow.

I've seen from experience that most people don't even try to learn the language. They come in with no knowledge of the cascade, wonder why everything fails and blame it on the language. Most "bugs" related to CSS can be spotted and fixed in minutes.

Ex: ID selectors are always stronger than classes when it comes to selector specificity. A class can also be mixed with an element selector to increase its weight but it will never beat an ID. Someone who is not aware of this will try to have a class selector be stronger than an ID and get strange results. Instead of fixing the selectors they put an !important on the class selector to have it be stronger than the ID. The stylesheet then quickly become a mess.


Or !important; everywhere


> One example, and not the best one, is 'width'. People want 'width' to be the total width of an element as displayed in the viewport but 'width' was never specified that way. It is the width of the content, such as text, exclusive of padding, borders and margin. But people don't read the specification, then struggle getting layout to look as they wish and blame CSS as not working "as it should".

And this is something on the wiki page:

> Box-sizing should be border-box by default.

While yes, CSS has well-defined behaviour here, it goes against user expectation. That mismatch is the real harm here.

(And to be clear: I'm not saying this with any sort of CSS WG hat on here. And I don't think the wiki page necessarily reflects the view of the whole WG, given it's not an official document.)


Yes, one of the most frustrating things is reading peoples rants about how 'bad' CSS is, it's clear they don't understand it, and they think it should be easy.

Sure it's nuanced, and maybe imperfect, but I love it.


https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing lets you have width work the way people want. box-sizing: border-box "typically makes it much easier to size elements."

The problem is that sometimes the specification is not optimal, particularly when you're making applications instead of just formatting documents. Some of those cases have been fixed, some have not.


(1) it should have been designed around what people actually try to do: three column layouts with headers and footers, aligning content in the middle, pinstriping (this one isn’t as popular anymore), drop shadows, etc. Instead, all of these things required either hacky workarounds, or stepping outside of CSS entirely. The first decade of CSS was “look at all these things you can do that you don’t want to, and you can use them so long as you don’t try to make the kind of sites your clients actually ask for!" So fucking stupid, it still makes me angry years later.


> (1) it should have been designed around what people actually try to do

It was but a lot has changed in the last 20 years.

At the time CSS was first supported in most browsers, the way to create columnar layouts was with a frameset. They even handled fixed position headers and footers.

I can't believe I've been writing CSS for 20 fucking years.


> the way to create columnar layouts was with a frameset

Ohgod, I forgot about that one. Ugh. Of all the bad ways to make a 3-column layout, that one was definitely the worst.


Framesets broke linking to individual pages of the website, since those pages would be opened inside the frames.


> three column layouts with headers and footers

I was appalled when I saw what was needed to make this use case, used by 1/2 he web pages in existence.


originally CSS had no layout facilities. (as it should be, see other comment). Layout was hacked in to css by abusing the "float" property into doing things it was never meant to be doing.


> Layout was hacked in to css by abusing the "float" property into doing things it was never meant to be doing.

So if CSS wasn’t supposed to do layout, despite that being what people needed, and if you weren’t supposed to use tables for layouts despite that being what worked... then what on earth were you supposed to be using for layout? I don’t recall any other serious options out there.


there weren’t any. the official w3c answer was basically “why on earth would you want to layout a webpage?! stop doing that!”

Ideology trumped practicality and we’re stuck with the consequences.

or another way of putting it is they viewed web browsers as something more like a feed reader/news reader. that the browser and user should have control of how the information is presented, not the individual websites, which should stick to plain vanilla semantic markup with no fancy stuff. CSS was only created to stop people mucking up documents with <font> <center> <marquee> and <blink> which have no semantic value.

for a time mozilla had xul, but that was never an option for website layout.


> the official w3c answer was basically “why on earth would you want to layout a webpage?! stop doing that!”

And that's the heart of my frustration. w3c designs things, not based on what people need, or even what people want, but instead what they think people should be doing. So many problems of the web stem from the fact that the committee who's supposed to be directing the design of web technologies, has no interest in how people actually use the web. That creates a power vacuum which gets filled by browser manufacturers, who at least have an interest in the people using the web's needs.


In the beginning... the web was never envisioned to be what it is today. The notion that anybody would want to do layout like publishing software didn't cross anyone's mind. Originally the web didn't even have images! It was just text and links. It was just a way to pass text documents around easily. Of course, then the designers came along and said "I want it to look like this" and webmasters (as we were called back then) had to figure out some way to do it. The only realistic way to more or less do it was to use tables (which, of course, was not their intent, but when all you have is a hammer...)


It wasn't that the web pioneers did not consider layout important. They came from a background where layout was "external". The important thing was the content. Style was something that was added and/or defined by someone else. Such as with LaTeX.

The first web pages I wrote had no style information at all. And the first browsers I used allowed (and expected) you to define the default colours and fonts for pages to your own taste.

I am still a fan of minimal styling. It would save me a lot of time to write "style = article" on my pages and be done with it... but most people want their pages to look unique and exactly as they think it should.


Do you mean using tables, float/clear, flexbox, or grid? Or all of the above?


> pinstriping (this one isn’t as popular anymore)

That almost seems like an argument against designing CSS for what "people actually try to do" - what people try to do changes depending on the design language du jour. Better to have a generic specification for maximum flexibility, no?


No, because CSS is still chock-full of things that nobody ever wanted to do. Things in it that people used to want to do, but don’t as often anymore, are still more useful than those.


What does CSS have in it that nobody wanted to do? There are certainly plenty of cases of things being done which only made sense for those targeting print, for example, but I can't think of anything that nobody wanted?


> Box-sizing should be border-box by default.

It was for many years for >98% of the users when IE had near-total market dominance. But W3C rejected sanity and refused to fix the spec, insisting that IE should break every website on the planet and implement the W3C box model.

This was a major PITA for anyone who cared enough to design a website that worked equally well in IE, Firefox, and Opera, which became an increasingly annoying problem as Chrome and Firefox gained in popularity. A great many developer hours (including mine) have been lost on the W3C's foolish stubbornness.


> It was for many years for >98% of the users when IE had near-total market dominance.

It never reached that high: IE was only around 80% at the time of IE6's release (and IE6 was the first version of IE/Win to support quirks mode, allowing the change without breaking sites; IE5/Mac had shipped a year earlier, but never had the marketshare its Windows counterpart had).


Some of these seem very nit picky but if we are doing that my pet peeve was that the “color” property should have been named “text-color”


It affects non-text as well, e.g., https://jsbin.com/wodevam/edit?css,output.


Wow. I've been writing CSS for 10+ years. I never knew that.


Or just "font-color" to match font-face and font-family. etc. That still gets me almost every time.


Color is not a property of font so I'd stick with "text-color"


Hold on a second here! It actually becomes the "currentColor" color in inlined SVGs, and the default fill color in svg when no color is defined. so oops, not a property strictly of text or fonts anymore. Maybe "foreground-color" would be appropriate?


color is as much a property of font as size is


Traditionally, font is just the shape of the characters (size, weight, italics). Other things (alignment, underline, wrap, color).

This is because "fonts" were originally physical typesetting blocks.

Some designers go further and say font refers only to the files and file formats; other things are the "typeface".


I believe the traditional usage is something like this: Helvetica is a typeface, Helvetica Bold Italic is a font.


Almost: Helvetica is a typeface family, Helvetica Bold Italic is a typeface, Helvetica Bold Italic 10pt is a font (or rather, the font is a case full of bits of metal with Helvetica Bold Italic 10pt)


Yeah, but fonts being recolored is a different thing than fonts having a color. https://www.colorfonts.wtf/


In practice it usually is part of the same font selection dialog in most software that you use to select the font face, size, bold/italic/underline, etc.

For example, the relevant button in Word is titled "Font Color"


Surely "text-colour"?


It wasn't until recently that I finally realized how user-friendly CSS was designed to be. As I started to fiddle with LaTeX in search of better looks on my papers, it gets more and more clear that the design of CSS is thoughtful and ergonomic. It is so painful to work with LaTeX that I could not believe I had complained about CSS. What would take a few lines of clear code in CSS would take dozens of undecipherable sequence of commands in LaTeX.

For instance, just changing the font size of section headings in LaTeX is not a trivial matter. Eventually I ended up with this:

    \renewcommand\section{\@startsection {section}{1}{\z@}%
                                       {-3.5ex \@plus -1ex \@minus -.2ex}%
                                       {2.3ex \@plus.2ex}%
                                       {\normalfont\normalsize\bfseries}}
It would take just h1{font-size:1em;} in CSS. The problem of TeX is that it has no abstraction that is easy to work with. In CSS, you have elements -- actually, a tree of them -- and they have their own attributes, and in addition, they can be easily modified. You can even give elements a class to have them have common properties. All things that do not exist in TeX. I did not know how the concept of a heretical structure of elements and their attributes give you an intuitive interface to a layout.

Certainly, CSS might not provide you with full control over how things are rendered. There is little doubt that TeX excels in that regard. But how many people need to be able to easily create a new math operator? Is it worth making it difficult to change the font size of headings?


I think you forgot the "C" in CSS

I think you forgot that everything is in a global, conflicting namespace, where people thought global naming conventions like BEM were a good idea vs actually solving the problem


Wow I just started making websites of my own recently and have encountered so many things that are immensely infuriating about how the language is interpreted that I've been thinking about starting a list myself.

They seem to favor implied behavior rather than explicitly defined behavior which is incredibly annoying. For example, space between inline-block elements that is not accounted for by margins. The fact that margin-top and margin-bottom percentages are computed based on the width of the parent element, not the height. The fact that certain properties like max-height are oftentimes not respected if they use a %, even if the height can be precisely calculated. The fact that I have to add body { margin: 0; } to everything. I'm sure there have been more but just what I can think of off the top of my head.

Oh, and COLLAPSING MARGINS.... WHAT THE HELL


I often feel annoyed too but CSS what we have been given to work with. Instead of wasting time being annoyed that reality does not match our expectations it is better for our health to swallow the bitter (red?) pill, accept reality and learn CSSs idiosynchracies. The page http://book.mixu.net/css/ shoud help.


>You may have used z-index to "fix" the relative stacking order of content. But did you know that z-index is not absolute across the document, but rather relative to a stacking context?

wait what the FUCK


While reading that page, it is helpful to make flashcards like you are a med student. In fact "flashcards are a good idea" is probably a good piece of advice for gaining a mental model of a system which was the result of more incremental evolution than all-at-once intelligent design.


They seem to be confusing when you are just starting designing, but once you spend more time with it - most of it starts to make sense

> The fact that margin-top and margin-bottom percentages are computed based on the width of the parent element, not the height.

It's actually much better this way, imaging a block of text with varied content. If you had margins calculated based on a height - you will have a margin that depends on text content size, which is wrong, instead you want your margins to depend on a screen size width, not the content inside

> Collapsing margins

It's a great solution as well, imagine you have a div that you want to have margins on top and bottom of 20px. It makes perfect sense to collapse margins if you have say 2 of those div's running one after another, because you don't want them to have 40px margin, you only want 20px. So when there is another element that is not that div - you will still have your desired 20px margin.


> It's actually much better this way, imaging a block of text with varied content. If you had margins calculated based on a height - you will have a margin that depends on text content size, which is wrong, instead you want your margins to depend on a screen size width, not the content inside

So using width to compute a vertical margin is somehow a better solution? If I wanted a margin of a fixed size that doesn't dynamically change based on content, I would define it exactly using vh, or px.

> It's a great solution as well, imagine you have a div that you want to have margins on top and bottom of 20px. It makes perfect sense to collapse margins if you have say 2 of those div's running one after another, because you don't want them to have 40px margin, you only want 20px. So when there is another element that is not that div - you will still have your desired 20px margin.

I just want the code to behave as I instructed it. If I say this div should have 20px of margin on top and bottom, then it should. Don't go behind my back and say "we know better" and delete it. There seem to be plenty of ways to achieve only 20px on successive divs without resorting to what is basically undocumented behavior that explicitly contradicts what is programmed in the file. For example, I could just give all divs 20px of margin-top, and then style :last-child with 20px margin-bottom. This is almost certainly a better solution than resorting to collapsing, at least in my opinion.


> I just want the code to behave as I instructed it. If I say this div should have 20px of margin on top and bottom, then it should

That’s exactly what collapsing margins are doing. It makes your div have 20px margin, not 40px. Imagine two blocks one above another. If margins were not collapsing - your divs would have 40px margin instead of 20 like you set.

> If I wanted a margin of a fixed size that doesn't dynamically change based on content

It does change based on browser width, that’s what most would want. From a designer perspective - the wider the element is - the more margin on top and bottom it should have for better readability. You don’t want your margins to be different for a list of various text items for example, it will look ugly. You want margins to be different based on a screen size.


CSS and HTML will usually afford a specific approach. Being a web developer is knowing what these approaches are, and to know when stuff might get "not nice". So when you see a graphic designer using multiline text blocks with elided text in their design layouts, you know to raise a red flag and get that removed.

Personally, I've not found collapsing margins a huge issue either way. It's just the way it is. There's 10 billion ways to add distance between two elements in the browser, so pick a solution and go with it.


Css is fine. Not perfect but fine. It's an approachable way to style documents that look ok on different devices. It's best when used sparingly.

When I see people complain about css, they usually fall into a few camps. First theres the person who wants everything to look the same everywhere. They want web design to work like a print document. Sorry but thats now how it works.

And then theres people who are writing web apps, not documents. I feel sorry for those folks. Cuz css does suck for that, and there's no easy solution.

But for documents, css is fine. Although it wouldnt be as important if you all marked up your documents correctly in the first place.


The problem is that there are plenty of us, because although it is possible to make a living with native projects, it is Web that pays most of the bills on UI development.

At least 2018 is the year we finally catch up with the native 90's regarding components.


A new software engineering maxim:

"The bar of complaint will rise to meet any improvements"


Nah, I've definitely used some software which had fantastic cognitive affordances, fit in my working memory really easily, and which people broadly agreed were fantastic.

http://docs.python-requests.org/en/master/#the-user-guide


I get a serious case of impostors syndrome when it comes to CSS. 20+ years of HTML, 15+ of writing Javascript, loving ES6 but CSS gives me fits.

What I hate the most that there really is no clear parent - child abstraction.

This parent child abstraction (all the way down to turtles) is present in most reasonable UI frameworks. I'll take Windows Forms or Qt any day of the week over CSS.

In CSS this abstraction leaks all over the place. Elements can do whatever the hell they want (z-index, pos, box sizing before International Border-box Day, etc).

CSS Grid was supposed to solve layout. It still has a long way to go.

For example, teaching at a bootcamp I ran into the following:

https://learn.freecodecamp.org/responsive-web-design/css-gri...

By setting a hard limit in pixels(as required in the exercise) you break the grid for smaller sizes because items go outside parent.

So what do I tell my students? Avoid px whenever possible, use media queries, em/rem and percentages.

That's all good, but there is no coherent mental model to think about UI besides bunch of arbitrary boxes which can do ANYTHING.

In a good UI your child elements should stay within the parent(via scroll etc), not so with CSS. There are no guarantees whatsoever. Someone will come up with !important !important pretty soon.


> background-position and border-spacing (all 2-axis properties) should take vertical first, to match with the 4-direction properties like margin.

Is there some reason why margin/padding is top, right, bottom, left instead of left, top, right, bottom or left, right, top, bottom or both of which would seem more common in other APIs


My guess is that it works the same way a clock does. Purely a guess though.


just to give you more TRouBLe


If someone just getting started in front end dev as a hobby and knows HTML, CSS classes, IDs, selectors, basic inheritance rules and the most of the top commonly used CSS declarations but nothing about centering or aligning elements, other than abusing the box model to move elements around the screen:

e.g.

.class { margin-bottom: -50px !important; }

would you recommend starting with CSS Grid or Flex box tutorials for learning alignment and why?

I'm getting the hang of {flex: # # #%;} grow, shrink, basis construct, but is CSS grid the future and should I cut my losses and start there? My time is limited as this is not my main profession.

Thanks in advance.


“New ideas will come along, but they will extend CSS rather than replace it. I believe that the CSS code we write today will be readable by computers 500 years from now.” — Håkon Wium Lie, co-creator of CSS.


Yeah and that puts enormous pressure on what we put there.

That flexbox, half-baked and overcooked at the same time. And display:grid at the same time but using completely different concept of flexibility (fr units in grid) and some strange property in flexbox.

What, the hell, this means:

    div {
      width:400px;
      flex:2;
    } 
? Just a humiliation of CSS box model.


flexbox, grid, table,etc. shall be values of some 'flow' or 'layout' property as they define layout model of element's content.

'display' values shall just define requirement of the element to its container: display:inline, display:inline-block require flow:text container and display:block require flow:vertical, flow:horizontal wrapper.

So it shall not be display:inline-table, display:inline-flexbox and the like.


The principal mistake of CSS IMHO is that it invented new syntax for what should've gone into HTML attributes (like SGML LINK and FOSI did). This then led to inconsistent ways of manipulating display properties (CSSOM etc.) and also to the identity crisis of HTML (postulating "semantic" HtML when markup is as syntactic as it gets).


It would be nice if it was possible for devs to create their own CSS-like DSL and get the browser to use that instead of CSS.


I started to work with HTML and CSS recently, so I'm still learning. To me it seems that CSS preprocessors are the closest thing to what you descibed, although the output is still CSS.


CSS should have used linear color space for gradients and blending instead of sRGB. I don't want CRT emulation in 2018.

https://lists.w3.org/Archives/Public/www-style/2012Jan/0615....


Fr units (fraction, measure of flexibility) shall be allowed on width,height,margin,padding and borders.

Instead of using flexbox I should just be able to write:

    label { width:1fr; } 
    input { width:2fr; }

to distribute the widths in 1:2 ratio.

Easy, obvious and has very good mental model - flexes are just springs where fr unit expresses their strength.


For what could have been:

"The Languages Which Almost Became CSS" https://eager.io/blog/the-languages-which-almost-were-css/


It shall not be `display:none` but rather `visibility:none;` to exclude element either from layout or rendering trees.


It MUST be a way to reproduce <center> HTML by CSS means solely. No way so far.


What wrong with display:flex, justify-content: center, align-items: center;?


I know at least three without using tricks like negative margins.


Emphasis on incomplete.


are there any efforts underway to rectify the horror of css?


When it comes to widely-used web standards, we tend to be pretty much stuck with them forever. They get extended, but not replaced.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: