<pre>
<code>
for (int i = 0; i < top; ++i) {
   vector<int> <span style="color:red">judy</span> = mary();
</code>
</pre>

for (int i = 0; i < top; ++i) {
   vector<int> judy = mary();

<pre>
<code lang="xhtml">
   <p> <!-- paragraph -->
	  <b>What's going on?</b>
   </p>
</code>
</pre>

   <p> <!-- paragraph -->
	  <b>What's going on?</b>
   </p>

<pre>
<code>
   <p> <!-- paragraph -->
	  <b>What's going on?</b>
   </p>
</code>
</pre>

   <p> 
	  What's going on?
   </p>

<pre>
<code>
for (int i=0; i<5; ++i) {
   <span style="color:red">cout</span> << "smap!" << endl;
}
</code>
</pre>

for (int i=0; i<5; ++i) {
   cout << "smap!" << endl;
}

<pre>
<code markup="span">
<a href="<span style="color:green">target-url</span>">Link text</a>
</code>
</pre>

<a href="target-url">Link text</a>

720 comments

You can leave a comment, or trackback from your own site.

1. Bennett

   19 September 2007 at 8:34 pm

   A, this is a built-in WordPress feature — an ‘x’ between two digits is assumed to be a multiplication sign and is transformed into one.

   Code Markup does allow for this. In my testing with Code Markup enabled, if I include
   <code>0x7f</code>
   in a post then it is rendered as 0x7f rather than 0×7f.

   If this is not working for you (remembering that Code Markup only works on text inside a code element) then you could email me the relevant content of your post for me to look at. (Use the Contact link at the top of this page).
2. A

   25 September 2007 at 9:48 am

   Bennett, thanks for the info. It seems that the rendering issue with 0x is inside a CSS structure that I defined myself – it is not inside a ‘code’ element. Maybe it is worth considering something similar for your package.

   I wanted to achieve two things: (a) be able to use ‘pre’ for things other than code (it really is not appropriate to completely usurp pre for code), and (b) define some other features such as a different background, different margins, that apply only in a block context – these should not apply in an inline context.

   So, I defined a CSS entry:

   .codeblock {
   display: block;
   white-space: pre;
   font-family: monospace;
   margin: 1.5ex .5em .5ex .75em;
   width: 90%;
   line-height: 2.25ex;
   background: #eee;
   color: #000;
   padding: 2ex;
   }

   Code blocks are then delineated in the source by “div class=’codeblock'” elements (I hope this shows up right when rendered in the blog).

   This doesn’t use Code Markup at all, and works better than one might expect, but it does have problems: it is not valid XHTML when code contains the left shift operator (two less than signs); for some reason, occasionally the display engine will stop issuing line breaks and collect a bunch of code onto one line; and 0x doesn’t show up correctly. Probably there are other problems.

   So, I was wondering: can you make Code Markup include a codeblock style that can be used in as a class for ‘div’ elements, and subsequently modified by custom stylesheets? That way, all the benefit of your work could be had in customizable code blocks, and it’d be cleaner to use your package for code blocks: it wouldn’t usurp pre for code only, could be invoked using only ‘div’ instead of having to use both ‘pre’ and ‘code, and the codeblock style could be modified with a custom CSS entry. What do you think? If this isn’t possible, do you have any suggestions?
3. Bennett

   26 September 2007 at 6:54 pm

   A, Code Markup works on code elements only. I believe in the value of semantic markup — all code listings on an HTML page should be inside code tags. You don’t have to put your code inside pre tags for Code Markup to work, and you’re free to use pre for other things than code.

   So instead of defining a style for div.codeblock, it would make more sense to define a style for pre.codeblock and use <pre class="codeblock">. After all, pre already specifies the display, white-space and font-family styles you want anyway. So put your code blocks inside <pre class="codeblock">, and inside that you should enclose the code in code tags. Inline code should just be inside code tags.

   So to sum up: Code Markup is based on the idea that all code should be in code tags; and it makes sense to use pre (styled appropriately) rather than div for displaying preformatted text.

   You have raised an interesting point — I hope this reply is helpful.
4. A

   27 September 2007 at 6:06 am

   Thanks for the info.

   Is there some technical restriction in WordPress that makes it impossible or difficult for Code Markup to process code that’s inside, say, a entity? The reason I ask is that otherwise there seems to be no reason why

   
some code
some more code


   is preferable to (or even as good as)

   some code
   some more code

   The semantic value of using as compared to "class=codeblock" seems about the same. In both cases the rendering information is specified in a style sheet. The redundancy of having to specify both 'pre' and 'code' in every code block is annoying, and seems to suggest that something could be improved about Code Markup's setup for code blocks. It's entirely possible I'm missing something.
5. A

   27 September 2007 at 6:08 am

   Well, I hope that’s clear – there’s no way to preview posts and some of the stuff I intended to show up as text in the post gets interpreted as rendering commands. The first example uses ‘pre’ ‘code’ … ‘/code’ ‘/pre’; the last paragraph should read roughly, “The semantic value of using ‘div class=”codeblock”‘ as compared to using ‘code’.”
6. kometbomb

   28 September 2007 at 5:19 am

   Your script still seems to eat backslashes if the code is inside a “...” block. If the pre-tag is omitted, it works well, although this makes WordPress end the code block after the first empty line.

   Makes one wonder why they just don’t rewrite the whole mess that is WordPress text parser. Or, add a simple checkbox to disable it. :/
7. kometbomb

   28 September 2007 at 3:57 pm

   OK, I just noticed the comment is a fan of good eating. 😉 It originally read “inside a [pre][code]…[/code][/pre] block” (‘[‘ equals ‘
8. John

   18 October 2007 at 11:35 am

   “A, Code Markup works on code elements only. I believe in the value of semantic markup — all code listings on an HTML page should be inside code tags.”

   The reason we have been using the pre tag is that word press will end the paragraph at the next blank line. So if you want to include blank space in your code, a pre is necessary at this point.
9. Bennett

   18 October 2007 at 6:43 pm

   A, since Code Markup is intended to be used in (X)HTML pages, that’s the semantics it uses. in HTML, <div class=”codeblock”> has no semantics, whereas <pre><code> means “preformatted code block”. The fact that you have created a “codeblock” CSS class is useful to you when you’re styling your page, but useless for, say, a search engine that indexes code. Semantics aren’t so useful unless they can be interpreted by machine. Now you might think that this is all a bit academic and theoretical; and you may be right.

   You may find it annoying to have to type “pre” and “code” for multiline code blocks; but that’s HTML for you.

   As a side note, I really do need to add a comment preview feature, don’t I?
10. Bennett

    18 October 2007 at 6:55 pm

    kometbomb, Code Markup doesn’t eat backslashes; the problem is with WordPress. Create a new post using <pre> and backslashes are preserved. (I have tested this on several recent WP versions). But if you have your profile set to use the visual editor, then when you edit a post, it eats backslashes inside <pre> elements. If you then save the post, the backslashes are gone. And this happens with or without Code Markup.

    You can disable WP’s text formatting with the Unfancy Quote plugin (see the Alternatives section above).
11. Bennett

    18 October 2007 at 7:00 pm

    John:

    The reason we have been using the pre tag is that word press will end the paragraph at the next blank line. So if you want to include blank space in your code, a pre is necessary at this point.

    Yes, in this case you will need to wrap your <code> in a <pre> as I do in my examples.