My favorites | Sign in
Google
                
New issue | Search
for
| Advanced search | Search tips
Issue 39: Semantic HTML
3 people starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  ----
Type-Defect
Priority-Medium


Sign in to add a comment
 
Reported by andreasblixt, May 30, 2008
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.
prettify.js
39.1 KB   Download
Comment 1 by mikesamuel, 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?
Comment 2 by andreasblixt, 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.

Sign in to add a comment