Typically changing the behavior of an extension is ill-advised (as the purpose for doing it, is unnecessary). From a disaster recovery scenario you are adding a step that really isn’t needed (the need to change the behavior of an extension so it performs differently).
On an Apache environment, sure you can use an .htaccess file to do it, so it is deployable with your code (not certain you can do that with IIS).
I guess my point is, changing the default behavior of an extension is an unnecessary step since there are extensions that already support what you want to do.
Now don’t take my statement to mean you shouldn’t perform
<?php
// accessed by calling index.php
include('mytemplate.html');
?>
and your mytemplate.html may very well include php tags.
My statement is directly against using index.html as your serving page and index.html contains php tags and must go through the php parser first (not a default behavior).
No my concern is the not obvious execution of an already defined extension (html). HTML by design does not get parsed server side. It would be like changing an .asp extension to execute against PHP. You can do it, but should you? Or a .cgi to execute against php.
Don’t get me wrong, it is entirely of my own opinion and everyone can do as they wish. Also, one other small tid-bit, if you were to allow .html to run the php parser, you are in a sense slowing down html pages that have no php in them, as they are still being forced to run through the php parser first (small hit on performance, but it is a hit nonetheless).
I’d suggest there’s also a usability/management issue. If another developer looks at the site, they’ll see a .html file and assume it’s flat HTML. This can cause a headache when it comes to tracking down code, debugging and will cause an issue if moved to another server.
