Live data from Hacker News

Why is CSS the way it is?

increment.com

151–160 of 173 posts

Re: Why is CSS the way it is?

#151

This is a somewhat superficial history that only briefly touches on origins, and doesn't discuss the fundamental idea behind CSS, from which everything else is, directly or otherwise, a consequence. Two decades ago I was overjoyed to discover that Scheme was finally going to have a useful application beyond illustrating SICP and writing koans to amuse myself, because DSSSL was on the cusp of evolving into the last do…

I have a really dim recollection of an IBM WebExplorer variant that had limited support of DSSSL but it may have been tied to the work we were doing with HyTime. None of the interesting WebExplorer variants ever saw the light of day in public and it was killed fairly quickly by neglect.

Re: Why is CSS the way it is?

#152
post #102

Earlier quoted context omitted.

And then you discover semantic classes for styling elements, eg `.amazing_h1.with_padding` and use nested selectors for layout like `.blog_post > h1` or maybe even utility classes `.amazing_h1.with_padding.centered'.

If you're doing class='centered' or class='with_padding', I don't see any reason not to just do style='align-self:center;' or style='padding: 1rem;' instead. The class names communicate less (Is that centering the content of the element, or the element itself? Is that vertical or horizontal centering, or both? Is the text being centered?). And it doesn't allow you to make sitewide changes like a semantic class does (…

Disagree. This is utility classing and you can target pseudo elements and deal with responsiveness. Tailwind is pretty popular and uses this methodology.

Re: Why is CSS the way it is?

#153

Earlier quoted context omitted.

My point is that there's nothing in CSS that's exceedingly difficult to understand once you sit down to learn it - it's that you're often sitting down to learn things that are entirely idiosyncratic to CSS and act as impediments to creating anything beautiful. I could abandon CSS and use SVG to create prettier things pretty quickly, because although SVG has some gnarly parts, programmatically manipulated it makes muc…

> Then I'm dealing with the interaction of specific elements and document flow and everything is liable to fall apart the second some mismatch between my mental model of layouts and CSS's actual model occurs Here lies the problem. If you fix your mental model, then your layout won't fall apart. It's the same as in any other language. Haskell doesn't match my mental model, but it's not the programming language's fault…

Haskell's problem is that it's so consistent (e.g. in enforcing purity, to the point of frustration for common tasks), if you don't understand it, you won't get anywhere. CSS's problem is rather the opposite - or if it's consistent it's consistent in its own, rather frustrating way. Mathematics may not be how we inherently reason, but I feel good having solved a problem in Haskell. I feel bad having solved most problems in CSS.

Re: Why is CSS the way it is?

#154

IMHO this article inadvertently shows why people hated CSS at the start. He spends a lot of time talking about color space conversions that few developers care about and Unicode filtering that even fewer people know about but glosses over basic layout by mentioning how floats allow for better inline images. It’s like the designers didn’t even think about layout because that problem was already solved with HTML tables…

I remember spending ages on various ways to implement "the golden layout" or whatever it was called. Edit: Holy Grail. One header on top, then three columns, and then a footer. And the middle of the three columns should scale with screen width and screen height, such that the rightmost column was at the edge, and the footer was at the bottom of the screen if content was less than screen height. And then a-list-aparts…

I have a CSS book from that time, one I kept too long because I felt it was one of the better CSS books in its time and hasn't been replaced as I keep a certain amount of books for decorative purposes and haven't bought new development books in a while.

The final chapter, in a "putting it all together" style spent most of its time om a holy grail layout.

If I was writing a modern CSS book, this topic would be somewhere in the second quarter in a chapter on grid and flexbox.

Re: Why is CSS the way it is?

#155

IMHO this article inadvertently shows why people hated CSS at the start. He spends a lot of time talking about color space conversions that few developers care about and Unicode filtering that even fewer people know about but glosses over basic layout by mentioning how floats allow for better inline images. It’s like the designers didn’t even think about layout because that problem was already solved with HTML tables…

I remember the reason behind skipping table for layouts was to help browsers render the page progressively.

Tables - instead - needed the whole chunk to be rendered. i believe this reason is still valid!

Re: Why is CSS the way it is?

#157

IMHO this article inadvertently shows why people hated CSS at the start. He spends a lot of time talking about color space conversions that few developers care about and Unicode filtering that even fewer people know about but glosses over basic layout by mentioning how floats allow for better inline images. It’s like the designers didn’t even think about layout because that problem was already solved with HTML tables…

Table-based layouts are basically really practical for layouts. It could really have been extended to make it more styleable and also to allow for stackable columns and more responsive layouts instead of whole sale replacing them with CSS and DIVs.

Also, it would have been nice if HTML supported the concept of data fields WITHOUT explicitly needing javascript.

HTML could also have allowed for an easier way of specifying different layout types without going into CSS wizardry to support responsive layouts.

For instance, something like the one below where data fields are specified in a separate block, reusable components in another and then finally the actual layouts.

#Data blocks here

   1

   
         [(1, "Barcelona"), (2, "Madrid")]
   

   
         [("es", "Spanish"), ("en", "English")]
   

   
         [("Home", "/index.html"), ("Profile", "/profile")]
   

   
         [{title: "Title comes here", content: "Content comes here"},{title: "Title comes here", content: "Content comes here"}]
   

# Reusable components here

   

     #options($languages[0], $languages[1], "es")  

      #options($cities[0], $cities[1], $selectedCity)
     
    #links($nav[1], $nav[0])
       

     

   

   

       #foreach ($posts : $post)

         $post.title

         

$post.content

#endforeach Copyright Company.com

    
     
        

        
        
        
     
      
         
         

        
        
        
      ...
    
    
       
         

        
        
        

       
  

   ...

Re: Why is CSS the way it is?

#158
> Why is CSS the way it is?

Because all its original creators were programmers and didn't think to invite even a single person who'd ever worked an hour on visual design. Check on Wikipedia, it's unbelievable but true.

Re: Why is CSS the way it is?

#160
post #146

Earlier quoted context omitted.

Wow, I'd absolutely love to hear more about this if you've got something to share ... To win a sizable portion of HNers, it suffices to say that DSSSL was the Scheme-based styling and transformation language of SGML (implemented by Jade/OpenJade). I can only imagine where we'd be now if DSSSL had won over CSS and similar FOSI-like ad-hoc styling languages (or even SGML's own LINK process declarations that however was…

> I can only imagine where we'd be now if DSSSL had won over CSS Or if Brendan Eich had prevailed when he wanted to embed Scheme in Netscape instead of Javascript.

He embedded Scheme in JavaScript instead but nobody noticed. As Lou Reed once said, “JavaScript is Lisp in drag”.
Post reply on HN