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.

Isn't this the default?

   align-items: stretch

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

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!

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

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.

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.

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.

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's just that what people want has gotten a lot harder to build.

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.

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?

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.

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

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

parent {

   child {

    }

is just so much more development friendly than

parent {

}

parent child {

}

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

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.

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.

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

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.

  div { display:inline-block }

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.

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

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

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.

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.

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.

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.

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?

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

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?

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

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

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

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

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

wait what the FUCK

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

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.

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.

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.

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.

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

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

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.

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

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.

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;
    } 

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

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

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

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

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

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

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.

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/

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

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?

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.

https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanc...

https://docs.microsoft.com/en-us/windows/uwp/design/layout/l...

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.

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

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.

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.

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?

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.

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?

    .style[“background-color”]

    .style.width=mywidth+”px”

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

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

That works. Js automatically allows use by camelCase.

[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&another=query%20parameter”

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”

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

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.

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.

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.

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.

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.

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.

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.

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

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

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.