5 ms·
As someone who used to be involved in the decision to not implement native context menus, and did a bunch of work on the non-native ones, I want to try to expla
by jaas 5y ago
As someone who used to be involved in the decision to not implement native context menus, and did a bunch of work on the non-native ones, I want to try to explain why this took a long time.
It has nothing to do with engineering resources, and we always wanted native context menus, but they were not customizable enough to meet the perceived needs of web, XUL, and extension developers at the time. People expected to be able to change colors and layout with CSS, for example. The native APIs put heavy limitations on what you could do with a native context menu and it was just not compatible with the expectations of people building against the rendering engine at the time.
There was some discussion of switching back and forth between native and non-native menus based on styling, but that got complicated quickly and it wasn't thought to be worthwhile.
It sounds like perceived needs have changed, and maybe the native APIs allow for bit more flexibility now. Glad it's happening, excited to see how well it works!
- barrkel 5y agoI suspect "perceived needs" have changed due to the scorched earth policy Mozilla took with the old Extensions API. All extensions have had to be pretty much rewritten from scratch.
- jaas 5y agoI'm sure that's a big part of it. The old-style extensions were so powerful because they could put their API tentacles very deep into the rendering engine. Mozilla paid a huge price for allowing that though - it was very difficult to change the behavior of many parts of the rendering engine without breaking extensions. Much of what you'd think was just internal implementation detail was actually API surface accessible to those extensions. The workarounds added a bunch of internal complexity. It really slowed down the pace of development. I get that some people mourn the loss of that style of extension, but dropping it was an important decision that should have happened much earlier. There were other issues with the old-style extensions (e.g. security) but making the pace of development uncompetitive should have been enough to doom it.
- kergonath 5y agoThanks for the explanation. As a user I very much prefer native widgets, as non-native ones always break expectations in subtle and infuriating ways, but it is interesting to see the reasoning behind this type of decision.
- seumars 5y agoThe fact the modern UI design has become as homogeneous as it is nowadays is a blessing that's hard to appreciate sometimes. I have to admit I still miss the early to mid 2000s era when customisation was more or less expected of every application.
- abruzzi 5y agoI don't ever want to go back to the "Kai's Power Tools" era of UI design. Computers don't excite me, they are a tool to get things done, and consistancy makes every application easier to learn. Granted, I know I'm probably in the minority, because custom UI widgets are commonplace in mobile app design.
- chrismonsanto 5y ago> Computers don't excite me Honestly kind of a depressing thing to read on "Hacker News", not that I disagree that UI consistency is good
- the_only_law 5y ago> Honestly kind of a depressing thing to read on "Hacker News" I agree it is, but I also must say as of recently I agree. There hasn’t been anything in a while that’s excited me. Probably in part because I went around to learn how all the parts of the sausage are made.
- e3bc54b2 5y agoI observed myself leaning in same direction. So I thought a little in why that is, and I realised the constant needless worthless churn on every part of "UI" from every corner of OS and application has made discovery impossible, especially discovery on my terms. A new update or UI is now terrifying rather than exciting. The only two times I remember being excited about computers in last couple of years is when I picked up NixOS and Lisp. Now that says more about me than computers, but that's my 2c.
- Cyberdog 5y ago
- eschaton 5y agoIt sounds like web designers need to adjust their expectations. When they’re designing web pages, they don’t get complete control over rendering or OS controls, and just need to deal with that. The idea that a web page should be able to override things about how a contextual menu is rendered is laughable.
- DonHopkins 5y agoThat's exactly the wall I ran up against with ActiveX pie menus. https://news.ycombinator.com/item?id=27276093 https://news.ycombinator.com/item?id=27276093 I wish browser extensions could pop up floating, undecorated, arbitrarily shaped, alpha-channeled popup windows, whose appearance you can define with any web technology you wanted, which could capture the mouse and keyboard to globally track input events, that would go a long way towards implementing pie menus and all kinds of other user interface widgets. Perhaps you don't want any web page doing that without permission, but at least trusted browser extensions should be able to.
- CyanDeparture 5y agoThank you so much for this explanation, I always assumed it a low level to-do. Makes so much sense now, FF has loads of custom add-on menus with all sorts of UIs you don't see anywhere else in MacOS.