MediaWiki talk:Gadget-DotsSyntaxHighlighter.js

Bug with parser function inside external link
This syntax does not highlight properly in Firefox 32.0.3 on Windows:

[ my text]

The  gets highlighted in yellow, but the external link syntax around it does not. I realize this is a tricky case because the syntax highlighter doesn't call the fullurl parser function, but maybe fullurl is common enough that it should be handled specially. --Maiden taiwan (talk) 15:33, 10 October 2014 (UTC)


 * I think the fullurl syntax is different in different languages, which would make handling it difficult (this is the same reason why etc. are not highlighted). Maybe it's time to engineer in a language pack system to grab the localized text you need for your language and no others. To be honest though, I'm not sure that what you're doing is all that common, and maybe it could be better handled by writing a template that makes a fullurl link automatically. —Remember the dot (talk) 16:59, 10 October 2014 (UTC)


 * Thanks for your quick reply! The fullurl pattern is the recommended solution when you're creating local links with query string arguments, like . On our wiki, this is reasonably common. Anyway, I hope my suggestions are helpful. Maiden taiwan (talk) 18:29, 10 October 2014 (UTC)

r.style.clear = "both";
Just wanted to report that in order to make the highlights match the text on Persian Wikipedia I had to add  to the code (which I think was required because of the special style of some of our toolbars). Thanks for this great gadget. Dalba 27 Aban 1393/ 11:11, 18 November 2014 (UTC)


 * I just tried the mainline code on the Persian Wikipedia and I didn't see any problems. What browser and skin are you using? Have you enabled any special toolbars? (And by the way, the actual source code is at User:Remember the dot/Syntax highlighter.js.) —Remember the dot (talk) 06:57, 19 November 2014 (UTC)
 * I'm using FF 33.1, vector skin. Yes, I've enable a non-default gadget (toolbar) on my account (Sorry that I didn't mention this before, I thought it is a default gadget). To reproduce the problem I think you need to run the code in this gadget so a toolbar will be added to top of the editbox. Then run your own code. Dalba 28 Aban 1393/ 07:26, 19 November 2014 (UTC)
 * I thought this over and I decided to adopt your solution. The syntax highlighter forces the textbox to width:100% anyway, so I don't see the harm in clearing floating elements too. —Remember the dot (talk) 05:56, 11 December 2014 (UTC)

Detecting changes to the text direction
As an RTL user I frequently need to switch direction of the text (using ctrl+shift+x in Firefox), but the direction of highlights is not changed accordingly. I don't know if it's possible or not, or how much it could affect the performance of the script, however it would be very nice if DotsSyntaxHighlighter could detect this. Thanks. Dalba 20 Azar 1393/ 06:51, 11 December 2014 (UTC)


 * Done. Would you like to contribute a Farsi translation of errorMessage while you're at it? —Remember the dot (talk) 18:58, 11 December 2014 (UTC)
 * Sure, I will be glad to. Here it is:
 * - Dalba 20 Azar 1393/ 22:19, 11 December 2014 (UTC)
 * - Dalba 20 Azar 1393/ 22:19, 11 December 2014 (UTC)

Fix error caused by elements
Can the code  be replaced with. Or line 204 from the better formatted script from if (text.charAt(tagEnd - 2) == "/" ) to if (text.charAt(tagEnd - 2) == "/" || match[0].substring(1) == "br" )

This will allow the script automatically treat  elements as self closing, since they are.

Also, is there any specific reason the code here uses generic variables and no whitespace? --KnightMiner (t/c) 16:45, 15 June 2015 (UTC)


 * I am not going to maintain a massive whitelist of every self-closing element that could possibly exist. Use  instead. —Remember the dot (talk) 20:08, 15 June 2015 (UTC)


 * I am not going to edit every article on Wikipedia just to replace  with   just so I can have the syntax highlight work (especially since   is both perfectly valid HTML5 and commonly used). If you do not want to maintain a list, at least add a feature for a user to define their own list (such as by adding the case  .). --KnightMiner (t/c) 22:11, 15 June 2015 (UTC)


 * While adding a config option would be more palatable than maintaining a list, it would still place a sizable burden on the site administrators to make sure that the list of self-closing tags is exactly correct for the MediaWiki extensions installed on the site, taking into account that the tags may have different names in different languages. Also, standardizing on one tag form gives wikitext a more consistent appearance that is less confusing to people new to HTML. The argument that  should be supported because it is "valid HTML5" is not a great argument because HTML5's purpose was to make any widely supported design decision "standard" no matter how bad of an idea it was. In fact, even though it would be "valid" to leave   alone, MediaWiki automatically normalizes it to   in the page output so that every page can be manually inspected with ease or parsed with a simple, low-overhead XML parser. In the same way, adding support for implicitly closed tags would also slow down the syntax highlighter's parser, and the #1 complaint about it has been that it's too slow already.
 * Long story short, I think the right thing to do is to gradually phase out implicitly closed tags in favor of explicitly closed tags in order to present a simple, clear syntax to users, minimize the burden on site administrators, and maximize highlighting speed. I don't expect you to agree with me, but I hope that you can at least see that this way forward has its advantages. I do have a question for you: Why are you using  directly in the first place? Why not build it into templates and use it directly as little as possible? —Remember the dot (talk) 22:55, 15 June 2015 (UTC)


 * Yes, standardization would be a easier (and faster) solution, but as it is currently not deprecated, I still conciser it more convenient. Also, until the software stops supports using it, I cannot see the users stopping using it even should it become deprecated, as quite a few times I have seen someone add a deprecated parameter (like  on a div) simply because it is shorter.
 * Specific cases I tend to see it include within table cells (such as on the articles on the various Doctor Who series) and talk pages (which better control formatting in the case of bullet lists and the occasional signature to add two half-height inline words). --KnightMiner (t/c) 01:49, 16 June 2015 (UTC)

&lt;br> is standard, users believe they edit the text in HTML-like style, not XML. Too much of a burden to follow every user and ask to use &lt;br /> instead, not to mention that it requires unnecessary keystrokes. Browsers have accelerated in recent times, I believe the performance would not suffer much. Jack who built the house (talk) 15:10, 9 June 2016 (UTC)