Hacker News Reader

Comment by abhibeckert | Hacker News Reader

> being able to style and control the width of the scrollbar is useful

No it's not. I have operating system wide settings for how scroll bars should work and the rules are complex with visibility and size of the scroll bar changing from one second to the next.

I expect my scroll bar settings to apply to all websites and they are significantly better than what codepen does.

Codepen also doesn't allow me to scroll past the beginning/end of the file, which feels jarring and just wrong with a touch scroll device.

And I'd bet it also falls apart with assistive technology for people who can't physically operate a mouse or trackpad, which in most countries is illegal. Why open yourself up to those issues?

View on HN

> Codepen also doesn't allow me to scroll past the beginning/end of the file, which feels jarring and just wrong with a touch scroll device.

Stuff like this often happens because of a lack of native styling options. Can’t change the appearance of the scroll bar (for, yes, often dumb reasons)? OK then we’ll use a giant JS library that poorly replicates every aspect of scrolling.

At least with native scroll styling, ugly as it may be, you get native behaviours.

This doesn’t make any sense. The native behavior is what OP wants. No one needs to recreate the native behavior, it is already available

The person you're reacting to is making a distinction between a native (in the context of browser) scrollbar with the ability to change its presentational style (but not behavior) and a completely custom JS driven scrollbar with likely different behavior from the native experience.

> highly opinionated solutions as something definite even though it has a narrow focus on what the author cares about

Most users either don't have such strong opinions about their scroll bars, or would prefer it looks coherent with the application, or OS-native (your preference). But I can almost guarantee the larger group of non-technical users will have never thought about the styling of their scrollbars for more than a few seconds.

Also in terms of accessibility, so long as they're doing CSS-only changes, and the bar is sized compliant and has proper focus states, assistive technology won't care.

They won't care as long as it's consistent. The only way for it to be consistent is for people not to touch it.

> Also in terms of accessibility, so long as they're doing CSS-only changes, and the bar is sized compliant and has proper focus states, assistive technology won't care.

Eh, it depends on your audience. My father has very poor eyesight. He doesn't use any assistive tools (e.g. screen readers or magnifiers), but he does need his computer-reading glasses. Accessibility isn't just ADA compliance and/or screen reader support.

Same argument for why we should use tabs over space when accessibility seems squarely focused on the blind and screen readers when visual impairment is a broad spectrum. My eyesight isn’t ‘bad’, but it isn’t what it used to be and with so many code bases using 2-space indentation, I wonder why this isn’t configurable as I have a lot of difficulty discerning the contrast when it’s so shallow.

Any modern IDE will allow you to display 2-space indentations however you wish.

Where is this option in Visual Studio 2022, and Xcode?

Considering the trend now is to straight up remove scroll bars (why the fuck...), I expect conversations like this will become moot in the not so distant future.

> But I can almost guarantee the larger group of non-technical users will have never thought about the styling of their scrollbars for more than a few seconds.

So you argument in favor of breaking the UIs of the non-technical users - who don't know that it is not their computer working wrong, but rather the site operator deliberately making things inaccessible - is users don't know that it is you breaking things? Sounds rather horrible.

But I can almost guarantee the larger group of non-technical users will have never thought about the styling of their scrollbars for more than a few seconds.

I think you're saying that this means it doesn't matter, but it actually increases the importance of respecting the users choices. Anyone who has changed their scrollbar has done so because it's important enough to them to bother. They've put effort in. That means there is far more likely to be a good reason not to override their preferred styling.

Just because most users don't think about it doesn't mean it doesn't impact them and that they should be ignored. The very fact that they can't fight for the solution that best benefits them means the onus is on us as designers and programmers to do that for them, instead of handwaving their needs away.

Or to phrase it a different way: Being able to style and control the width of the scrollbar is so incredibly useful that it must be in the hands of users, and not designers.

Would you extend that to buttons, text fields and all other components in general?

I'd say default should be whatever the web designer wanted, if you're not agree you can always use one of the overrider plugins.

Yes 100%, apps should follow the theme for components set by the user.

Well, that's a super minority opinion. Also, websites are not apps.

The same applies to most websites too

I would go even further: websites should not be the ultimate decider on any style-related decision. Including colors, font faces, text size, margins, padding, content width, and any other UI elements. Website should be able to suggest these things, but browsers should default to the user’s preference or the system’s configuration. The user should have the final say on how the User Agent displays HTML content.

Browsers have ceded far too much control over these things to websites, to the point where we are even debating whether they should style such fundamental OS controls as scroll bars!

1991 called, they want their Gopher back.

Overriding all css is so popular a concept that no Firefox plugin to do that has more than 100k downloads (and firefox users are probably the most likely to fidget with things like that).

A radical idea - people should be able to create whatever they want in whatever colours and fonts they want and have it shown to viewers the way they want, at least unless the viewer explicitly objects.

It's relatively easy to force your custom stylesheets to any website. Whether it will work at all is another question.

I believe what you suggest could work only with semantic HTML without any advanced styling - no floating elements, no flexbox/grid, no absolute/relative positioning etc. This then means return to static text based websites which is fine for many use cases, but not for all.

Ideally, rich web apps which actually need all the CSS/APIs could use them, while the text-based sites would keep custom styling/JS to minimum (which would allow reasonable user-defined styling). But it's impossible to force this dichotomy in practice.

Would you then also force developers to stick with the very limited set of native components, or are they allowed to make custom ones?

Lets say a date picker was not supported in html, I'd at least prefer they made one aggregating native buttons instead of from scratch with colored divs/whatever.

They can make custom ones when a native one doesn't exist.

There's literally no reason to write your own implementation of a drop-down menu. Zero. None.

And yet, I occasionally run into a site where I need to enter my mailing address, and they have a drop-down menu to choose my state. In a native component, I can just tab to it, type "or", and Oregon (or OR if they're using the abbreviation) will be chosen, and I can just tab on to the next input field.

But every now and then, I find myself on a form where that doesn't work. It turns out, what looks like a drop-down menu is actually a fancy div, and when you click on it, another div pops up with divs for each item. Oh, but I can't even use my keyboard to choose an option! I HAVE to click!

WHY DO WEB DEVS DO THIS!? What was gained by this? Someone spent time to reimplement something for absolutely zero gain, and a LOT of loss! WHY!?

And my complaints don't even begin to address how the custom solution is probably awful for accessibility.

You don't need to make a custom button.

You don't need a custom date picker.

I'm struggling to think what custom components you think need to be made.

My best guess is that these abominations are made in order to adhere to some pre-made design that specified all the visual aspects without regard for the existing technology. If somebody gives you an export of a design made in Photoshop and says that you need to match it pixel for pixel, that design might not be readily implementable. Depending on the approvals needed, or the cost of hiring external designers, asking them to revisit the design in order to match the tech stack might be politically infeasible.

So instead of design being the intersection of form and function, design becomes entirely detached from the function.

They can use CSS to change the design.

It does not require the developer to completely rebuild the component behavior from scratch using JavaScript.

Good thing CSS is client side!

Interesting setup, do you have a link to it?

Reply on news.ycombinator.com