Hacker News new | ask | show | jobs
by pastelsky 1837 days ago
Having worked in multiple platforms — web, native desktop and mobile, it still amazes me how far ahead CSS is as a styling paradigm in terms of expressiveness and power!

Infact, it's the best language for styling content ever created. Think about this the next time you have to create a couple of XML files just to get round corners and shadows in Android.

6 comments

+100. I did Android dev for like ~7 years and recently have been doing more Web dev. Yes CSS is a tricky language but I always get where I am going. On Android I frequently have to give up and settle for a more vanilla style because what I want to do will require like 1000 lines of code copied from StackOverflow. Even something as simple as "A rounded EditText with inset shadow" is hours of work. With CSS that's two lines.
Two lines today. CSS has come a loooong way... One could argue that the main advantage of CSS is that is a living standard, constantly adding and improving features and seeing a competition between implementations; whereas more traditional technologies are typically mono-vendor and, for one reason or another, have long stagnated.
To be fair, if you wanted to implement it before CSS support, I think you’d have a hard time reaching 1000 lines to do it. 50ish maybe (in JS and HTML).
I'd suggest checking out Flutter if you're doing mobile dev (or at least Android). It makes styling ridiculously easy.
Agreed! The beauty-per-effort-unit on Flutter is so high. There's a reason that Android's new UI framework looks a lot like Flutter widgets!
Compared to other half-assed declarative formats? Yes.

Try covering dynamic-sized image with an svg surface. Try outlining a hovered element so that outline/shadow covers other items around. Try to baseline align text in non-shallow div hierarchy (which is required to workaround other issues).

When there is a moderate visual requirement I’d better mess around with something like GTK+/Cairo, NSView or QPainter rather than pulling hairs at CSS trying to slap few incompatible js-y solutions into one big ball of bs.

> Try covering dynamic-sized image with an svg surface. Try outlining a hovered element so that outline/shadow covers other items around.

I'd appreciate a visual example of what you are talking about. Seems like a far fetched, obscure-as-hell example to use as an argument. A strawman as they would say. CSS isn't perfect but it's pretty damn powerful for something I can teach a 9 year old.

We can certainly get a lot of work done within CSS's limits. For the auto-generated billion div soup, god speed and good luck.

> We can certainly get a lot of work done within CSS's limits.

You can also hit the ugly points very quickly.

E.g., suppose I want to draw diagrams of text connected by Bezier curves. Looks like SVG is the obvious choice for me. But suppose I add editable text to the mix-- well, HTML5 certainly has plenty of options for me there. And the Javascript to glue a solution together however I want.

Yet, none of those options come with any CSS that allows me to align the baseline of the text in my choice of HTML element with an SVG text element of my diagram. I have to scour Stackoverflow for some holy-shit hack of nested div bullshit just to tell the browser to position HTML stuff the way it does for an SVG text element.

These rought seams joining SVG, HTML, and CSS remain very frustrating until you start reading the specs and list archives to figure out that they were very different tech developed by very different teams with very different initial purposes and use cases in mind

But joining SVG and HTML is really, really not something web developers get to very quickly. It's an absolute niche use case.
Problems from joining SVG and HTML seem like they happen all the time, esp. judging from Stackoverflow questions. Off the top of my head, I remember that an SVG src for an img tag won't inherit from the containing DOM's CSS.

(That's not to say there aren't Javascript exeskeletons that inject the SVG directly into your DOM for you.)

Nah, these aren’t obscure at all.

Covering a image with something (whether SVG or not) is very common, though most of the time the image’s size will be known, or at least known in one axis. We’re talking things like putting captions on top of images.

Needing hover effects to render on top of elements around is even more common—if you want a row of buttons that share borders, by far the easiest way involves this very situation. Example where `position:relative` does the magic:

  data:text/html,<style>button{border:2px solid red}button:is(:hover,:focus,:active){border-color:lime;position:relative}button+button{margin-left:-2px}</style><button>ⅰ</button><button>ⅱ</button><button>ⅲ</button>
If it's very common... how is it difficult?
It isn’t.
It isn't difficult to you because you've memorised that particular hack, And, undoubtedly, many others.

It doesn't make them any less of a hack.

https://news.ycombinator.com/item?id=27376496

We can certainly get a lot of work done within CSS's limits

All I really want is a linear model over current layout model. E.g.

  ...your regular css...

  .wrapper:relations {
    div.text/left == svg.line.underliner-segment/left + 5px
    div.text/baseline == svg.line.underliner-segment/bottom + 2px

    #item-a/center-x == #item-b/center-x

    #item-d/right >= #item-c/left + 20px

    */right <= $this/right - 10px
    */bottom <= $this/bottom - 10px
  }
I don't want play a detective with css properties ever, when there is a proper mathematical model for coordinate relations. Those who are fine with current CSS could then continue to craft wands and potions and everyone'd be happy.
Right.

Thanks for this but

> I don't want play a detective with css properties ever, when there is a proper mathematical model for coordinate relations.

Designers and UI devs would probably rather just write custom shaders on canvas if they have that level mathematical prowess. For most, offloading that cognitive load to an abstraction like CSS is worth it. Let the browser do the math. Playing detective then seems like a woefully arbitrary issue to have.

Those who are fine with current CSS could then continue to craft wands and potions and everyone'd be happy.

I believe it's called the dark arts.

Isn't this basically a normal tagged image? Like one you'd see on instagram/facebook. It displays a little bubble at a given position with the user name of the person in the picture. When you mouse over it changes to indicate it's a link.

Sounds challenging to implement that in straight CSS :) I'd love to see a demo

> Try covering dynamic-sized image with an svg surface.

This isn’t difficult. Two reasonable approaches immediately occur to me on this.

① The traditional one: <div style=position:relative;display:inline-block><img><svg style=position:absolute;inset:0 /></div>

② Using Grid’s ability to put multiple things in the one cell: <div style=display:grid><img style=grid-row:1;grid-column:1><svg style=grid-row:1;grid-column:1 /></div>

> Try outlining a hovered element so that outline/shadow covers other items around.

On hover, ensure it’s on a layer of its own, and if its surrounds are also on layers bump its z-index above theirs. e.g. `:hover { position: relative; z-index: 1 }`. Definitely hacky, but not difficult, unless you want the decoration to render beyond the bounds of a parent element’s layer, such as if it’s in a scrolling area with 0.5em of padding and you want a 1em box-shadow around it—that simply can’t be done, layers are inviolate; but as consolation, other platforms almost certainly have the same limitation.

This isn’t difficult

It indeed is [1].

Expected: a yellow line crossing an entire 236x236 image, in all three cases.

Explanation: svg default size is lunatic (300x150) and it doesn't care of your layout modes, so it clips all drawing beyond that, unless you specify either width/height attributes (not css properties!), or a viewBox, from which it infers missing width/height.

I lost a day to this once, when parent-filling svg clipped 3 of my 5 shapes for no fucking reason. Shapes coincidentally fell either fully into 300x150 box or fully outside of it -- no easy hint for you.

You can pre-calculate that in js, but if you specify .wrapper's dimensions in non-px, or use some aspect fit, you're screwed as well.

[1] https://codepen.io/mhmdqrn/pen/yLMvGJW

True, SVG itself can be surprising if you don’t know what you’re doing with it—it’s a powerful graphics format that supports flexible sizing and aspect ratio handling, which is much of the reason why width/height and viewBox are separate things, and in cases like this it’s important to understand what they each mean (and how any of them are inferred in the presence of the other).

For the sort of thing that you’re doing here, there are two most likely possibilities for what you want:

① Give the <svg> element a preserveAspectRatio attribute, most likely preserveAspectRatio="none" if you’re just trying to draw a diagonal line across the image. This’ll allow it to stretch the SVG, effectively throwing your stroke-width off a bit so that it could look wrong if you use it on multiple images of different aspect ratios.

② Accomplish a dynamically-sized viewBox with percentages: <svg width="100%" height="100%"><line x2="100%" y2="100%"/></svg>

Fortunately all of this stuff is nailed down pretty well now. IE always had trouble with these more unusual aspects of SVG, even to IE11. I fondly remember a design I implemented a decade or so ago that exercised just these sorts of fiddly areas, causing such issues on IE9 that I gave up and made it use the simpler, not-as-pretty non-SVG fallback that was necessary at that time because of IE6–8.

Technology is only as good as its outcomes are. I didn't instantly realize back then that width/height attributes are required, because SVG as an element (not as a powerful format) doesn't respect given CSS layout. You didn't instantly detect the issue to suggest a working solution, probably because you know too much recipes to pick one off the top of the head. This is the end result of such technology - we both spend much more time learning and/or explaining than it could be. Now multiply that by the factor of world and by general shortage of a single-person skill capacity and time.

If you pick any other technology, e.g. an airport gateway system or a shop checkout line, and apply this "can be surprising if you don’t know what you’re doing with it", you'll get a big congestion instead of a functioning airport or a shop. Users are not to blame when the system is based on some cryptic nonsense. Good systems just work, bad systems require custom effort to fly and never scale. These congestions induced by web tech only pull us back and I can't understand why you're so positive with it (if not condescending; sorry if I mistook that).

> Try covering dynamic-sized image with an svg surface.

You could embed the dynamic-sized image within an svg, perhaps even a fully dynamic inline svg.

> Try outlining a hovered element so that outline/shadow covers other items around. Try to baseline align text in non-shallow div hierarchy

I mean at some point you need to use JS. Still, IMHO it's quite amazing how far you can go with a purely declarative language. That also means a myriad of side effects including smooth reflow being taken care of automatically as long as best-practices are followed. Is there any way to write these examples completely declaratively in GTK+/Cairo, NSView or QPainter?

Given the power of XAML styles and templates I respectfully disagree.
Yes, XAML was (is?) quite nice to create interfaces, with notably grid and components support years before CSS got them. It has its pain points (including the different incompatible implementations) but I always did somewhat OK designs faster with it than I ever did with CSS. Android AXML is indeed a (bad) joke though.
Just providing an example of a CSS styled XML file: http://mailmarkup.org/mail-documentation.xsd
The problem with CSS has historically been browser conformance—naturally there’s been some workarounds. However, CSS has been a success because of its ubiquity. However, it is somewhat limited in its extensibility. For app development I really appreciate Qt Quick QML as it’s really nice language for UI development, but also highly extensible. Granted, different use case than CSS in ways.
Bootstrap was effectively the jQuery for CSS, in terms of standardizing what layouts looked like across all browsers.

It gets a bad rap because it's so easy to use for non-designers that a lot of sites that use it don't bother customizing the UI elements like buttons or expand/collapse accordions etc. Or the layout of the page, for that matter. The famous "Every Bootstrap website ever"[0] site outlines this nicely:

[0] https://www.dagusa.com/

Cute, can I have tabs with equal widths based on the longest tab, without knowing the exact number of tabs?
Yes you can: https://wt5hp.csb.app/ (implemented in pure CSS, with some JS to demonstrate that it works)
Thanks! And darn, I forgot about css grid. I think this example wasn't possible with flexbox a few years ago.
No. Ut I’d tell a designer that’s a stupid design and we can get pretty close to it if they really wanted it but overflows will make it look ugly depending on where they want this magic unlimited tab box.