A Firefox-only minimap (2021)
stefanjudis.com
stefanjudis.com
On one hand, I definitely appreciate that, I'm glad to see a feature abandoned if it's being abandoned because it's impossible to do it safely. On the other hand... I wanted CSS custom filters so much and I still regularly think of things I could have done with them :)
[0]: https://lists.webkit.org/pipermail/webkit-dev/2014-January/0...
I can appreciate a clever use of CSS the same way I can with JS but for my day to day browsing I don't want either being able to do whatever it wants because far too often what websites use it for is user-hostile.
I get why they're likely a bad idea, I'm not saying they should be implemented. It's very likely the right decision to get rid of them. I just mean... I want them XD
1. Stuff is too small to really make out where I'm going or navigating.
2. Short or long pages, both don't really benefit from the loss of screen real-estate. Or the distraction really.
3. Other tools like a proper index with descriptive headers, or the search function work so much better to navigate the page.
Where mini-maps could be awesome are large images, or maps. They tend to visual in nature, and when zoomed in you can look at the mini-map to see where you are in the whole. Which is useful.
So, cool future, but this doesn't really seem like a great implementation.
I use the minimap a lot, as a much better scrollbar. I tend to work on long files and even if I am rarely looking directly at the minimap, it is in my field of view and I often subconsciously glance at it.
This kind of feature is clearly no one-size0-fits-all, but it would be a mistake to consider it is useless because you don't like it.
But I think of code very visually and spatially and I don't split files until I have to, so it does help me quickly navigate to be able to sort of see the "shape" of a file and to be able to quickly jump around in it, especially if the file is divided into clear sections. Mostly just personal preference, and I agree they should never be mandatory.
And agreed on the large images/maps, most image editors have a viewport feature like that and it's pretty useful when doing detail work.
It's for looking at the shape of the code, not the contents. Also VSCode for example will show errors visibly highlighted in red in the minimap as well, which makes them easier to navigate to.
- (Linter) Warnings (in most themes a yellow or orange), like compile errors
- Marks for recently edited sections of code (in most themes a blue). Those marks are also shown in the left hand gutter beside lines but I think they are sometimes too subtle there, but their mini-map counterparts are less subtle.
- Current global search results (a bright gray or sometimes yellow, depending on theme)
- Current file search results (a slightly different gray)
- Current "active token" search results (another gray), such as when you put the cursor mid-word and VS Code naturally highlights all the other uses of that word
- Indicators for all of the lines containing your cursors when using multi-cursor (Alt+click to add additional cursors), which can be very useful to watch in large files with a bunch of shared refactors spread out over some distance
That's just off the top of my head because I use all of those to navigate some source documents.
I think one of the "shape of the code" things not everyone appreciates as well is that some languages create more interesting shapes than others. There are some languages where every file creates a very similar looking waterfall and there are others where the landmarks are much more obvious. Ironically it is sometimes the worst languages that have the most visually distinguishable shapes and where I find I appreciate the minimap most of all. You can visually see sections that began as copied and pasted duplicates, you can see the places where lines are highly repetitive and often those correspond to key patterns of very explicit landmarks ("there's the save code, you can tell because all the field string names are on the left side of assignments; there's the load code, you can tell because all the field string names are on the right side of assignments"). You can't make out the individual words, but you can certainly see those "blocks" like that from that "ten thousand foot view".
There's probably a visual processing/pattern matching thing about minimaps in general that some people have an easier time with than others. I've always liked a good map, regardless of context, so minimaps have always seemed useful to me. Map reading is a large combination of subtle skills, and I have just enough childhood training and natural aptitude that I have a great baseline for just about any map. I appreciate not everyone has those same skills, especially not in the weird arrangement that I do.
Bring back actual scrollbars! Or at least make it possible to turn them on.
At least while coding this is actually pretty old school to have no scrollbar at all. My emacs has no gui elements. I dont need them. I see a 89% to know where I am right now but this information is actually not really useful.
I move expression/function/method/bookmark wise for and backward or I just search and leave marks where I to jump back later. I really avoid touching my mouse and my window manager (xmonad) and development environment are entirely keyboard driven. I tried minmaps, its just distracting eye candy maybe a bit usefull while reviewing a codebase or looking for something.
But if the content is, say, HTML, or LaTeX, or a Word document, then I can see a visual representation being more useful. It would be interesting to know if there's some correlation between people liking/disliking minimaps and the type of content they tend to view/edit.
Now, I use it all the time, that's essentially a better scroll bar. In fact, the moment I saw the mini-map on the linked websites, I instantly tried to use it as a scrollbar, and was very disappointed to see that it didn't work.
After the spaces vs tabs war calmed down let's see what will be the aftermath of the minimap invasion
I would find this very useful on a site like Wikipedia where I often know the section I want to jump to before landing on the page. (e.g. I want to see the number of goals Messi has scored each season at Barcelona and I know there's always a table at the bottom of most wiki articles regarding historical stats for soccer-players). I could see from the mini-map where the tables are jump straight to it.
Like you said, the the text is too small to make out where you're going or navigating. But most often I find myself visiting sites that I've visited in the past and for those I have a good mental image of what the page already looks like. I can use the hints from a minimap to jump to the relevant section of the page.
I'm trying to figure out the use-cases and implications of this. You can do offscreen/overflow:hidden tricks to make it work with hidden elements. But... as far as I know there's still no way without a library to convert that element to an image (for privacy reasons I suspect).
I'm sorry for kind of being all over the place, but the MDN page is pretty short and I have a lot more questions. I guess I could always apply CSS filters and distortion directly to elements, does this being treated like a background open up possibilities there? It's the first time I'm hearing about this even though it's been around for a while, and I wouldn't have suspected this would be a CSS feature even on the table. How useful is this beyond just cloning viewports (assuming I'm only targeting Firefox and don't care about Chrome)?
For other cases, I'm not sure if I should think of that as a feature or a limitation. Definitely something to play around with though.
For whatever reason car manufacturers are the worst at it. Microsoft is also pretty bad (worse than Google).
* myADP had some kind of bug preventing firefox authentication that lasted months.
* Elan financial redid their credit card site for fidelity visa and had a CSS bug that hid the card total balance. This lasted for about a month.
* bitbucket (work required) had this bug that prevented pages rendering in firefox. It was some kind of JS client side bug and it impacted a bunch of people in my company. After months of support request they gave us some console commands that opted into an experimental feature which resolved the issue. This one was especially frustrating as they kept telling us to just clear our cookies and delete our profiles.
* Some random IRS system I had to use for either requesting a tax transcript or validating my identity just didn’t work.
It’s actually been so frustrating my coworkers joke anytime there is a bug I’m experiencing that it must be another Firefox only bug.
I'm not saying that to dismiss the problem, I believe GP that it's crashing; more bringing it up to say "there is something going wrong here that's not at the browser/site level that could potentially be fixable for you on your local device if you want to use Fastmail in Firefox."
For years they had a terrible implementation that only worked in _old_ versions of IE. They had no incentive to change because they were the main players in that space. I loathed them because their tagline was "Anytime, anywhere" which was clearly missing an asterisk.
Between blocking tracking, with DuckDuckGos privacy plugin, and using Firefox I'd say that blocking tracking breaks WAAAAY more sites.
It fascinates me how many people I know have uBlock (Origin) installed in Chrome and see nowhere near as many whiny banners and "stop running an ad blocker" nonsense as I see running Firefox without an ad blocker just ETP and MAC. The people complaining "Firefox is an ad blocker" are making it clear that they don't actually care that you are blocking ads or not, they care that you are blocking trackers and hate you for trying to maintain a semblance of privacy. Keeps saying the quiet parts out loud.
Most of the sites that do that are a "close tab and ignore" thing, some are a sequester to their own account container and feed them garbage (create a dumb account for them, turn off ETP just for them just in that container). It is still only a once-a-month case where such a site I need to get something done on is entirely broken in Firefox and I need to open it in something Chromium based, but that's still too often and getting worse.
But that "Firefox is an ad blocker, please use a less private browser" is a daily annoyance for me for sure.
I couldn't apply to become a registered engineer in my state using Firefox because the form was in an iframe, and for some reason the iframe didn't render on FF.
The credit portal for Shell Fuels only works in Chrome and doesn't display at all in FF due to a console error. (Enough of the page renders to make you think that the page is complete but i.e. the buttons to apply or make a payment don't render).
The field for setting the date of a consultation (work) in our accounting package doesn't work in FF, and no matter how many times I write to their support team they just write back with "Firefox is not supported, please download Chrome". There was a similar attitude at a software company I worked prior, but I managed to wear them down and get Edge (modern), Firefox and Safari on the QA supported browser list with the reasoning that they are the default browsers for Windows, Linux and macOS respectively.
But come on, browser standardization is so good these days I honestly don't understand how people are making pages that only work in Chrome?
I use FF by default.
Does anyone connected to the Chrome or Webkit teams have any idea why? Is there a lack of interest, is it hard to implement with good performance, does it create any tricky security issues?
Specifically, it does reflections of elements. That's really the big use case for -moz-element IMO.
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-box...
I'm glad there's still whimsy on the web
It feels kind of disappointing that I can't interact with it to scroll around like in i.e. Sublime Text, but I imagine that's a little harder to do as the author of a website. It's still very cool to me that you can do something like this on the web, and I wonder how much work it would be to support this complex CSS feature in Chrome or Safari.
Couldn't be bothered to scrolling/dragging logic. :D
Haven't really noticed any issues on Firefox except the lack of actually good web translator.
-moz-element looks sweet, hope it comes to other browsers.
But it's such a dog. Even after turning off mail and feeds which just sit there eating CPU like candy, I just can't make it fast, and returning to and cleaning up my Firefox made it so snappy, I'd rather stick to my 3 profiles (normal,dev, media) and do the rest via Bookmarks. And for all the sweet UI options and configurability Vivaldi has, with Tree Style Tabs and some addons for it, and hacking the UI CSS, I am sheepishly making Firefox my primary again, pretending none of that happened.
I wish it cached compiled WebGL shaders though. That is the only thing where Chrome beats it to a pulp sadly. Maybe there are config tweaks, I haven't looked into it, but out of the box reloading a page with a lot of shaders is basically instant in Chrome, even on mobile, and can take ages on FF, depending on the shaders.
otoh firefox has been really weird since the 115 update - rock solid before that, but now all kinds of weird graphic glitches and hangs.
Anyway this is definitely cool, but it's a shame you can't use it as a scrollbar.
[1] https://images.ctfassets.net/f20lfrunubsq/2FuQMHycwersLjIf4d...
The argument of -moz-element() can be a child of the styled element, but it can't be a parent (makes sense).
<div id="a"></div>
<div id="b"></div>
#a,
#b {
height: 200px;
width: 200px;
border: dashed;
}
#a {
background: -moz-element(#b) no-repeat;
background-size: 80%;
border-color: green;
}
#b {
background: -moz-element(#a) no-repeat;
background-size: 80%;
border-color: purple;
}IIRC, it's pretty finicky to get it lined up exactly. Maybe less-so with coordinates rather than elements.
[0] https://larsjung.de/pagemap/ [1] https://larsjung.de/pagemap/latest/demo/text.html [2] https://uiw.tf/minimap
Of course, browsers will never be fully at parity with each-other until they're all based on Chrome, so it's no surprise there are the occasional features that are just easier to implement in one browser than the other... though this one just seems kind of wild, I'll be honest.
https://help.vivaldi.com/android/android-appearance/page-act...
Pretty cool thing here, just wish I could use it to navigate. That's the biggest reason why I keep a minimap on in VS Code.
Example here: http://html2canvas.hertzen.com/
Along similar lines, HyperCard had a lockScreen flag that would stop sending draw commands to the screen, and instead buffer them internally, so that the screen would update once drawing was finished. It's such a powerful abstraction that much of the hand-waving we do today to avoid redraw would just go away, including nearly all of the effort that goes into building single-page applications (SPAs), because their functionality can be simulated by simply locking the screen and fetching new HTML from the server as a dumb terminal so the loading bar doesn't animate:
https://www.hypercard.center/HyperTalkReference/lockScreen
<rant>
To a first-order approximation, all apps/libraries/frameworks are missing critical functionality like this. The most common design mistake is to provide a setter without a getter, or vice versa. Another one is for a console app to provide a config file setting, with no way to override that as a shell argument to the executable. There are dozens, if not hundreds of these common anti-patterns, so statistically the odds of any piece of software having any of one of them can be considered to be 100%.
So in this case, most "modern" browsers provide a way to render the screen image from an HTML description, but no way to retrieve that image. The canvas element is a band-aid over these original design mistakes. A proper DOM implementation would look like iframes (windows) all the way down, where the contents could be specified from url, attributes, html, vectors/buffers or code. Each would have its own sandbox attributes defaulting to full isolation, so could be treated as its own browser, then their data dependencies could be piped together, a bit like unix executables. Mashups/portals/aggregators would be so easy to build that kids would be doing it.
It's a serious enough problem that honestly I don't really think in terms of HTML/CSS/Javascript anymore. I work in tables mentally, then let the designers transpile that description to CSS. And the real work of building the rich interactions available in desktop programming simply can't be done without massive yak shaving. This was also a problem in OpenGL before better access to render buffers and shaders went mainstream.
IMHO this all started when Netscape became a private enterprise from its Mosaic roots, then was exacerbated when Microsoft monopolized the browser market for so many years, then cemented when Firefox and Chrome endorsed the status quo. The only way out now would probably be to formally build a programmer's browser from scratch with hard security constraints around the core element's external communication, then emulate the current HTML/CSS/Javascript experience we're used to. Sort of like Qt, Postscript, etc. Which of course will never happen, so it's hard to see the positive in discussing these foundational decisions when there's nothing any of us can do to fix them in any reasonable amount of time/money/effort.