And why the hell green? Ruby's not Python :(

You mean Ruby's not Emerald ;)

Has anyone tried rendering the current docs with the old theme?

- CPU usage and rendering overhead/waiting time is noticably higher than on the old version.

- The supposedly responsive functionality means that the sidebar hides ~half of main content on my default window size and resolution on desktop. I have to zoom out to be able to read at all.

It doesn’t work very well on mobile. Though, I’m not sure that the old one did either.

There’s too much white space. Documentation should be compact so that you can fit as much as possible on the screen while remaining legible.

The colour.

I’d even say it’s harder to make a text website NOT render well on mobile. Doesn’t HTML handle that by default, unless you use some freakishly long text without spaces?

I can. This is pretty typical.

I’m not a (frequent) Ruby user, but I routinely check the Go documentation, the MDN, the Python documentation, and several other language documentations on mobile. Because sometimes I will think of something while I’m walking my dog, or while I’m in my couch, or before sleeping, or at any other moment.

Mobile UX is exactly as important as desktop UX. And for a text only website (ie. not a web app) you don’t even need to spend time to make it work, it’s almost the default behavior. You have to go out of your way to make a text website that doesn’t render well on mobile.

  - main { max-width: 800px; }
  + main { box-sizing: border-box; max-width: min(864px, 100%); }

First, I assume the problem is that, when viewed on mobile, this website is wider than the screen. (Or wider than the browser window.) This makes some horizontal scrolling necessary in order to read some of the text.

No matter how narrow I make the browser window on a desktop, the same problem never occurs, so at first glance this looks like a bug in the mobile browser (which for me is Firefox Focus).

The `box-sizing` CSS property determines whether you want the size of an element to be set to the value you specify, or to something else. You might ask "why would I want something else?", and that's a good question.

Anyway, `box-sizing: border-box` means that when you set the width of the element, it won't be any wider than the width that you set. The default value of this setting is `content-box`, which means that the "content" of the element won't be any wider than the width you set, but, if the element itself uses any padding or borders, those don't count toward the width and the element will be wider than you said it should be.

I assume the adjustment to `max-width` is intended to do two things:

(1) prevent the width of the element from exceeding 100%, presumably related to the width of the browser window;

(2) otherwise, raise the previous maximum by 64px, to adjust for the fact that padding is now included in the notional width of the element. There was probably 64px worth of padding originally.

The problems I see in my own analysis are:

(a) We're only adjusting the `max-width` property, which means that if an element wants to be narrower for other reasons, such as the width of the browser window, that was always allowed. It's not clear to me why this wouldn't have been happening in the page as delivered.

(b) As I mentioned above, the problem that occurs on mobile does not ever occur on desktop, no matter how narrow the browser window gets. This suggests that it isn't a problem with the CSS, but rather with the mobile browser.

They clearly wanted to support mobile (otherwise the hamburger menu is unforgivable) and already spent time making it partially work, but it looks like they just bailed out early before going the final 1% of the way to it looking polished (see a sibling's two-line fix [0]).

[0] https://news.ycombinator.com/item?id=41346674

Its a fact that a large share of page visits are now done on mobile, depending on the content.

In print, people went to great lengths to get the highest contrast possible. I see no reason why we shouldn't do the same on screen.

"color: #191919;"

Here's some real high contrast, and IMO a perfectly designed website:

https://motherfuckingwebsite.com/

Previous HN discussion:

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

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

The best colors are ones that are subtly off of pure white and pure black; to the point where you can’t even tell. My website uses #191919, which you can’t consciously tell isn’t black, but looks better for it.

=> https://matthiasportzel.com

Print’s a different beast. I used the same concepts to design my business cards and they looked washed out using off-black. Paper reflects environmental light (instead of emitting its own light) so you can crack the contrast as high as you want and the end result won’t be pure black on pure white.

You probably don't remember because you have not needed to read Ruby documentation on mobile. Good news though -- I suspect you are not alone in this.

Yea why the heck did they pick green? I get red can look like errors but I’m certain there’s a cheerful ruby red out there that would have worked as an accent color for Ruby’s documentation. Green just feels so wrong to me for Ruby.

[1]: https://www.ruby-lang.org/fr/

The Python logo has been blue/yellow in the modern era and monochromatic prior, but the Python IDLE icon DID used to be green[1]. Which in practice probably cemented into my brain very early on, since I learned Python with IDLE!

[1]: https://github.com/certik/python-2.7/blob/master/Lib/idlelib...

...why?

Here's the least reality-informed, most popularly well-known image of a python you can find: https://static.wikia.nocookie.net/villains/images/a/a1/Kaa_O...

The goal was to move in the right direction, but make it similar enough that it would get quick approval without rocking the boat much (yet).

I would expect 95% of the user base to be reading these docs on a laptop or desktop.

- Its very hard to navigate around and easy to get lost with links.

- Mobile view is borderline unusable. Need to scroll horizontally to read a sentence.

- Cursor is a beam while hovering over the sandwich menu icon

[1]: https://docs.ruby-lang.org/en/3.3/

And green? How did that get approved?

I'm glad things are still moving in the Ruby community. I use it every day. But Elixir is winning the mind-share battle over Ruby at $dayjob these days. And their documents is second to none. One of the best that I've used.

Personally I prefer the look of rubyapi.org over either of the official ones, but this new one kinda feels like a step backward from the prior one.

- sent from my iPhone

That one's a bit too much red for my taste :) There's a sweet spot to find that's closer to "nice accent colors" than "aggressive red wall of text"

It looks like the mobile view is getting fixed [1].

[1] https://github.com/ruby/rdoc/pull/1162

That seems to be the curse of our time: Function follows form.

As a terrible Ruby programmer with pretty good 55 year old eyes I can't read these docs at all. Everyone is complaining about the color scheme (which I agree with) but its the font choices (lightweight, grey on grey) that kills usability for me.

When I'm looking at docs I need to find what I need quickly, and searching a sea of whitespace and barely there text is not great.

Hilarious!

Random example: https://docs.ruby-lang.org/en/master/ARGF.html#method-i-each

Love the new colour scheme, easy to read (on desktop) and feels more chill than reds and greys.

The main font is very thin light gray font to begin with that makes it very hard to read even on a 4k monitor

Talk about irony. I increased the font to 150% so I could read that very sentence, and it's literally impossible to do so, because the sidebar covers the text when you zoom in that far. And the only reason I zoomed in that far was because they used Lato-light rather than Lato-regular. Maybe Ruby isn't used for accessible web development.

What an unnecessary comment. Sure, the docs website could use more work, but what does the choice of a language used for back-end development have to do with the quality of the front-end code (non-Ruby) in those same projects?

It's 2024. Accessibility is absolutely worthy of comment, particularly if you're boasting about being a language used for web development. They could have used one of the thousands of available existing solutions rather than rolling their own.

> a language used for back-end development have to do with the quality of the front-end code (non-Ruby)

Ruby is used for a more than the back-end. Check out Sinatra or Rails.

I'll probably create custom CSS rules for the doc if this is the final version and be happy with it. I've been using a custom dark theme for HN for years and I'm happy with it. I'm glad we still have enough control over web pages to do that!

I know there is devdocs [1], but unfortunately it need to implement scrapers and filters for each site specifically.

[1] https://devdocs.io/

ruby-docs.org is sadly gone https://web.archive.org/web/20230615061406/https://www.ruby-...

There is https://rubyapi.org and https://ruby-doc.org left from what I know

When that is done it should be a good start.

I hope we'll see Ruby renaissance soon. Python must be avoided because of the social and governance issues. I think everyone got the message that it is a fools errand to contribute to an organization that is infested with apparatchiks who treat the actual work horses with contempt. Frankly, I think Python has an uncertain future and should be avoided for non-LLM startups.

One of the best websites, GitHub, is written in Ruby. Python has no website that comes even close.

So it is Ruby or Javascript or Golang or Scala or (?). For those coming from Python, Ruby should be easiest.

Like what do you expect from me? I would be rendering these docs in a w3 emacs frame...

I really don't want to assume incompetence or ignorance at all since I'm sure someone worked really hard on this. But I'm genuinely puzzled by a lot of what's going on.

If i stumbled onto this site while looking for docs about a ruby method, i'd think I landed on the docs for some other programming language or fork of ruby. That's how off-brand this is - to the point of being disorienting as a user.

There are not a lot of things that create a brand around a programming language, and color is definitely one of them.

This is such a tasteless design decision for something meant to be official ruby documentation that I can't even appreciate any other changes that docs may introduce. And then the fact that it doesn't even work on mobile...

I am truly baffled anyone would think this is in good taste.

the last time I saw such a fumble with ruby related docs was back around 2014 when relishapp was the only place to get rspec docs. It's UX was such a painful mess that i just avoided it at all costs. Glad to see it's dead now.

If you thought it used to be red, you are probably thinking either of ruby-doc.org, which is an unofficial third-party site (but is older than docs.ruby-lang.org), or of the Rails docs.

  #root { color: black; }
  main { color: var(--text-color); }

Most people just use rubyapi.org because it’s modern and looks good. It’s backed by the Ruby foundation.

These docs are just the “official docs” which I almost never even use anyways. Glad they don’t look like they’re from 2001 anymore but I’m likely to keep using rubyapi.org as it’s just way out ahead in looks and mobile support.