Live data from Hacker News

Ask HN: Is it just me, or is CSS too damn hard?

news.ycombinator.com

301–310 of 358 posts

Re: Ask HN: Is it just me, or is CSS too damn hard?

#301
post #87

I'd recommend spending some dedicated time learning about layout, not leaning on a framework. CSS layout is largely about the relationship between elements. Instead of looking at it as "I want this element on the right," try to see the relationships between elements. What's the group of elements, and what causes them to be where they are? (Generally, complex layouts are nothing more than nested groups of elements.) O…

That's really interesting. I'm also firmly in the space of finding CSS layout inscrutable (CSS styling is fine). I'd concluded that the issue is precisely the lack of peer-to-peer relationship constructs. Everything seemed based on 2 constructs: 1. Flowing 1D content (text) into a 2D space 2. Hierarchical relationships, i.e. positioning children with respect to parents. I haven't looked deeply into flexbox or grid. M…

I'd say grid is much more of a "new" concept for CSS than flexbox.

And while I'd always understand learning the basics - to get stuff done most everyone landed on hard coded (sort of) grids before "CSS grids" came out.

Beyond that, I still recommend looking in the (reborn) CSS zen garden:

http://www.csszengarden.com/

Re: Ask HN: Is it just me, or is CSS too damn hard?

#302

> Is it common for other developers to have issues with it, or is it just me? Is there any material out there that made CSS "click" for you? If you're coming from an application development background, you will hate CSS layouting. It's the most ass-backwards way of structuring a UI that you will ever encounter. A lot of web people who never used stuff like Qt, Swing, Winforms (etc) just don't realize this. They think…

The thing is, Winforms et al. solves a much simpler problem. It only runs on one platform, it does not handle scaling gracefully, it does not even attempt the solve the complex problems of text re-flow to accommodate different size viewports etc. Swing is fine for cross-platform GUIs but can it render books in high-quality typography on various devices? (Or would it use a HTML rendering control with CSS support for this?)

The design of CSS makes a whole lot more sense when you understand what problem it is designed to solve.

> CSS wasn't originally meant to do layouting

This is not correct. The first version (1.0) did not support advanced layouts but it was definitely in the cards. DSSSL was an inspiration and supported layout.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#303
post #189

Earlier quoted context omitted.

Good comment. CSS is actually pretty simple, as long as you start with the smallest elements and work up. It becomes a nightmare if you try and address everything individually. It’s not really a programming language, but a series of guidelines. I’ve seen this simplicity actually throw developers as they’re used to something much more complex and systematic. Preprocessors like SASS are great, but I wonder if they’re d…

Pixel perfect is not possible in HTML/CSS. Stop spreading this. But it is very possible to make websites look very good and inline with what was designed. But good luck making an input, button and select the same height. It's just not going to be pixel perfect. What is pixel perfect in your browser isn't in others. But what designers should now is it doesn't matter as long as it looks good for everyone.

> But good luck making an input, button and select the same height. It's just not going to be pixel perfect.

Sure you can. Just see how Bootstrap does it.

It is true that for a long time, input controls were rendered using the native platform controls, so there were are a lot of differences and limited styling capabilities. But these days all browsers (as far as I am aware) use the browser rendering engine for input controls, and they are fully stylable.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#304
post #299

Sorry, but web UI in general is an industrial dumpster fire. I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter. The layout "math" should all be on a server. That way we could pick and choose layout/style engines that fit our domain and shop preferences: OOP, FP, set-theory, declarative, whatever you wish; NOT the viewpoint of T…

> I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter.

OK...so if you search for something on google you need to know the coordinates for every pixel in the rendering of the text you are looking for?

Re: Ask HN: Is it just me, or is CSS too damn hard?

#305
post #262

Earlier quoted context omitted.

> hey, just center this thing Step 1: On your container div... display:flex; justify-content:center; align-items:center; Step 2: There is no step 2.

Yeah, with flexbox we can finally do the layouts we could do with tables since 1996, and it's only a little harder.

With display:table from CSS 2 you could do the layouts you could do with HTML tables. Flexbox solves a different problem - for example you can't have rows and column in a flex. There is some overlap in functionality, but generally flex is more convenient to use.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#306
post #292
post #282

Earlier quoted context omitted.

Some of the names are unintuitive, sure. Though I don't think the ones you provided are in particular; I think your distaste for those is subjective. But it's really not hard to learn the names for concepts which themselves make sense (at the beginning, perhaps, but not for someone willing to put in a modicum of effort). Many of the worst parts of CSS, and even JavaScript for that matter, come from the need for backw…

> Some of the names are unintuitive, sure. Though I don't think the ones you provided are in particular; I think your distaste for those is subjective. Relative and absolute... Is there a CSS book or tutorial that doesn't take a jab at these names when explaining positioning?

Relative means "relative to the default position", which makes perfect sense to me. Absolute means "I'm explicitly setting this position", which also makes fairly good sense. There are probably better names they could've used for "absolute", but there are also much worse ones. But the point is, these are just names. What really matters is the quality of the underlying system. You don't hear people complaining that Lisp uses made-up strings like "car" and "cdr" to refer to the start and tail of a list, or that bash uses "ls" and "cd" to list and change directories. Those are far less intuitive than "position: absolute".

Re: Ask HN: Is it just me, or is CSS too damn hard?

#307
post #304
post #299

Sorry, but web UI in general is an industrial dumpster fire. I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter. The layout "math" should all be on a server. That way we could pick and choose layout/style engines that fit our domain and shop preferences: OOP, FP, set-theory, declarative, whatever you wish; NOT the viewpoint of T…

> I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter. OK...so if you search for something on google you need to know the coordinates for every pixel in the rendering of the text you are looking for?

Who is "you" in your scenario? It would be similar to printer formatting languages. The printer driver translates a document into lines, vectors, and polygons, and sends those to the printer as page coordinates, except the page length is not limited to paper's limit. (We'd probably have to add event triggers on designated polygons to handle UI interaction.)

The equivalent of the "printer driver" is the rendering engine on the server that takes your document or data and formats it using whatever formatting/layout engine YOU choose. The "input document" could be HTML even. We don't have to toss away HTML to use it. The difference is it doesn't have to be HTML.

In some ways it would be closer to working with PDF documents, except it wouldn't be based on "paper" conventions. The width would typically be dictated (or requested) by a particular device (client), and the length would be whatever the renderer decides is needed, typically based on the content being rendered.

Office workers love PDF because it's WYSIWYG. Browsers don't butcher their original vision. But, keep in mind the layout engine does not have to be WYSIWYG. The key point is your shop decides, NOT a standards committee. Layout engine FREEDOM! Hallelujah!

Re: Ask HN: Is it just me, or is CSS too damn hard?

#308
post #299

Sorry, but web UI in general is an industrial dumpster fire. I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter. The layout "math" should all be on a server. That way we could pick and choose layout/style engines that fit our domain and shop preferences: OOP, FP, set-theory, declarative, whatever you wish; NOT the viewpoint of T…

So I need to wait for a network roundtrip for all tabs if I resize my browser? So sites can freely ignore my styling settings (it's bad enough already)? ...

Re: Ask HN: Is it just me, or is CSS too damn hard?

#309

The Bootstrap CSS framework is the easy button of CSS It makes writing CSS enjoyable and fun https://www.youtube.com/watch?v=wesUO81YX0U

My experience is that Bootstrap makes 95% easier but the 5% that doesn't cooperate eats up all the savings of the 95%. When it doesn't do what you intend, it's a black box that usually ends up being "fixed" using obscure CSS or JavaScript fudges found on Stackoverflow etc. It feels like: "Just put in 'grf:snig;bleppo(){99.foo()}' here, and that should fix it."

Re: Ask HN: Is it just me, or is CSS too damn hard?

#310
post #308
post #299

Sorry, but web UI in general is an industrial dumpster fire. I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter. The layout "math" should all be on a server. That way we could pick and choose layout/style engines that fit our domain and shop preferences: OOP, FP, set-theory, declarative, whatever you wish; NOT the viewpoint of T…

So I need to wait for a network roundtrip for all tabs if I resize my browser? So sites can freely ignore my styling settings (it's bad enough already)? ...

I'll agree that resizing delay is probably a weakness. But I'd gladly trade that away for simplicity everywhere else. Also, because it wouldn't need gobs of CSS and JS for formatting, the re-render code (vectors) would not be that big and thus transfer relatively quickly. Remember, we are simplifying what the client needs to do and know. Excellent observation, by the way.
Post reply on HN