| Issue 39: | Semantic HTML | |
| 3 people starred this issue and may be notified of changes. | Back to list |
Right now the prettify library doesn't really promote semantic HTML. The class "prettyprint" doesn't convey what the content of the tag is; especially not without the prettify library. Asking the user to manually call the prettyPrint() function using the onload attribute in the <body> tag isn't very semantic either. Preferrably the only thing the user should need to do would be to include the prettify.js file. I've modified the prettify.js file to include the aforementioned suggestions (it has been attached to this issue.) <pre class="code"> tags and <code> (note that no class is required) tags will be highlighted as soon as the DOM has finished loading (sooner than the onload event) if the prettify.js file has been loaded. |
|
,
Jan 06, 2009
I think semantic markup advocates have many good ideas, but it is not a goal of this project to promote semanticness or any other markup layout methodology. While I think avoiding the need for an explicit onload call is good, this project has too many clients to change the API that radically now. Could a wrapper script help make it easier for those who want to use semantic HTML to use this code? |
|
,
Jan 06, 2009
I understand why you don't want to change the function of the script in order to keep backwards compatibility. I would propose making the code more configurable, so that the user of the script can decide how they want it to behave. A few configurable variables could be added to the top of the script, one for configuring what tags/classes should be prettified, and one that decides how the prettify engine should be initialized. The current method of calling prettyPrint() on load is noticably "slower" (onload code might be triggered several seconds later in the browser than using the method in my aforementioned code to detect DOM load.) But since it's, as you say, used in many older clients, it could be kept the default behavior. |
|
|
|