Html encryption is, of course, the technique by which information that has been encoded in HTML (a derivative of SGML, for those who are technically inclined, and therefore one of the wide family of markup languages that include XML and its many sub derivatives).
There is nothing special about encrypting html since it is merely a piece of digital information that can be encrypted without any concern for what the underlying content is or means. This is in contrast to XML encryption, where an amazingly complex and complicated structure has had to be created in order to relate information items to each other. This happens because in XML, as opposed to html, it is possible to have embedded references to other data items, and if you encrypt those, and later decrypt them, to the unsuspecting viewer, the links resolve and information that was never protected at all can be shown as if it were guaranteed all the time.
So encrypting html can be a very powerful way of assuring a recipient that the information that they are seeing is genuine, has not been altered, and can be relied upon. But only provided that html encryption is not used to appear to protect information that is actually not on the html page at the time of applying the html encryption, but is resolved later. Because that would be a grave misuse of the technique.
Generally speaking, people receiving html pages are not sophisticated in the internal issues of exactly and precisely how information is processed by computer systems. Indeed, and not to put too fine a point on it, there is no shortage of IT professionals who do not know either. In fact, unless you can inspect the actual html code itself you cannot be utterly certain as to what may have been encrypted, and what was not, and should not be relied upon.
So html encryption is a valuable method and technique, but it has some problems if it carries references to information that was not encrypted at the same time as the underlying html. If the other information was also encrypted then the user can place reliance upon it, and otherwise not.
As with many web services, there are two distinct aspects to protecting an html page. To the programmer, the most obvious aspect is the underlying code (including scripts, references to URLs and email addresses) to stop other people copying the underlying content rather than what is displayed by the web pages. However, the second aspect, the visual representation of the information itself (text, pictures, animations, etc.) are themselves copyright works and the managers of a business may see those as equally, if not more important than how the image was created. For example, the appearance of a magazine is probably more important than the underlying coding that presents it.
Thus html encryption can be used to protect the underlying encoding but cannot be used to enforce digital rights management (DRM). Various products are available that just ‘protect’ the underlying code but because of the way these products work (delivering the decryption key along with the encrypted page by a simple script) they are vulnerable to straightforward attacks that appear well documented.