Article colourizer bug.
-
Silver members and above can edit that article. I've gone and added the magic few words.
knockNrod wrote:
When articles apply all the color-coding -- far from adding clarity -- they actually take away from the article by over-focusing the reader's attention on the colors, pulling the reader out of the context of that article.
I've gone back and forwards on this a few times. I'm leaning towards removing it again.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
The inline coloring seems useless much of the time. One of the editors did that to one of my articles and I felt it reduced the quality of the article. I could have changed it, but of course that becomes more difficult once an editor gets his/her grubby hands all over it. It can be useful to color code (or, say, italisize) code when it is needed, such as when emphasis is desired or when the term is ambiguous. But that doesn't always apply. For example, it is common practice to uppercase SQL terms when writing SQL code, and that's a practice I carry over to articles. Emphasizing that additionally by adding color is just too distracting, unnecessary, and purposeless. Especially if the article is already broken into small chunks of text with lots of PRE blocks (with so much emphasis, where's a reader to focus?).
-
The inline coloring seems useless much of the time. One of the editors did that to one of my articles and I felt it reduced the quality of the article. I could have changed it, but of course that becomes more difficult once an editor gets his/her grubby hands all over it. It can be useful to color code (or, say, italisize) code when it is needed, such as when emphasis is desired or when the term is ambiguous. But that doesn't always apply. For example, it is common practice to uppercase SQL terms when writing SQL code, and that's a practice I carry over to articles. Emphasizing that additionally by adding color is just too distracting, unnecessary, and purposeless. Especially if the article is already broken into small chunks of text with lots of PRE blocks (with so much emphasis, where's a reader to focus?).
I don't mind a single distinct color for highlighting .NET class names, C# keywords, or identifiers that should be taken literally and not be confused with the regular English words. So a teacher can explain about
classandFormandbool initializedin class. Unfortunately I had to add a lang="text" twice to get the above CODE snippets all in a single color, otherwise it would have looked like this: I don't mind a single distinct color for highlighting class names, keywords, or identifiers that should be taken literally and not be confused with the regular English words. So a teacher can explain aboutclassandFormandbool initializedin class. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
I also suggest, and this is new, you automatically replace CODE tags by PRE tags as soon as they span a newline. Yes, I want PRE blocks to be syntax colorized, as the colors work well on the PRE's background, whereas they don't work at all (at least for me) on the CODE background (especially the blueish one in forums). :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Luc Pattyn wrote:
also suggest, and this is new, you automatically replace CODE tags by PRE tags as soon as they span a newline
Adding to Luc's suggestion, we should also remove one PRE(or CODE) tag automatically if it's followed by another one immediately. In Q&A, many times, people put PRE tag to code part explicitly (for second time) even though when by default code gets formatted by a PRE tag while pasting. Ex:
protected void SampleCodeSnippet(object sender, EventArgs e)
{
// some code
}HTML presentation of above:
<pre><pre lang="cs">
protected void SampleCodeSnippet(object sender, EventArgs e) { // some code } </pre></pre> Above highlighted part can be formatted internally(i.e. remove one PRE tag)
modified on Wednesday, September 29, 2010 2:31 AM
-
Ever since I visited Italy I've found it very useful to be clear on what sort of queue I mean. Italy vs the Europe[^]
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Chris Maunder wrote:
Italy vs the Europe[^]
:-D :thumbsup: Nice one! I didn't knew Italy was so much similar to India! :laugh:
-
I don't mind a single distinct color for highlighting .NET class names, C# keywords, or identifiers that should be taken literally and not be confused with the regular English words. So a teacher can explain about
classandFormandbool initializedin class. Unfortunately I had to add a lang="text" twice to get the above CODE snippets all in a single color, otherwise it would have looked like this: I don't mind a single distinct color for highlighting class names, keywords, or identifiers that should be taken literally and not be confused with the regular English words. So a teacher can explain aboutclassandFormandbool initializedin class. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
I disagree. Most code posted on this site that has no lang tag in the PRE blocks is of a C flavour. Having a few messages be colourised incorrectly is a better tradeoff than having the majority of code blocks with no lang tag be uncoloured - especially given that the colouriser came in only after several hundred had already been posted. [Edit: and yes, a compromise is to have the default language set different for different modules]
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
You need to pay more attention to the discussion. We're not talking about the pre blocks. Those need to be colourized, where the colour adds a great deal to the clarity of the reader. By contrast, the code tag is for marking, as I said, usage of code within the article text.
Without darkness, there are no dreams. -Karla Kuban
-
I never said the FAQ article said the CODE block supported a lang attribute, i was merely pointing you to a list of attribute values for the various languages. :doh: I think some authors get mixed up when to use CODE and PRE and as a result some of the articles look too coloured. Agree that only code should be colourised using the CODE(for single inline statements, parameters, function names etc) and PRE for blocks of code. (Off Topic: Not fed up of Wonderware InTouch yet? we are ditching it as our main system in preference of Emerson DeltaV, although our turbine HMI's still use Intouch)
Dave Find Me On: Web|Facebook|Twitter|LinkedIn CPRepWatcher now available as Packaged Chrome Extension, visit my articles for link.
Oh. Well, thanks for the heads up, but I actually did give it a cursory read before I published my article. A good thing, too, because I was initially colorizing the code within the pre blocks using the CSS classes. Manually. :doh: As for InTouch, we often don't get to choose. When we do choose, we go with Windows Forms. But sometimes our customers buy our furnace and insist on integrating our Level 2 HMI within their existing SCADA system.
Without darkness, there are no dreams. -Karla Kuban
-
Silver members and above can edit that article. I've gone and added the magic few words.
knockNrod wrote:
When articles apply all the color-coding -- far from adding clarity -- they actually take away from the article by over-focusing the reader's attention on the colors, pulling the reader out of the context of that article.
I've gone back and forwards on this a few times. I'm leaning towards removing it again.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I understand. I went back and forth a couple times writing the article. In the end, I remembered something I learned about typesetting from the perspective of an editor: four fonts and two colors is enough. (Fonts here includes weight, point size, and italics -- extremely minimalist.) Any deviation should have a compelling justification. The reasoning is that the article should allow the reader to focus on the content, put them in the zone. Any deviation at all (including the four fonts and two colors) draws attention at the expense of pulling the reader out of the zone. (Note this doesn't preclude more, it's just that when you see more you should consider it the editorial equivalent of a code-smell.) I'm not saying that this opinion is right, but I've never heard a compelling contending argument. Hey, newspapers and magazines were successful for hundreds of years -- they must have learned some useful lessons.
Without darkness, there are no dreams. -Karla Kuban
-
I agree with you, the default for CODE should be
lang="text"which means no colorizing, since CODE is for short, single-line snippets, and hence does not benefit from any colorization. I have been pleading this for many years, without any luck. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
I understand. I went back and forth a couple times writing the article. In the end, I remembered something I learned about typesetting from the perspective of an editor: four fonts and two colors is enough. (Fonts here includes weight, point size, and italics -- extremely minimalist.) Any deviation should have a compelling justification. The reasoning is that the article should allow the reader to focus on the content, put them in the zone. Any deviation at all (including the four fonts and two colors) draws attention at the expense of pulling the reader out of the zone. (Note this doesn't preclude more, it's just that when you see more you should consider it the editorial equivalent of a code-smell.) I'm not saying that this opinion is right, but I've never heard a compelling contending argument. Hey, newspapers and magazines were successful for hundreds of years -- they must have learned some useful lessons.
Without darkness, there are no dreams. -Karla Kuban
My feeling is that the "two colours" rule doesn't always hold, especially for technical content that needs to be visually broken (eg comments and code). In any case, colourisation for CODE blocks has been removed and I'm hoping to do a final test and upload today.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Luc Pattyn wrote:
also suggest, and this is new, you automatically replace CODE tags by PRE tags as soon as they span a newline
Adding to Luc's suggestion, we should also remove one PRE(or CODE) tag automatically if it's followed by another one immediately. In Q&A, many times, people put PRE tag to code part explicitly (for second time) even though when by default code gets formatted by a PRE tag while pasting. Ex:
protected void SampleCodeSnippet(object sender, EventArgs e)
{
// some code
}HTML presentation of above:
<pre><pre lang="cs">
protected void SampleCodeSnippet(object sender, EventArgs e) { // some code } </pre></pre> Above highlighted part can be formatted internally(i.e. remove one PRE tag)
modified on Wednesday, September 29, 2010 2:31 AM
Yep - good idea. Added to the TODO
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP