[View source↑] [History↑] Sorting order: last modified first newest threads first oldest threads firstContentsThread titleRepliesLast modified Improve line number display of GeSHi syntaxhiglighting008:16, 23 August 2013 Disagree with bold+italic and code tag guidelines720:03, 6 December 2011 Special Tags208:21, 4 June 2011 Improve line number display of GeSHi syntaxhiglightingHistory SummarizeReading example codes with line numbers is currently difficult because the line numbers are shown in individual lines with code below it. It is preferable to have line number in the same line as the code. Please see the screenshots below for clarity. Before: [] After: [] I could get the line numbers to be displayed on the same line by editing bootstrap-mediawiki.css line 568 and removing the "list-style-position: inside;" style. Please look into this and edit the file on the server to display example codes in better manner. Thanks MoreHistory View source Link toSiddhartha (talk) 08:16, 23 August 2013 Disagree with bold+italic and code tag guidelinesHistory SummarizeOnly italic for replaceable and variable text Use this combination [Bold and Italic Text] for replaceable or variable text. I think that's overkill, it draws wayyy too much attention. Just use italics for variable and replaceable text, that's the convention used by O'Reilly books and most web sites. (The semantic HTML tag for variable text is <var> — enter your User Name. Note how it's just italic, not italic+bold.) extend code tag to end of entry Surely the <code> tag must extend over all the bits you type in, otherwise it's incoherent. The examples given are wrong. current (2011-12-01) type ssh [email protected] in Konsole better, it's all stuff you enter type ssh [email protected] in Konsole best (don't overstyle, variable text just in italic) type ssh [email protected] in Konsole kbd tag, not code, for user input Besides, the correct tag for things you must type is the <kbd> tag. From the HTML 2.0 spec at w3.org, "The KBD element indicates text typed by a user." <code> should be for bits of config files, sample output, etc. Let's try kbd: test using kbd tag instead type ssh [email protected] in Konsole The steps to get there from here are: Style kbd to have the same yellow background as current code and the input template. Change these guidelines, start using <kbd> for user input, and over time convert markup for text entry in existing wiki pages to it. Change the <code> tag to have the same violet-gray background as the output template. MoreHistory View source Link toskierpage 02:10, 2 December 2011 I generally have nothing against that. But... We have already Parley/Manual that does not even follow the current guidelines. Can anybody be a volunteer and fix everything (well, as the only manual which is more or less up-to-date and complete now, at least Amarok/Manual) on manual pages? It would also be good to present some table of correspondence. Ex.: Description Code Code example Result Inline user input <kbd></kbd> <kbd>ssh -h</kbd> ssh -h Thanks. Parent MoreHistory View source Link toYurchor 10:11, 2 December 2011 "Only italic for replaceable and variable text" - I dislike the effect of the combination, but then Italic, standing alone, already has a defined role. In my opinion to give it this role as well will cause a great deal of confusion. "extend code tag to end of entry" - I agree, but if we develop the additional tag there will be no point in starting such edits. "kbd tag, not code, for user input" - I await Yurchor's comment as to whether, in the long run, this would help or not. I'm happy to go ahead, if he is, but his comment about getting people to follow rules does stand. We have seen a strong argument in the last week or so where a writer saw no reason to obey our rules. This leaves us, I think, having to choose between discouraging writers or creating a team of editors to mark up every new page, as soon after creation as possible, with standardised markup. That's something of a thankless task, and I'm not even sure that the authors would accept it. Parent MoreHistory View source Link toannew 16:51, 5 December 2011 In the long run it does not matter. Most of authors do not care any rules. They choose formatting freely and deliberately even on the pages with "default" formatting. Re-formatting pages is just a waste of time (imho). Tomorrow someone can dislike something else... If there will be no overlaps we can proceed with any formatting. There are enough editors to fix articles (at least now). And I'd rather revert any inconsistent changes in markup in manuals without having at least a little hope of fixing the whole manual by the particular editor. The consistent look and feel of manuals is better than inconsistent usage of the best markup ever discovered (imho). Parent MoreHistory View source Link toYurchor 18:01, 5 December 2011 I'm not sure what you're saying. Yes most people don't follow rules, but it can only help to develop the right rules. The more they make sense and are consistent with what people are used to (italics for variables, kbd as the tag for the keyboard input, etc.), the easier they are to follow. I can live with bold and italic as your variable text rule if changing it will introduce inconsistency within your wiki. But extending the box and using <kbd> make sense, and over time the wiki will improve. Parent MoreHistory View source Link toskierpage 06:10, 6 December 2011 I have no problem with this if someone will fix all inconsistent markup. Parent MoreHistory View source Link toYurchor 06:40, 6 December 2011 Anyone got a month or two to spare? Seriously though - since we are all agreed that <code> markup should encompass whole commands, the logical first step is to correct such things as we find them. Even if we felt it worth the time involved, there is no way that you could search for and find such broken instances, so it's down to alertness and common sense. To be honest, I would rather not include new tags such as <kbd> unless we can see a genuine advantage to it. Parent MoreHistory View source Link toannew 16:36, 6 December 2011Show 1 reply Special TagsHistory SummarizeEdited by another user. Last edit: 08:21, 4 June 2011Under Special Tags it says: <keycap></keycap> can also be used around groups of keys to be used concurrently, e.g. Ctrl+Alt+F1 to launch a virtual terminal. (Note that Note that "+" is used to link keys to be pressed concurrently). My question is: 1. Shouldn't Ctrl+Alt+F1 use <keycap></keycap> instead, i.e. Ctrl+Alt+F1 2. Shouldn't the separator be " + ", i.e. (space)+(space), as written on Edit Markup#Special_Tags? In this case it would be Ctrl + Alt + F1 I can change this if I get an OK. MoreHistory View source Link toHans 10:36, 11 October 2010 1 - it was bold text merely to draw attention to the group of characters. However, I've accepted your alteration. 2 - Older pages do not have spaces there, newer pages do. I'm not making an issue out of this, since the i10n team haven't expressed a preference, but I've amended the page to show the 'newer' version. Pages with the older version can be changed as and when other edits are needed. Those particular changes should be marked with a "Don't invalidate translation" tag. Parent MoreHistory View source Link toannew 18:57, 11 October 2010 Excellent, thank you. Parent MoreHistory View source Link toHans 21:34, 11 October 2010 Retrieved from "https://userbase.kde.org/index.php?title=Talk:Typographical_Guidelines&oldid=91610#Special_Tags_588" This page was last edited on 11 October 2010, at 10:36. Content is available under Creative Commons License SA 4.0 unless otherwise noted.