I think that the most common way of doing this is with a shared group, and making sure that files are group readable/writable/executable, and obviously owned by the shared group.
You could also create a functional user without login rights that you can both sudo to, but then you lose some traceability. Actually, I suspect there is a user www on your machine which could own these files, and you could both be permitted to sudo -u www -s
to get a shell session as user www. This is probably the user who owns the web server process, and you might want to use another account instead, either if you don't trust yourself or the other user to have the access rights of the web server, or if you want the web server to only have read rights on the web content.
I've used Unix and Linux for 30 years, and I don't think I ever worked in an organization where people actually used ACL. That doesn't mean that it's a bad thing, but it makes me suspect that it will be a solution which might confuse both users and some tools. You might think that it's about time that more people learn about ACL, and that might be right...
The classic owner-group-other system has flaws. For instance if there are some people you want to share write access on files with, and other that you want to share read access with, and then a third group with access to the file system that shouldn't even be able to read the files, you run out of categories in the normal user-group-other hierarchy... That's not the use case you describe though.