An attiny85 being used normally (ie with ISP programming) is impossible to brick by uploading crap to it. There's no bootloader to speak of. The only ways you can brick it are to write fuses to use a clock source that isn't present, and just applying an 8mhz square wave will let you fix it (or really anything in the operating range of the chip and fast enough that the programmer could talk to it), or setting the high fuses to disable SPI programming or disable reset (both of which require HVSP to unbrick).
However, if you mean you're using a digispark (ATTiny85 with VUSB bootloader), that you can brick by uploading bad code to it (though you can't upload html to it - avrdude tests the checksums in the .hex file before uploading, and will refuse to try to upload it if it's not a valid file). So that is quite plausible. Unfortunately, recovering these is hard, because they often set the reset disable fuse, so you can't go in to fix it with an ISP programmer, you have to use an HVSP programmer to reenable reset in order to reburn the bootloader. (If reset disable isn't set, just connect to ISP programmer and reburn the bootloader - no prob) You might be able to talk to it by powercycling it while trying to upload a new sketch - you want it to be turning on right as it switches from compiling to uploading (this works on the theory that until execution gets to your sketch, the bootloader should still work, so if you act quickly, you can upload a known good sketch).
The (sketchname)_bootloader.hex files should only be used when programming a sketch via ISP (not via the bootloader over serial or usb or whathaveyou) and you need to still have the bootloader - this only works on things with BOOTRST fuse (ie, basically any atmega, but not attiny's) On anything that doesn't have a BOOTRST fuse, the (sketchname)_bootloader.hex files should not be used at all because those bootloaders typically patch the code as it's being uploaded so that the bootloader will run on startup).