Live data from Hacker News

Incomplete list of mistakes in the design of CSS

wiki.csswg.org

11–20 of 132 posts

Re: Incomplete list of mistakes in the design of CSS

#11
post #4

I'd like to propose for the list: 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

This "headings closer to the content" suggestion is very good.

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.

Re: Incomplete list of mistakes in the design of CSS

#12

Earlier quoted context omitted.

My favorite part about that is how we came back around to display:grid

Until then, display: table kept everyone calm.

No, dealing with tables was like trying to build a house out of tempered glass.

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.

Re: Incomplete list of mistakes in the design of CSS

#13
post #4

I'd like to propose for the list: 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

moreover h* is just broken whenever dealing with more dynamic content — it simply can’t reasonably be made to work according to accessibility recommendations — and the accessibility guidelines around never skipping a level themselves are ridiculous given the practical reality that dynamic content exists and we have only h1, h2, etc. to work with — the readers and specs are what need to adapt here, not the entire internet

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

Re: Incomplete list of mistakes in the design of CSS

#14

Earlier quoted context omitted.

Until then, display: table kept everyone calm.

No, dealing with tables was like trying to build a house out of tempered glass. 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.

> If I add or remove a random element, the rest of the elements stay in the correct place.

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.

Re: Incomplete list of mistakes in the design of CSS

#15
post #7

It is extremely funny to me that the list thinks the mistake about !important was using the exclamation mark sigil, and not the concept of a single priority level. 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"

As opposed to the 15 levels of priority available in Chef.

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.

Re: Incomplete list of mistakes in the design of CSS

#16
post #4

I'd like to propose for the list: 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

moreover h* is just broken whenever dealing with more dynamic content — it simply can’t reasonably be made to work according to accessibility recommendations — and the accessibility guidelines around never skipping a level themselves are ridiculous given the practical reality that dynamic content exists and we have only h1, h2, etc. to work with — the readers and specs are what need to adapt here, not the entire inte…

I like how z-index works, currently. And though I agree with the article, it should apply to all elements by default, I'm not sure how you'd do stacking differently in a way that'd work any better than the current situation?

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.

Re: Incomplete list of mistakes in the design of CSS

#17
This felt relieving. As in: some part of me had felt stupid for thinking some of this seems really unintuitive when using it in practice. Like z-index stuff, margins, vertical-align, border-radius, ...

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?

Re: Incomplete list of mistakes in the design of CSS

#18

I will never understand the bizarre scene of the web's smug collective declaration that tables were dead and not to be used juxtaposed against the years it took to regain the ability to reliably center things. Assuming one agrees that we even did regain it. 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

I think it was advised a bit too early, but ever since flexbox entered the scene, tables for page formatting became irrelevant.

And just in case, nobody ever said tables were dead. Tables were declared bad practice for page formatting, not for tabular data.

Re: Incomplete list of mistakes in the design of CSS

#19
Are they taking requests? I know just enough CSS to hang myself, but one thing I can never keep straight in flexbox is "align" vs "justify". Could not have used something like "main-axis" or "cross-axis"? Intentionally had to be somewhat obtuse from how it would be used?

Re: Incomplete list of mistakes in the design of CSS

#20

Are they taking requests? I know just enough CSS to hang myself, but one thing I can never keep straight in flexbox is "align" vs "justify". Could not have used something like "main-axis" or "cross-axis"? Intentionally had to be somewhat obtuse from how it would be used?

Yea align and justify get me everytime.

I like that in Flutter they do exactly as you suggest: they call it mainAxisAlignment and crossAxisAlignment

Post reply on HN