Improving the style of different nested languages

The current release of Prism.js defines styles for all the possible tokens, regardless of the language being highlighted.

In my opinion this is a UX issue, as nested languages use token styles which are not always the best choice for an effective code readability.

Example

Think to a HTML document, with embedded JavaScript and CSS, together with some server-side language, such as ASP.net or PHP (you have it here: http://jsfiddle.net/landzup/vJbkM/).

In this case, the JavaScript "token number" has the same style of HTML "token tag".
Or PHP "token attr-name" has the same style of HTML "token attr-name".

In some cases we could workaround it, by defining language-specific rules:

.language-javascript .token.number { color: #f04; }

but it is not always possible, as some languages are not wrapped into a language-specific class.
In fact, in the multi-language example mentioned above we may notice that:

• all the languages get highlighted only if the outermost element has the "language-php" class;
• associating the "language-html" class to the outermost element, will cause the PHP code to be not highlighted.

The first scenario is an incomplete solution because, even though highlighting will work, there is no "language-html" class Prism.js applies to the HTML code. It means that is impossible defining HTML specific classes.

Possible solutions

I suggest two possible solutions:

1. upgrading the library to let it markup HTML code when it is nested into other languages, allowing developers to write language-specific styles;
2. sharing the list of all the tokens of each language supported by Prism.js, opening the possibility to refine the CSS and style unmarked languages with some CSS workaround.

The first does not exclude the second, which would also help to optimize custom CSS by deleting classes for tokens which do not exist in a given language.

No files or tests are named. Start by examining how Prism.js generates markup for nested HTML, JavaScript, CSS, and server-side languages, then review the resulting token styles. Done means a decided, documented approach that enables language-specific styling for nested code without breaking highlighting.