The author seems to be have written this post based on work for an in-browser video editor (https://videoinu.com/editor). It runs completely on the client-side, so all the editing, previewing, rendering, and exporting is done using web technologies. Of course, it's not comparable to a professional editing tools but nevertheless that's very impressive achievement in my opinion!
It's true, a proper desktop editing application would probably be better in most cases, but I guess it would still be useful for the case where your computer can't run desktop applications (ex. chromebooks) or your administrator doesn't give you permission to install such applications.
> Because you'd have to download an app like this and then trust that it won't install malware or spyware or do anything else malicious.
How you would check that web app, which JavaScript/WebAssembly source/binary should be firstly loaded into your browser from 3rd-party website, would not "install malware or spyware or do anything else malicious"?
Modern browsers are pretty secure nowadays. By comparison, you have pretty much zero guarantees about an app you install onto your computer. The only concern is that these browser apps are quietly sending your files elsewhere, but this is easily inspectable via the dev tools.
Or you just run the installer in a sandbox/container, as has been possible for at least a decade in all major OSs
Sandboxee was released in 2004, and there have been various bits of registry journaing/snapshot software since the late 1990's which combined with NT ACLs could provide at least as much security as your getting out of a browser sandbox.
Browsers have an absolutely huge sandbox surface and lack even the most basic of fine-grained security controls out of the box. Enabling even basic restrictions to avoid fingerprinting has turned out to be difficult. How you do you know (particularly with firefox) that one tab isn't actively picking out data from another tab open to your banking site. Much less the problem with malicious javascript being injected via the ad frameworks.
> Or you just run the installer in a sandbox/container, as has been possible for at least a decade in all major OSs
The level of technical know-how necessary to accomplish that is astronomical compared to "here's a link," especially since it's cross-platform out of the box. That's why it's a no-brainer: any sane person is going to prefer that over installing untrusted software. Basically zero users know about the sandboxing solutions available for their system, much less willing put in the effort to Do It Right.
Has you ever read changelogs of Firefox & Chrome/Chromium? There are tons of issues documented related to sandboxing & security each new release happen.
Why would you use browser-based video editing over desktop-based free software, where you can read the source (or listen to someone you trust who has read the source) to make sure it's not doing anything malicious? Besides the fact that it might be easier/simpler for very small projects.
> (or listen to someone you trust who has read the source)
By this I meant to include, for example, the Debian team. Of course there can be bugs/oversights, but the same is true of the browser solution. Is there even one instance of malware being distributed through the official channels of a mainstream Linux distro? Not that an in browser JS video editor isn't cool, but I don't see how it would have technical advantages over the various Linux desktop editors.
So many of the projects I see mentioned here are neat hacks, but that's really about it.
People writing a complete operating system for an 8 bit micro made of discrete chips? That's neat, but not really useful, and most people won't ever take the time to boot it once.
An FPGA that runs web assembly code? That's nifty, but if we want high performance we probably won't use web assembly to do it.
You invented a completely new language that has all the features of C but none of the things that are annoying? We'll add it to the list of C-like-but-not-annoying languages.
Found a great new way to estimate how much capital you should try to get when creating a start-up to sell your all-natural soap products in California? That's great for you... a little bit niche for the rest of us.
You re-implemented emacs in python? That's a really impressive technical achievement. No one will ever surpass you in either emacs implementation or python hacks. Also, no one will ever use it.
Same thing with Hackaday... lots and lots of "cool" projects where neither the creator nor the site mods seem to realize something is just a nifty project, and not the salvation of the world.
You write as if these are bad things, but they're wonderful things. They're also the bread and butter of this site, so it's good that you see them here. Something would be wrong if you didn't.
Pure interest and sublime pointlessness are, of course, two of the classic hacker motivations.
I see such "not really useful" projects much as I do fine art. There's not much measurable use to the world in most painting, sculpture, or music in and of itself - but done well, it brings enjoyment to both the creator and appreciative observers. Count me as an appreciative observer in many such cases.
This would be accessible anywhere on any computer hooked up to the internet, even potentially a phone, tablet, raspberry pi, your grandma's computer, etc.
Many programs that don't need low level access like spreadsheets, pdf readers, word processors, image editors, etc.could be made into single page html files that would both be sandboxed and cross platform.
> To make matters even more exciting, the last two coordinates might not be what you'd expect; when absolutely positioning items in CSS, right and bottom indicate the distance from the right and bottom edges respectively. In image maps, this holds no water. Instead, both horizontal coordinates are counted from the left edge and vertical coordinates from the top edge.
Interesting. This order is commonly used by libraries like SDL and SFML to declare rectangular shapes.
They're x, y pairs for the top-left and bottom-right corners of the rectangle. They're coordinates in the fourth quadrant of the Cartesian plane (i.e., with the origin conceptually in the top-left corner), which is also the way coordinates are given in most windowing systems (including X). This is more obvious when using the "poly" attribute rather than "rect," where you can have an arbitrary number of x, y pairs (and the browser automatically closes the shape by drawing a line between the last coordinate and the first).
The way CSS orders border, margin, and padding values is clockwise starting from the top. But these aren't coordinates since they represent sides, not points, so I think the author is confusing things by comparing them.
something I always wondered since the age of programming mode 13h, is the use of the fourth quadrant so that loop would fill video memory in the order the scan line goes reading it?
This is pretty much it. Scan lines are numbered from the top down, as they happen, everything else is numbered accordingly.
The real question is why scan top down and not bottom up? (I don't have any idea). Horizontal scan lines makes sense given a wider than tall screen, because it results in fewer scan lines, lowering the frequencies required ( a bit). Wider than tall makes sense for TV given common movie film aspect ratios and computer monitors started as TVs with different control circuits and cases.
I think it’s just designed to match the English order for text. This way your text mode can go through memory linearly. Graphics mode can just reuse the same order.
Back when image maps were common on websites, it was also easy to find the coordinates in your image by placing your Paint Shop Pro crosshairs at the desired points in your image and then transposing those coordinates to the html. Using a relative number for the second point would have added a lot of work for complex image maps. Maybe that's just a coincidence because it was actually driven by the underlying array, but it was super helpful on the design side too.
PS - This brings back my memory of server side image maps which were fun for treasure hunt type images because you couldn't view the page source to figure out where the hotspots in the image were. Good times.
They both make sense for their respective use cases. An image has a fixed size. An HTML element does not necessarily. You can't measure the the right border from the left of an element if you don't know how big it is.
Interesting to perhaps no one else but those others that have suffered with it, the PDF specification allows drawing rectangles and other in-line graphical elements inside a 'sort of' canvas from a bottom right co-ordinate space only. I wondered for a while why that was.
Do you mean the bottom left corner? That's what ReportLab (python PDF authoring package) uses. It kinda makes sense wrt the cartesian coordinate system where x coordinate increases to the right and the y coordinate increases upwards, thus the origin is at the bottom left. But yeah, from a UX perspective it's one of those cases where practicality would have been better than purity.
That order has been used since the dawn of time. Well, since the dawn of graphics. I'm surprised at the author's surprise and I find it a little concerning.
It's funny this came up. I've been doing webstuff and getting paid for it since about 1996 or 1997; imagemaps were a pretty big deal back then. Recently, I found myself thinking, "How do they do that these days?" I have gotten out of the webbish stuff and even before that, I tended to stick to the tried and true.
I don't think the need for something very much like imagemaps will ever go away. The lure of arbitrary polygons and paths cut from an image needing to be clickable is high, and I think the ability to join up a bunch of polygonal (or worse) images and have them well-aligned is far off. It's easier to cut up than to re-align.
The answer is usually to use SVG. You see this in most maps and charts with clickable or interactive areas. For cases where you need a raster image to have clickable regions, like showing plots of land or property boundaries on a real estate website, you might see a mix of a raster image below a semitransparent SVG overlay or just a <canvas> element instead, which would have to manually reimplement handling clicks and hover events on the various regions.
I saw a site not too long ago that had a map of U.S. states with state changes on hover and click. It was just a bunch of SVG's in an <ul>. So it's possible, but it takes some braining.
I feel like I'm missing something. It seems like declare a <map> element, associate it with an <img>, but then use JS to iterate over the map and build a bunch of absolutely positioned <div> elements on top of the image. Why not just have the annotations stored outside the DOM (returned by API or whatever) and just build the absolutely positioned <div> elements? Wouldn't that avoid the fighting with funky coordinate systems, etc.?
I get why <map> is (was?) useful in general, but if you're going to do your own annotation rendering on top anyway, it just seems odd. Fun exercise though!
If image maps only allowed rectangular areas, they wouldn't be terribly useful — you're right that it would be almost as easy to lay some transparent divs over the image.
However... image maps also allow for circular and polygonal regions, which can be really handy.
I guess you could also do that with a transparent SVG overlay, but using a map is easier.
The annotation divs have to be rectangles, but the mouse/touch-sensitive areas of the underlying image don't! The author's goal is to only show an annotation if the user hovers over/touches its corresponding region in the image map.
I remember seeing image maps for the first time as well. I can't remember exactly what they were for (possibly the Yahoo logo when it had circular buttons around it), but I distinctly remember the feeling of being able to click on an area of an image and something different happening.
It floored me at the time because it was, in my mind, when Dorothy opened the door to Oz and a huge, beautiful world just appeared before her.
It's very strange to be in an age group that gets to remember being in a world before and after image maps (among ALL the other tech that erupted in the last 30 years).
The best part of it is that as soon as we saw it.... we could reproduce it. I viewed-source and started creating my own image maps on my personal websites immediately. Then showed these to friends and family and they were so impressed :)
.... I find myself trying to recreate this feeling all the time.
I couldn't agree more with your feelings, it was beautiful at the time. I remember I spent hours visiting websites with JS snippets, to do simple things, the web felt so much amateur and collaborative. Seeing it now through the times, I think the difference was that to create an amateur website, you don't need to understand a lot of techs, just HTML and how to use a FTP software. Now everything seems much more complex.
Anyway, I just wanted to tell my experience with Image Maps. A friend of mine had a much better CPU, where his father also worked creating websites, and he had Macromedia Dreamweaver. He could create image maps with the cursor, clicking here and there, and it was amazing. Meanwhile, in my house, my CPU only allowed me to run stuff like Notepad++, which meant I had to memorize my friend's code, running back home, start typing it and trying to understand how it worked to modify it at my piacere. The best feeling in the world was when the click did what I expected in the area I wanted. What a feeling.
You still can go the route of not knowing a ton of tech to get a site up and running while still having full agency over the HTML/etc. Just pick up a service like bluehost shared. Hell, at work we even have one for odd tasks and easily-accessible FTP needs and one-off sites or documentation pages.
I do remember getting to play with Dreamweaver back then, though. It felt so high tech compared to Notepad and FrontPage Express and all that. All the "cool" sites had image maps and as a kid it was tough to understand how they worked. I did something similar to you, but usually copy and pasted from a web site then changed the image out and kept tweaking by trial-and-error until I got the result I wanted.
This brings me back to the time of when I used Photoshop 5 to create the entire website design and layout, create slices, and export to HTML which was then by edited by Dreamweaver.
Image maps were great. I used them for a site's nav that needed some slight visual flair (item entries had to be diplayed at a slight angle with a custom font). To reduce the bandwidth, the entire nav's text was a single image with transparency. Then the backing would be either a red or green angled rectangle. The text had a mapping over it that would change the background rectangle depending on what area you hovered. It made for a great effect.
I used to love image maps: really useful for adding hotlinks and hover effects to images. Sadly they can't deal with the modern responsive web - though there exist some Wordpress plugins to help overcome that issue.
This CSS article[1] goes into details about alternative approaches. It mainly seems to be SVG, or CSS clip paths. I've used (and like) SVG; CSS clip paths are foreign territory to me - has anyone used them in production to replicate image map functionality?
One of the goals I made for myself when developing my canvas library[2] was to bring image-map-like functionality to the <canvas> element - but as responsive and accessible as I could make it. It's still a work-in-progress but I'm getting there!
You should be able to tab through the pins using the keyboard, and 'click' a pin by pressing the return button (mileage may vary between browsers and devices). The text labels and links themselves also exist inside <div> elements immediately following the <canvas> element (automatically added by the library when it picks up a canvas, and when creating canvas text and links) ... but I don't know how useful/convenient this is for users restricted to screen readers.
Wow, blast from the past. I remembered building a website using image maps 13 years ago. Just checked and it's still being used even though I stopped being the webmaster 12 years ago, works great! Never realized it was considered obsolete even then.
Pretty clever use of old tech. I think I probably would have tried embedding the raster image in an svg[1], then overlay shapes for hover or click events.
I have considered recently I should make some things with imagemaps again, like there is untapped potential there I'm not clear of but that when I start working with it years of experience and new technologies will clarify.
Make a web framework that renders the UI entirely as mapped images. A PNG would probably be faster to load and render than most of today's multi-megabyte JS monstrosities.
> we'll be revisiting this opinion once responsive websites with their (gasp) automatically resizing images are out of fashion.
Will this ever happen? We won't stop having radically differently sized devices any time soon. Of course I'm sure eventually the "responsive" approach will give way to other techniques but I can't really see the high-level approach disappearing.
Flexbox (for one-dimensional layout) and Grid (for 2-dimensional layout) really improved the situation and finally made floating and positioning obsolete.
My dad's employer didn't remove the Java applets from their website until I pointed out that navigation had been broken due to both Firefox and chrome having removed Java support. Until then, the menu showed pixelated hyperlink-blue text that changed color with a transition when hovered or clicked, and couldn't be used with the keyboard. Each link in the menu was a Java applet to take you to the next page.
No, that wasn't it. They didn't suck, and for a bunch of years IE was the best browser.
In the past there were no other options (no CSS positioning etc) so people used tables as a way to control content layout. They were actually pretty good for this, even though that's not what they were intended for.
Then CSS came along. Initially CSS was mostly exciting because it exposed a lot more fine-grained control over display properties like fonts, borders, margins etc than had been available in HTML attributes.
Gradually developers came to appreciate the value of what CSS was intended for - separation of content and presentation. Along with that realisation came the push for "semantic" markup, i.e. use appropriate HTML tags for the content, and stop using tables for layout (unless you are marking up actual tabular data).
For some years this was awkward though because CSS didn't provide good layout tools. So instead of true semantic markup you often ended up with "div soup" - lots of anonymous tags which exist just as containers for sake of achieving some hack with the CSS positioning system. And still a couple of things that had been simple to achieve with tables remained impossible.
But people persevered with the CSS hacks, for all the right reasons, until we get to the present day when I guess modern CSS has all the tools needed to produce any kind of layout, layouts that adapt to screen size, units that cope with Hi-DPI etc etc etc
But I think it's still appropriate to mark up tabular data in HTML with a table, and I would think they do a good job of that?
1. Less markup. It's way easier to have a unordered list and use flex or grid to get the layout in place. No giant soup of nested table tags.
2. How do you deal with responsiveness? A pretty typical pattern would be "have this set of elements horizontal on large viewports, then have it vertical on small viewports". Trivially easy with flexbox (just set flex-direction at a media query breakpoint) or grid (change the number of columns).
There are so many unpredictable edge cases to the magic of the table layout rendering algorithms that I would be hard pressed to recommend them for layout to anyone. I've seen the dark arts of what people do to make tables responsive and I want no part in it!
But honestly though there is a whole host of simple layouts that are a breeze with Flexbox or Grid that require precise contortions of the mind to produce with tables and the hacky css required to coerce them into order.
Rendering issued aside, it's a good idea to use tables for what their designed for: displaying data. Using elements how they're specc'ed to be used makes the web a lot friendlier to screen readers and friendly neighborhood spider bots.
I’ve built a layout back-end that rapidly prototypes the web-page with custom metal type, quickly hammers it into a wooden frame, and then runs it through a printing press and scans the result, which is then saved as a PDF, compressed, and sent to the user’s gopher client.
This reminds me of a benchmark of sorts, that gave a ratio of the size of a whole size to the size of its image rendered as JPEG. One could think of a map overlay to bring back some interactivity.
Does anyone remember it? It was once featured on HN, but I can't find it now.
I last used these in 2014 for a mobile web app that tracked muscle soreness. Worked like a charm, and I was also able to handle responsiveness with viewport aware JavaScript. I had to dig up an old copy of Fireworks to generate the polygons easily too.
Was just thinking of using an image map the other day! My dad has a camera collection and it would be cool to take a picture of it and then map prices of the picture to links about each camera. Haven’t gotten their yet though.
To me looks like it's fun to develop but impractical to use. Today you can go cleaner and scalable with css-grid, flex and other proper HTML elements. It was a nice article though
interesting mentions of the <blink> and <marquee> tags. I have a modern app that makes use of these properties for making gif's. blink will make any content in the gif flash on the canvas and marquee will move it side to side : https://imgur.com/rgHrsoa
Terrible for accessibility though. I'm sure screen readers have come a long way, but the core issue we dealt with 15-20 years ago was that the convenience of an imap wasn't worth breaking accessibility standards.
With more of our traditional desktop services having moved to mobile and now moving back to the browser, I'm more concerned about this creating another wave of accessibility limitations caused by a petty convenience for dev.
I don't want to sound off like an activist, but I'd like to see that someone with limited mobility or sight can equitably access services they, as much as we, will sooner or later have to depend on as current apps and software lose support and phase out. The Net has always been a place where a person's only limitation should be their choice to not commit their time to learning how to use it. Let's stand by that now more than ever, or I fear we'll hand an uncontested victory to the idiots in Silicon Valley who want us to adapt to how they want us to use the Net.
