Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS: Unavoidable Bad Parts

matklad.github.io

Post reply on HN
Print view View original

81–88 of 88 posts

Re: CSS: Unavoidable Bad Parts

#81

Post by DarkUranium »

siddboots wrote: post #42
seanwilson wrote: post #33

> If you “View Source” on any “real” website, you’ll notice that everything has layers and layers of wrapper elements, so you might be tricked into thinking that wrappers are how you solve layout problems. I can’t really agree or disagree here, as I never wrote “production” CSS, but, in my experience, it’s much easier to understand if you do the opposite — restrict yourself to using only markup-meaningful semantic ta…

20 years ago everyone was sold css entirely on the premise that, once the standards were adopted by all of the browsers, we would all be writing purely semantic html with completely orthogonal and swappable css. And today literally no one designs web sites that way - html today is mostly specific to presentation. It feels like pretty dramatic technological failure to me.

I feel like CSS would be in a much better place if they went with the Cassowary proposal for layout.

It would avoid the whole mess of block vs table vs float vs flexbox vs grid (and also absolute vs relative vs fixed) positioning.

Basically, it feels like 90% of CSS is it trying to fix its past layout mistakes & limitations.

Re: CSS: Unavoidable Bad Parts

#82

Post by CableNinja »

elxr wrote: post #38
TonyStr wrote: post #35

Earlier quoted context omitted.

This is true. I use increased font size on my phone, and so many websites are borderline unusable because of massive unnecessary padding. But I am also a culprit of using rem for everything. What is the alternative? Pixels?

Thanks for helping me realize my accidental anti-pattern. Can you link some of the sites that do that the worst. I want to use those as references to fix my UI (on increased font-sizes on small screens) before releasing an app I've spent 4+ months on.

Perfect example for you: indeed.com (desktop site). unless its been fixed recently, huge swaths of area are already empty padded space, made worse by zooming

Re: CSS: Unavoidable Bad Parts

#83

Post by littlestymaar »

FelipeCortez wrote: post #70
littlestymaar wrote: post #69

Earlier quoted context omitted.

For that to work I would need to define a custom component from JavaScript, wouldn't I? (and I thought custom components had to contain an hyphen in there name, is that wrong?)

try it! data:text/html, A B C grid{display: grid} afaik to create a CustomElement you need to use dashes, yes, but in this example ` ` is an HTMLUnknownElement, which renders just fine. some discussion here: https://stackoverflow.com/a/22545622/2393963

TIL thx!

Re: CSS: Unavoidable Bad Parts

#84

Post by littlestymaar »

assimpleaspossi wrote: post #73
littlestymaar wrote: post #67

Earlier quoted context omitted.

Not really. This would not be different to and associated elements, which are arguably better than a div soup.

Yes, really. Even is used to represent the data, not the layout, though it will be laid out as a table but it's probably the only element that does such a thing.

> Yes, really. Even is used to represent the data, not the layout

Nope. It's a html tag to lay out data in a table form!

> but it's probably the only element that does such a thing.

, ,  all come with an associated layout implication. But the worst offender are  and , which carry zero semantic meaning and just means “I'm a block element” and “I'm an inline element”, those are pure layout element. In fact are the ones I'm using as template for my demand of  or  elements.
And html isn't just tags, it's tags and attributes on these tags, and things like hidden, height or width are indisputably related to layout and not to data.
The idea of HTML as a pure semantic layer with no layout consideration may be a general design philosophy for the language, but that's by no way a faithful description of what HTML actually is in practice. And pretending it is, isn't helping.

Re: CSS: Unavoidable Bad Parts

#85

Post by jkrejcha »

littlestymaar wrote: post #84
assimpleaspossi wrote: post #73

Earlier quoted context omitted.

Yes, really. Even is used to represent the data, not the layout, though it will be laid out as a table but it's probably the only element that does such a thing.

> Yes, really. Even is used to represent the data, not the layout Nope. It's a html tag to lay out data in a table form ! > but it's probably the only element that does such a thing. , , all come with an associated layout implication. But the worst offender are and , which carry zero semantic meaning and just means “I'm a block element” and “I'm an inline element”, those are pure layout element. In fact are the ones…

Eh. HTML in its recent iterations made it very clear to try and separate itself from layout concerns. It's why was deprecated.

With that: is really only meant for actual tabular data and not about layout. It really isn't about the layout. It got abused for layout because it was the only thing that worked in a lot of cases (especially amusingly enough, email)

and I think I'd agree, even if they did eventually get retconned to be "bring attention to" and "idiomatic text". Same with and friends. This happened with other elements too.

I think it's fair to acknowledge the realities (people who are writing HTML a lot of times use to mean "bold") of usages but ideally the semantic meanings are useful. I have seen cases where "" emphasizes it by doing something other than bold for example

Re: CSS: Unavoidable Bad Parts

#86

Post by littlestymaar »

jkrejcha wrote: post #85
littlestymaar wrote: post #84

Earlier quoted context omitted.

> Yes, really. Even is used to represent the data, not the layout Nope. It's a html tag to lay out data in a table form ! > but it's probably the only element that does such a thing. , , all come with an associated layout implication. But the worst offender are and , which carry zero semantic meaning and just means “I'm a block element” and “I'm an inline element”, those are pure layout element. In fact are the ones…

Eh. HTML in its recent iterations made it very clear to try and separate itself from layout concerns. It's why was deprecated. With that: is really only meant for actual tabular data and not about layout. It really isn't about the layout. It got abused for layout because it was the only thing that worked in a lot of cases (especially amusingly enough, email) and I think I'd agree, even if they did eventually get retc…

> HTML in its recent iterations made it very clear to try and separate itself from layout concerns.

That's what I'm saying, it's a general design principle for new developments, but that's it. (And I don't think that's a good one)

> It really isn't about the layout. It got abused for layout

It wasn't abused for layout, it was all about layout in the first place. If it was about data it would never have been possible to “abuse” it for layout, because an heterogeneous table with nested sub tables makes no sense from a “data” point of view. The fact that this was supported from the beginning shows what it was built for.

> but ideally the semantic meanings are useful. I have seen cases where "" emphasizes it by doing something other than bold for example

But I agree with that. I'm not saying we shouldn't have semantics elements in HTML, I'm saying that pretending that HTML “is only about data” is silly in a world were something like 80% of HTML tags in web apps are and that are here only for layout purpose.

Re: CSS: Unavoidable Bad Parts

#87

Post by yencabulator »

nicoburns wrote: post #57
littlestymaar wrote: post #46

Earlier quoted context omitted.

> so there often aren't semantic HTML tags that would make sense. Pet peeve of mine: there should really be ` ` and ` ` elements, as well as ` ` (flex item) and ` ` (grid item) for the child element instead of relying on a div soup with CSS attributes everywhere.

There's nothing stopping you from defining those yourself for your own websites: grid { display: grid } will work in every modern browser.

You're supposed to only use custom elements with a dash in the name. Otherwise the spec can add an element that means something new, and you've accidentally used that name.

Re: CSS: Unavoidable Bad Parts

#88

Post by RandyRanderson »

Randy's Axiom 173: VERY widely used techs are some of the worst, ill-conceived techs ever.

However, no one will admit this because:

. many people don't know them (the techs) well enough because they're so abstruse. Some people would argue this a necessary feature.

. many people only know them and so can't compare them to something else

. people that do understand them typically have financial or ego reasons to look the other way

. people that do understand them AND are rich and happy are afraid of all the other ppl in this list.

Generalization: any widely use tech must be extremely complex or extremely simple (eg TCP).

Post reply on HN