Closed Bug 665733 Opened 13 years ago Closed 12 years ago

Kuma: Syntax highlighting, with optional line numbering

Categories

(developer.mozilla.org Graveyard :: Wiki pages, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: openjck, Assigned: groovecoder)

References

Details

(Whiteboard: u=user c=wiki p=2 2.4.5)

      No description provided.
Version: unspecified → Kuma
Assignee: lcrouch → nobody
Target Milestone: 1.0 alpha → ---
Priority: -- → P1
Blocks: 710713
Code examples in Kuma are barely styled.

Syntax highlighting is currently implemented on MindTouch with dp.SyntaxHighlighter [1], but we've talked about moving to jsFiddle [2]. Maybe now's the time to switch?


[1] https://github.com/alexgorbatchev/SyntaxHighlighter
[2] http://jsfiddle.net
Target Milestone: --- → 1.9
Let's do the same syntax highlighter for now.
Whiteboard: [u: user] [c: wiki] → u=user c=wiki p=1
Target Milestone: 1.9 → 2.0
Target Milestone: 2.0 → 2.1
Target Milestone: 2.1 → ---
Whiteboard: u=user c=wiki p=1 → u=user c=wiki p=2 2.4.5
Target Milestone: --- → 2.4
Assignee: nobody → lcrouch
This was easy to start but I came across an issue.

DekiWiki stores code blocks like this:
<pre class="deki-transform" function="syntax.JavaScript">

Which then renders like this:
<pre class="js" name="code" style="display: none;">

(The new version of) SyntaxHighlighter wants blocks like this:
<pre class="brush: js">

Should we convert the pre tags during migration? Or should we try to match DekiWiki's rendering logic to turn the 'deki-transform' class into 'brush: js'? Or should we try to modify SyntaxHighlighter?

Personally, I vote for converting the pre tags during migration - it gets us all the way off MindTouch/DekiWiki semantics.
To sum up my IRC ramblings: 

I'd lean toward *not* changing the page content, just on principle of fewer things with a chance to damage content. Instead, this could be supported purely in JS.

That said, the JS to support this would be legacy cruft, and converting the content in migration is not necessarily a bad idea.

Something else that just occurred to me: We'll need to document this as a part of a "what's changed for authors in Kuma" guide that I don't think we've thought about yet.
Blocks: 733803
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Version: Kuma → unspecified
Component: Website → Landing pages
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.