Mistakes in the Design of CSS (2013) - https://news.ycombinator.com/item?id=38363698 - Nov 2023 (143 comments)
Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=25891435 - Jan 2021 (68 comments)
Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=18297757 - Oct 2018 (150 comments)
Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=10453850 - Oct 2015 (106 comments)
Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=7665667 - April 2014 (1 comment)
Default heading styles should not have equal top and bottom margin. Headings should be closer to the content they label than to the content they are setting their content apart from.
h1, h2, h3 should not have different styles. it's an anti-pattern that leads to broken accessibility
I came across it when reading Butterick's Practical Typography and it's possibly the lowest effort/clearest improvement guideline in the book.
Now I can't unsee websites that do it wrong.
there should really be one header tag and its level should be based on some nesting depth
and don’t get me started on the maintainability mess that is z-index… better we have a system to centrally maintain an ordering list than a distributed one which only works reasonably consistently if you already know everything in the whole system
You can't do away with stacking contexts, you need those to isolate content you don't control to prevent it from breaking the stacking order of content you do control.
I completely agree with you about h* tags, though. I wish html5 sectioning hadn't been killed by the browser vendors. As is there's no safe way to put headings inside custom elements. We almost had it, it was specified and everything.
One way I've dealt with this in react is combine a Heading component with ContentGroup component. Each content group needs exactly one heading, and heading can't exist without it. Content group can contain other content groups. The tag for heading can then be determined by how many content groups are in the tree above it.
This works pretty well ime, but it can be hard to get devs to use (or think about accessibility at all).
Related: I also love when I can't paste tabular data into Excel/etc. anymore
For the record, I don't hate the idea of stylesheets, but...sheesh
With css grid, I can tell each element which area or column+row to occupy.
If I add or remove a random element, the rest of the elements stay in the correct place.
But do that with a table and you end up trying to glue your house back together shard by shard whilst trying not to cut yourself or breaking things more.
This complaint highlights how absurdly not fit-for-purpose html+css actually is. Okay, you may want to do "responsive" design, but you have the semantic layout fixed, therefore you try and contort a styling engine into pretending to be a layout engine when in reality it is three stylesheets in a trenchoat.
I need to write this up properly, but one of my bugbears with responsive design is that it became normalised to push the sidebar down below the content on small screens. And if you didn't have a sidebar, to interweave everything in the content no matter what screensize you were viewing on.
What I want is a way to interleave content and asides on small screens, and pull them out into 1+ other regions on larger screens. Reordering the content on larger screens would be the icing on the cake but for now I'll take just doing it.
This CSS Grid approach adds gaps: https://codepen.io/pbowyer/pen/azNarbZ
Using named grid-template-areas stacks the items you move to the sidebar on top of each other, so you only see one of them.
'Good' old floats get most of the way, but put the item in the sidebar exactly where it falls. Plus they're a pain to work with overall: https://codepen.io/pbowyer/pen/jEqdJgP
this not fit for purpose may in fact be historically superseded usages that still are baked in to some usages affected by the relatively rapid change of the various platforms that must interact and use the respective technologies, the specification version of "technical debt"
that is to say some subsets of the numerous technologies can be used to construct something fit for the purpose that you are describing, but as a general rule anything constructed in a solution will probably be using other subsets not fit for that particular purpose, but maybe fit for some other purpose.
Isn't this a trivial problem to solve that doesn't require introducing any new layout mechanisms?
Today it's usually implicitly designed for iphone, designed for 1080p, or ipad, and you have to guess, strong correlation with whatever device the designer uses in his personal life.
And just in case, nobody ever said tables were dead. Tables were declared bad practice for page formatting, not for tabular data.
Use grid instead.
The most important thing is to use the right tool for the job. If grid lets you express what you want in the most straightforward way, use it; if flexbox does - even if it needs nesting - then use it instead. Don't shoehorn one into a situation where the other makes more sense. And sometimes either will work for a particular situation and that's fine too; use whatever you find most ergonomic. They're both very good in their own way.
The argument doesn't make sense because it is not too hard for a screenreader to understand whether a table is used for layout and even if it was hard the problem would more easily be solved by just adding an attribute to the table to indicate that it is used for layout.
I made a stunning landscape photo one time that looked great only when displayed at roughly the size of a hand. If made larger undesirable details became visible (littering), when smaller important details were lost (a formation of birds over a fishing vessel).
Not beyond a point, but it's still very useful to be flexible up to that. For example, I'm very grateful that a web page will reflow text rather than print everything on one line and force horizontal scrolling.
Usually I declare victory when they say that tables might get depreciated in the future.
They at one point really wanted to get rid of framesets. I asked how to make the classic scrollable resizable side top bottom UI in pure CSS. We've tried for hours, everything we tried looked ugly and didn't fully work. framesets are here to stay now :)
I still have one of the funnier "how to make this without tables?" challenges. It's not a very good example of the use of tables but did make me laugh.
that sounds like a use for tables, so I find it difficult to imagine a non-table layout that would want this.
>Resizing columns by size of cell content.
I can sort of see this as a requirement for non-table layouts that would not work well, however my experience from table time was that was one of the biggest irritants at least for me, that columns would haphazardly resize based on what was in them, and sometimes you wanted them to and sometimes not. As a general rule I found it better design wise to truncate text rather than have things expanding and contracting in response to what copy editors were doing.
>framesets are here to stay now
woo yeah, I see them a lot in the wild. I mean really the only time I really see frames used anymore are iframes and generally in eCommerce and similar security requiring solutions where the frame can be partially controlled by the storefront, but is more fully controlled by the payment provider. I just find the statement "framesets are here to stay now" really weird and triumphal for something that is so rarely used?
>I still have one of the funnier "how to make this without tables?" challenges.
I followed the link, I would think it is better suited to a "why would you make this" challenge. I'm not sure
1. it shouldn't be a table. seems like maybe it should be
2. why the freaky animation. or for that matter why the animation nearly crashed my browser.
I'm definitely sure lots of designs could not be adequately achieved without tables and framesets, but my experience seems to have run contrary to yours because for me CSS was a godsend in fixing the things I found irritating about those two technologies, this does not mean that I never encountered situations where I thought this would be easier with tables, but as soon as I tried putting tables back in I found all those irritants came back in.
From my experience tables and framesets were best suited to layouts that are rarely ever wanted, and when used to implement slightly different layouts had too many problems and irritants to be useful.
Your mileage has obviously differed, but I'm not sure that "here is a particular problem that people seldom wish to solve and which I have constructed, that plays to the strengths of my favored technology while avoiding its pitfalls" is as impressive an argument as you seem to think it is.
I think it's fairly easy to understand if you understand what it was a backlash against. Tables today are used sensibly, for the most part, but the pre-CSS world was truly absurd in its table use.
The reaction may well have been over-the-top, but it wasn't disproportionate given the state of table usage at the time.
CSS's initial forays into layout seem bad today because people think of tables in terms of their intended use (not the now long-gone monstrosities the community actually extracted from them), but in comparison to the previous ecosystem, floats were a relative godsend.
In the words of one of my CS profs, from a few decades ago: "There are only 3 numbers - zero, one, and infinity. And 'one' is often a mistake"
5 different types (default, force_default, normal, override, force_override)
which can be in 4 different places (attribute, node, environment, role) but not all of the types can be in all of the places
PLUS the "automatic" type, which is from somewhere else entirely
Oh and there's inheritance and merging which does not behave intuitively at all because it's not exactly inheritance.
In other words I have early career trauma from someone's extremely unwise priority implementation and am deeply suspicious of ANY priority override system which isn't just code I've written in a normal programming language.
Meanwhile, one of the linked pages mentioned bluegriffon, so I got curious if such editors can handle template languages such as django's.
While I don't know that yet (edit:no templates at all, what a shame), I also found this tutorial, and it was inspiring that such a pedagogical approach to online authoring still exists.
https://www.thesitewizard.com/bluegriffon/bluegriffon-2-tuto...
Edit: no seriously, why don't these editors support at least some established template language? I think dreamweaver had a concept of templates, which made using these editors make at least some sense.
Edit: oh wow dreamweaver still exists. Any of you have experience? Still good?
I like that in Flutter they do exactly as you suggest: they call it mainAxisAlignment and crossAxisAlignment
I wish that one were we elaborated on more :)
You should be able to write
<div color="red" font-weight="bold"/>
Instead of
<div style="color: red; font-weight: bold;"/>
Just kidding. To me the biggest mistake was the standards' slowness in the early 2010s to provide badly needed new functionality such as a proper replacement for table layout, vertical alignment, etc. The cult of knowing specific tricks to get things working properly carried on for too long and made a lot of people annoyed at the semantic web (rip).
Why can't this be dealt with with CSS versioning/features where you can opt into your current-color and a lot of more substantive style behavior while leaving currentColor functional?
>Comments shouldn't have been allowed basically everywhere in CSS (compare to HTML, which basically only allows them where content goes), because it makes them basically unrepresentable in the object model, which in turn makes building editing directly on top of the object model impossible
HTML comments are basically just a HTML tag that isn't rendered. Tools that 'compile' the HTML code into a document tree, including browsers, preserve comments as nodes without any extra effort.
CSS comments can go anywhere:
/*wow*/ .selector /*x*/ {animation /*z*/: 2s /*z*/ linear /*z*/ bounce;}
EDIT: also why is it useful to have comments in the object model in the first place? To access them from js?
They do with left+right, and have done this for a very long time. You only get the anchoring if you additionally set width.
More importantly to me, "display" has been overloaded with two meanings: Display of the element this rule applies to/how it interacts with surrounding elements (none, block, inline, inline-block) and display of the contents of this element (flex, grid).
Which is why we now also have inline-flex and inline-grid.
Edit: Apparently we can now arbitrarily combine inline/block and flex/grid as two values to "display", no idea when this happened: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
- Values for properties with just two valid values available should have been true and false rather than having one more unique word combo to remember forEach.
- I cant quite describe them but float at times has some weird unexpected behavior.
https://stackoverflow.com/questions/23154201/weird-behaviors...
I also don't understand why they never specced the (much simpler) `text-align: -moz-left/-moz-right/-moz-center' which already had precedent in HTML with `<div align=left/right/center>'. It's the saddest part of the "center a div" saga, all the W3C had to do to fix it is to assign a standard keyword to a feature that everybody already implemented, but to this day it still hasn't happened.[2]
[1]: https://pcwalton.github.io/_posts/2014-02-25-revamped-parall...
[2]: After many long decades, they did finally specify block-level `justify-items'. Two problems: a) it's backwards-incompatible with text-align, b) it still doesn't work in Gecko.
If the mentioned mistakes or similar language design mistakes were made. Because mistakes will always be made.
(Unison lang comes to mind but it’s refactor failsafe seems narrow. How about: Antifragile language design? Self-correcting language?)
For example, the Circle compiler extends C++ with its `#feature` directive: https://github.com/seanbaxter/circle/blob/master/new-circle/...
Sadly, the closest I've personally seen to this sort of thing in widespread use is `"use strict";` in JavaScript, which is only a single binary switch. You can't, say, turn on a new keyword, disable a keyword, switch to a different incompatible version of some browser API, etc.
I encourage all language designers to include a feature mechanism in a forward-compatible way. Don't overthink the difficulty: It doesn't need to do anything at first, it just needs to not be a parsing error. Treat it like a comment. FYI, this is the same as having a version number or header size in a binary file format's header, which all sane formats have (there are a lot of insane formats out there...).
edent•6h ago
So many weird design choices in computing are because one person said "this seems right to me" without considering other viewpoints or consulting with the wider community.
Sure, you probably dont want death by committee, but a tiny cabal engaging in groupthink often produces unhelpful results.