Module talk:Chessboard

Bug

Making the icons use position:absolute (i.e. inside a div instead of a table) caused an obscure and probably coincidental css rule for nested elements to give each of them a white background, effectively negating the svg/png transparency, to wit:

div.thumb div a img {
    background-color: #FFFFFF;
}

I tracked this down in Firebug as having originated from the following url:

• http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=site&only=styles&skin=monobook&*

My edit to this module fixed the visual problem immediately by conveniently removing element "a" from the hierarchy and dodging the above css rule (see before & after screen-shot taken from Template:Chess diagram/doc) but I'm amazed nobody else had complained about it. If we really do want each chess-piece icon to link to the image page as they did before my edit, we will need some superseding CSS rule to work around this bug. ―cobaltcigs 09:20, 9 June 2013 (UTC)

thank you. it's possible that this was recently-introduced. I have made a corresponding change to Module:Chessboard mxn, which probably wasn't necessary, since that template doesn't use transparent backgrounds, but it will make lack-of-link consistent. Frietjes (talk) 16:02, 9 June 2013 (UTC)

thank you for reporting the problem. however, your solution caused collateral damage: when removing the "a" from the hierarchy (by adding link="), we lose the tooltip, which, for each piece, gave the square algebraic notation ("e6" etc.), the color and the piece name. i am undoing it, and instead will try something else (i think i'll just pack the image in some surreptitious element, maybe another "div" or "span" or something). i have no idea why monobook has this rule - i does not make too much sense: if such a rule is really needed, why just monobook? "div, thumb div a img" is clearly something to do with content and not interface, and i can't think of a good reason why same content with monobook should have white background to images while other skins leave the img background untouched. the correct solution, IMO, would be to remove this rule (unless someone can explain why monobook should have it). peace - קיפודנחש (aka kipod) (talk) 00:39, 10 June 2013 (UTC)

Sorry, I didn't notice we had customized/meaningful tool-tips until you told me so. My subsequent edit appears to keep them appearing by moving the title attribute (a.k.a. tool-tip) to the outer "span" element. This is the string which is normally forwarded to an "a" element from the final parameter of the [[Image:...]] syntax when parsing wikitext. A CSS rule has the same effect regardless of what elements are nested between those named in the rule. ―cobaltcigs 04:16, 10 June 2013 (UTC)

yes, i found that out... i made some experiments, such as replacing the "div" element with some other element, but didn't get anything that actually worked, and i had to get away from keyboard. one thing i did do is to leave a message to the gentleman who created this css rule (back in 2005): User talk:Omegatron#request to undo ancient edit. the reason nobody noticed until now, is that it seem that few enough people use monobook, and of those, few enough people look at chess articles... well, thatks for solving it. peace - קיפודנחש (aka kipod) (talk) 06:08, 10 June 2013 (UTC)

thanks for making the edit request. it appears this rule has now been removed, so we can go back to what we had before? Frietjes (talk) 19:39, 12 June 2013 (UTC)

Okay I've reverted it. This is not as an affirmation that linking to the svg description pages several times from every chessboard on the page is terribly important (wikibooks' boards, see e.g. QGA, have neither links nor tool-tips), only that doing so no longer obscures the square color. ―cobaltcigs 02:43, 13 June 2013 (UTC)

Bug In The Mobile Version

The styling of the chessboard breaks when using the mobile version of Wikipedia. It's really bad on Webkit, with both desktop and mobile versions of the browser (when viewing the mobile version of Wikipedia). Other browsers show somewhat broken (but still usable) layout.

To replicate

1. Go to http://en.m.wikipedia.org/wiki/Fool%27s_Mate using any Webkit-based browser, either on a desktop computer, or on a mobile device

2. Note the broken display of chessboard, esp. in the "Details" section. Example screenshot.

Explanation

The mobile version's CSS interferes with the styling of the chessboard, particularly with the padding and verical-align.

Fix

Each <td> tag's style attribute must also contain the following: padding: 0; vertical-align: inherit;. I don't know how to edit modules on Wikipedia, otherwise I might've fixed this myself.

Disclaimer

I've tested this solution on iOS Safari and Chrome, and on latest desktop Chrome, FF and IE. The fix worked in every case.

--Exizt (talk) 13:12, 11 August 2013 (UTC)

Repetitive style attributes for every single table cell would be more appropriately achieved through CSS rules. Let's say we assign some classname to the root table element in line 130, like <table class="chess-diagram" ...>. Then a CSS rule like table.chess-diagram td { padding: 0; vertical-align: inherit; etc; etc; }. The td height and width properties in place now could also be phased out by hard-coding only the total table dimensions (at 10×{{{size}}}) and employing table-layout:fixed. ―cobaltcigs 14:29, 11 August 2013 (UTC)

This is definitely preferrable, but can Wikipedia modules add their own styles? --Exizt (talk) 14:42, 11 August 2013 (UTC)

It would be great if they could. See previous thread for an example of non-coordination between template/skin maintainers. ―cobaltcigs 15:32, 11 August 2013 (UTC)

Meanwhile, could we change how the current module works? I can't find any mention of how to do so. --Exizt (talk) 15:34, 11 August 2013 (UTC)

I could try. Do you mean only the 36 border cells containing the coordinates (with 4 empty corners), or should the 8×8-spanning middle cell containing the board also have the above style properties? ―cobaltcigs 15:41, 11 August 2013 (UTC)

I went ahead and did both. How's it look? ―cobaltcigs 15:52, 11 August 2013 (UTC)

It seems we should add a "max-width: none !important" to the style of all <img>s (all pieces and chessboard itself). -Exizt (talk) 18:13, 11 August 2013 (UTC)

is there a similar problem with module:Chessboard mxn? or does the fact that that template is using a different method avoid the issue? thank you. Frietjes (talk) 18:37, 11 August 2013 (UTC)

Can you provide an example of an article that uses this module? -Exizt (talk) 19:35, 11 August 2013 (UTC)

http://en.m.wikipedia.org/wiki/Capablanca_chess ―cobaltcigs 02:00, 12 August 2013 (UTC)

http://i.imgur.com/tGSGV6z.png -- it's broken, too, but not as broken.

Editing protected css pages is in fact the only way to set style properties directly on an img tag. If you get the attention of somebody willing to do that, be sure to mention those other changes (in the interest of html reduction). ―cobaltcigs 01:57, 12 August 2013 (UTC)

You forgot to add a "vertical-align: inherit; padding: 0" to the right "8" cell (it's the last <td> in the second <tr> (the <tr> that contains the chessboard image)), and also to the empty corner <td>s (they don't have a "style" attribute specified yet). Fixing this seems to fix the layout.

However, the SVGs are still resized to become too big. To fix this, their parent <div>'s width and height must be set explicitly. So this should be added to their style attribute: "width: 23px; height: 23px;" -Exizt (talk) 09:38, 12 August 2013 (UTC)

Fixed?

So, I went ahead and changed the module myself. I've tested the fix on Chrome, mobile Chrome for iOS, and the following desktop browsers: latest Chrome, latest FF, IE7+. —Exizt (talk) 09:06, 13 August 2013 (UTC)

Highlighted pieces with red frame are not supported

Hello,

Highlighted black King on light square e8

	a	b	c	d	e	f	g	h
8	e8 k D								8
7									7
6									6
5									5
4									4
3									3
2									2
1									1
	a	b	c	d	e	f	g	h

LUA issue with uppercase color of piece kD

{{Chess diagram|=
| tright
| Highlighted black King on light square e8
|=
|rd|nd|bd|qd|kD|bd|nd|rd|=
|pd|pd|pd|pd|ua|pd|pd|pd|=
|  |  |  |  |  |  |  |  |=
|  |  |  |  |  |  |  |  |=
|  |  |  |  |  |  |  |  |=
|  |  |  |  |  |  |  |  |=
|pl|pl|pl|pl|pl|pl|pl|pl|=
|rl|nl|bl|ql|kl|bl|nl|rl|= 
| LUA issue with uppercase color of piece '''kD'''
}}

The LUA script, used in the en:WP chess diagram template, needs the transplant version of the highlighted black King Chess_kDt45.svg, which does not exist.

There are only:

• the transplant version without the red frame or
• the non transplant version on light and dark squares: , .

Could you fix the LUA script in order to use Chess_kDl45.svg on light square or Chess_kDd45.svg on dark square instead of the missing transplant version? Otherwise, if it is simpler, could you create the transplant highlighted pieces with red frame?

' color of piece in uppercase (D)ark or (L)ight for highlighted piece with red frame
If color of piece = "D" or "L" Then
    Use the image of the highlighted piece with red frame on a dark or light square.
    Do not use the (t)ransplant version 
    because the transplant highlighted piece with red frame does not exist.
End If

The following fully featured example can be copied and pasted in WP:SB for test (see Template:Fr 2.1 The Immortal Game diagram):

{{Chess diagram|=
| tright 
| [[Immortal Game]] (1851)
|=
 8 |rd|nd|bd|la|kD|xx|nd|rd|=
 7 |pd|  |xx|pd|ur|pd|pD|pd|=
 6 |xo|  |  |bl|  |oo|  |  |=
 5 |  |pd|bd|nl|ua|nl|  |pl|=
 4 |  |  |  |dr|pl|ua|pl|  |=
 3 |  |  |  |pl|dr|ql|  |  |=
 2 |pl|qd|pl|  |ul|dr|  |  |=
 1 |rL|ra|ra|ra|ra|kl|rL|  |=
    a  b  c  d  e  f  g  h
| Anderssen 18.Bf4-d6 versus Kieseritzky 18... Bc5xRg1 19.e4e5 {cut the long diagonal} Qb2xRa1+ 20.Kf1e2 Na6? 21.Nf5xg7+ Ke8d8 22.Qf3f6+! {Queen sacrifice} Ng8xQf6 23.Bd6e7# 1-0
}}

Nimmzo (talk) 20:15, 14 September 2013 (UTC)

I was thinking we could do this with a border style in the divs, but would be more efficient, and less work, to just create the transparent images. Frietjes (talk) 22:33, 24 September 2013 (UTC)

Module:Chessboard mxn

Hi! I'm going to copy this module to Ukrainian Wikipedia, but I want to know one thing first before transition. Why do we need both Module:Chessboard and Module:Chessboard mxn, but not a single, general template which Module:Chessboard mxn seems to be from the first look? --DixonD (talk) 13:48, 24 September 2013 (UTC)

the Module:Chessboard uses a different method for generating the board which uses transparent image overlays, rather than generating every single square. since we have the light/dark background images for all the squares, Module:Chessboard mxn should work for everything. it may be a bit slower on boards with very few pieces, since more images need to be loaded, and the generated HTML may be a bit bigger, but it should work in all cases (as far as I can tell). Frietjes (talk) 14:37, 24 September 2013 (UTC)

the "mxn" way works similar to "the old way", which is slower to render, and even more important, it breaks the mediawiki parser limitation once you have enough boards on one page. the other one is not entirely free either, and also has some "boards per page" limits, but because it's significantly more efficient, the parser can handle many more boards per page. to illustrate: using the "mxn" way, the parser balks with about 50-60 8x8 boards. with the other way, you can have more than 200, and if the boards are sparse (i.e., contain small number of pieces each), then it can handle many more. and, as mentioned, it renders significantly faster, both on the server when you hit "save", and on the use agent, when someone loads the page. peace - קיפודנחש (aka kipod) (talk) 15:56, 24 September 2013 (UTC)

yes, that's true, the Module:Chessboard mxn will be slower for pages with a large number of boards per page. here is the not-entirely-scientific comparison from the 60 board speed test in the testcases

Chessboard	Chessboard mxn
NewPP limit report CPU time usage: 8.605 seconds Real time usage: 11.023 seconds Preprocessor visited node count: 9744/1000000 Preprocessor generated node count: 56384/1500000 Post‐expand include size: 967835/2048000 bytes Template argument size: 0/2048000 bytes Highest expansion depth: 2/40 Expensive parser function count: 0/500 Lua time usage: 0.743s Lua memory usage: 912 KB	NewPP limit report CPU time usage: 13.057 seconds Real time usage: 18.762 seconds Preprocessor visited node count: 11784/1000000 Preprocessor generated node count: 60464/1500000 Post‐expand include size: 1144715/2048000 bytes Template argument size: 0/2048000 bytes Highest expansion depth: 2/40 Expensive parser function count: 0/500 Lua time usage: 1.064s Lua memory usage: 886 KB

Frietjes (talk) 16:06, 24 September 2013 (UTC)

Thank you, it makes a perfect sense. However I still wonder if we can come up with something general (I don't like the idea having several templates/modules doing similar things). So what if we have a version of Module:Chessboard mxn working "in the new way" for most common sizes (detecting it from user input) and "the old way" for the rest? Sorry, if I'm saying nonsense now, I should have been invested more time into understanding how it works (will do it anyway). I'm just seeking for some quick answers prior to diving into code:) --DixonD (talk) 19:12, 24 September 2013 (UTC)

yes, it would be possible. the main thing is that the "standard" (8x8) uses an image with the board itself (aka File:Chessboard480.svg). in order to use the same logic for the mxn case, one of two things need to be done: we could either create an image for every possible size, or we could create one large image (say, 20x20 or so), and very carefully display it inside a div where we clip it with "overflow:hidden". the reason this is not done is that either of these would take significant amount of work, and since 97.12% of the *actual* use is for 8x8, we took the approach of "who cares about some extra time to parse and display the non-standard sizes - they are used rarely enough that it doesn't matter".

now, if someone wants to use the same code for both 8x8 and mxn, then this someone will better do it at least as efficiently as we do the 8x8 today, which means use a background image for the board and transparent-background pieces. as i said, this will require you to either create an image for each allowed mxn, or create one image which is large enough, and contain it inside a clipping div.

personally, i think the current situation is good enough.

just to explain what is my relation to this module: i created the original one, where my goal had little to do with performance - what i really cared about was the ability to use the FEN string as the input rather than the 65+ parameters used before. the improvement in performance was an important "selling point", but it was not the main thing for me.

as the module history shows, the bulk of the work to make this a real, useful thing was done by others - most notably User:Frietjes, who also created Module:Chessboard mxn from scratch.

peace - קיפודנחש (aka kipod) (talk) 22:23, 24 September 2013 (UTC)

I don't know if there is significant overhead if you have unused functions in a module. if this does create significant overhead, we could certainly strip this module down more, removing the auxiliary ascii2fen and ConvertArgsToFen conversion functions, which are not used by the main board function. if there is no significant overhead from unused functions, then merging the two modules would seem like good idea. I agree with kipod that the current situation of two modules seems to be working fine. Frietjes (talk) 22:32, 24 September 2013 (UTC)

when parsing pages with chess boards, the lua code itself represent minuscule portion of the time anyway, so it does not really matter what overhead some unused functions represent (i think there is no such overhead anyway, but i never tested it). however; it is not clear what's the value of cramming both modules together in a single one: if there is a lot of copy/paste of code or constants (IOW, there is a lot of duplicated code, and the size of the combined module will be significantly less than the sum of sizes of existing ones), then it makes sense. otherwise, i do not see much value. there is no cost of having two modules, the main "cost" is having duplicated code. peace - קיפודנחש (aka kipod) (talk) 23:51, 24 September 2013 (UTC)

So I combined two modules into one in Ukrainian Wikipedia. You can see it on uk:Модуль:Chessboard. In short, the logic is follows: if we have an image for the specified size in "known_boards", we use the new method. Otherwise, we use the old method. The overhead shouldn't be big if any for an 8x8 board (even though I haven't tested it), as it is just a matter of few extra lines executed in this case. --DixonD (talk) 08:39, 27 September 2013 (UTC)

use mw.html module to create the html code

i started this module, but as of now, most of the code in it is not "mine", and i don't think i want to modify it myself.

i wrote the code before mw.html was available (or at least, before it was documented, which is practically the same thing). i think it will be good to convert the existing "manual" building of html elements to use the mw.html tooling - the code will be clearer to understand, and easier to modify (esp. for porting it to other projects, or if it will ever be moved to a centralized location a-la commons).

again, i do not want to do it myself, but i think it will be good if someone will volunteer to do it.

peace - קיפודנחש (aka kipod) (talk) 21:52, 3 February 2014 (UTC)