These are some readers' responses. Read the full article to see what all the fuss is about.
-
Popular
Categories
- .Net & C# (1)
- Architecture (3)
- C++ (5)
- Coding (4)
- Copyright, etc. (3)
- HTML/CSS (2)
- Java (14)
- JavaScript (6)
- JUnit (3)
- Recommendations (9)
- Risks (8)
- Software projects (2)
- SQL (4)
- Testing (6)
- Tools (5)
- Usability (1)
- Web (5)
- Web publishing (16)
- Windows (1)
- WordPress (27)
360 responses
Other comment pages: « 1 … 7 8 9 10 11 [12] 13 14 15 16 17 … 18 »
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
0x7frather than0×7f.If this is not working for you (remembering that Code Markup only works on text inside a
codeelement) 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).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?
A, Code Markup works on
codeelements only. I believe in the value of semantic markup — all code listings on an HTML page should be insidecodetags. You don’t have to put your code insidepretags for Code Markup to work, and you’re free to useprefor other things than code.So instead of defining a style for
div.codeblock, it would make more sense to define a style forpre.codeblockand use<pre class="codeblock">. After all,prealready specifies thedisplay,white-spaceandfont-familystyles you want anyway. So put your code blocks inside<pre class="codeblock">, and inside that you should enclose the code incodetags. Inline code should just be insidecodetags.So to sum up: Code Markup is based on the idea that all code should be in
codetags; and it makes sense to usepre(styled appropriately) rather thandivfor displaying preformatted text.You have raised an interesting point — I hope this reply is helpful.
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.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’.”
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. :/
OK, I just noticed the comment is a fan of good eating.
It originally read “inside a [pre][code]…[/code][/pre] block” (’[’ equals ‘
“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.
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?
You can disable WP’s text formatting with the Unfancy Quote plugin (see the Alternatives section above).
John:
Yes, in this case you will need to wrap your <code> in a <pre> as I do in my examples.
Other comment pages: « 1 … 7 8 9 10 11 [12] 13 14 15 16 17 … 18 »