Template talk:Asbox

Navbar position
I've got a sandbox edit (diff) which moves style attributes to new templatestyles (Template:Asbox/styles.css), and also moves the navbar to prevent it from overlapping text. The navbar is invisible by default, but can be made visible by user CSS. See Template:Asbox/testcases. Please let me know if you see any issues. Matt Fitzpatrick (talk) 15:09, 27 February 2021 (UTC)

Interaction between Asbox and Infobox
Following a discussion at WT:FOOTY, I have worked out that is there is an Asbox level with part of an Infobox that there is some strange behaviour. Any links with the infobox that are level with the Asbox will not be clickable, and if you try to select the content within the infobox and move into the same region, then text outside the infobox will become selected. Is this something that is known about, and if so is there anything that can be done about it? As an example, I created User:Spike 'em/sandbox/fw as a copy of an article exhibiting the problem and cut out as much as possible, and used subst to get down to the lowest level of template / module. Spike &#39;em (talk) 17:26, 11 March 2021 (UTC)
 * It's not specific to either asbox or infobox. The problem is one of a conflict between two divs, one being full-width (in this case, the asbox) and the other being absolutely-positioned (the infobox), which are trying to occupy the same portion of the screen. Only one of them can be on top. The area occupied by the infobox is obvious, because of its border; you can reveal the edges of the asbox div by styling it, such as by placing this CSS rule  into Special:MyPage/common.css. Then visit the problem article, and you should find that the asbox background now obscures part of the infobox, including the links that you refer to above. The normal asbox has no background, so it's transparent; but that doesn't mean that the background isn't there. -- Red rose64 &#x1f339; (talk) 09:39, 12 March 2021 (UTC)
 * , this should be fixable by adding overflow:hidden to the asbox css style definition, to force it to create a new block formatting context (just like we do for headings) —Th e DJ (talk • contribs) 12:25, 12 March 2021 (UTC)
 * , I had a play with that, and indeed the asbox div does sit on top of the infobox. Is there anyway to make it go behind, given that the table within it resizes based on the presence of the infobox (so the text within wraps rather than overwriting the infobox)? I removed the asbox class from the div and can then access the links again, even though the div is still as wide as the page. Spike &#39;em (talk) 12:29, 12 March 2021 (UTC)
 * Or, based on the suggestion from TheDJ, I added  to the style tag just before the div, and that created a box just around the text and left the infobox unaffected. Spike &#39;em (talk) 12:33, 12 March 2021 (UTC)
 * And finally, I changed my common.css to  and that fixes all the problematic articles. Spike &#39;em (talk) 13:02, 12 March 2021 (UTC)
 * I don't know what you mean by I added to the style tag just before the div - which style tag is that? The MediaWiki software does not allow use of  tags, although they would indeed be used to enclose CSS rules - if they were whitelisted. -- Red rose64 &#x1f339; (talk) 10:20, 13 March 2021 (UTC)
 * I inspected / amended the html in chrome to test it directly and then amended my .css settings as mentioned. I'm not an expert on this, but it does seem that what TheDJ suggests will fix this problem.  Spike &#39;em (talk) 10:53, 13 March 2021 (UTC)
 * Hello, just visiting from Module talk:Adjacent stations/Amtrak where we saw the same issue. I agree that modifying the overflow property for asbox resolves the issue and it does feel like the right solution. Mackensen (talk) 13:18, 14 March 2021 (UTC)
 * I have added Template:Asbox/sandbox/styles.css and tested on pages in my own sandbox which are copies of the pages where the issue has been noticed (User:Spike 'em/sandbox/fw and User:Spike 'em/sandbox/KFS). I've checked the testcases page and all looks ok in there, but I did notice that when testing in my own sandbox that having both the asbox/sandbox and plain asbox on the same page caused both to work properly (I guess the .css attributes are additive). Spike &#39;em (talk) 10:34, 15 March 2021 (UTC)
 * , correct. I think we can make the edit request.
 * Please apply the following change to Template:Asbox/styles.css: diff —Th e DJ (talk • contribs) 12:29, 15 March 2021 (UTC)
 * ✅, and thank you all very much!  P.I. Ellsworth   ed.  put'r there 18:18, 15 March 2021 (UTC)
 * Please apply the following change to Template:Asbox/styles.css: diff —Th e DJ (talk • contribs) 12:29, 15 March 2021 (UTC)
 * ✅, and thank you all very much!  P.I. Ellsworth   ed.  put'r there 18:18, 15 March 2021 (UTC)

i18n unfriendly normalization
This line, is making this module not useful for other wikis where ZWNJ (and maybe ZWJ) is used in category titles which they aren't a part of,   and   so I had to add ZWNJ to them on fawiki, can you avoid the replace or allow the characters that actually have semantic use at least in other languages? Thanks! −ebrahimtalk 19:03, 22 March 2021 (UTC)
 * This can be applied to fix this. −ebrahimtalk 19:18, 22 March 2021 (UTC)
 * The code is there for a very good reason: see Template talk:Asbox/Archive 4. Any changes must not cause those problems to recur. -- Red rose64 &#x1f339; (talk) 21:53, 22 March 2021 (UTC)
 * Interesting issue. LRM, RLM shouldn't be used at titles of course but ZWNJ is different, running  (ZWNJ is in between of %%) gives 287200 so there is 287200 categories with ZWNJ on fawiki, there can be a balance here I believe, one can go for eliminating all the non-Latin characters on English Wikipedia and one can allow all the things, I'm not suggesting either at the moment but just to add ZWJ and ZWNJ. −ebrahimtalk 18:31, 23 March 2021 (UTC)
 * Yes check.svg Done I've made a similar change to the last-requested one. Izno (talk) 01:43, 5 June 2021 (UTC)
 * Izno: Would you please add ZWJ and ZWNJ also as the original request? Just allowing that two unicode points wouldn't be hurtful so in future English Wikipedia applies the same logic on other places based on the same reasoning updating Lua module wouldn't have silently failures for us. Thanks −ebrahimtalk 09:25, 5 June 2021 (UTC)
 * Please make it obvious in sandbox what it is you want to add. I look at the presented diff from fa.wp and even the en.wp version of the same and do not see a meaningful difference, which is bad. If you're going to use hidden characters in a pattern, use their Unicode references as in Module:Citation/CS1/Configuration (see  ) so that other users do not a) possibly remove them in the future unintentionally and b) so that the exact characters are trivially inspected for reasonability. Izno (talk) 16:15, 5 June 2021 (UTC)
 * Izno: My bad, sure, I didn't know about how to encode them like that in Lua, thanks for the pointer, https://en.wikipedia.org/?diff=1027068468 −ebrahimtalk 22:39, 5 June 2021 (UTC)


 * As the above discussion please consider applying this change as the same change in Persian Wikipedia resolves our issue and I think it makes sense to keep such code changes upstream so no silent failures happens on module updates. Thanks! −ebrahimtalk 10:00, 11 June 2021 (UTC)
 * ✅ &mdash; Martin (MSGJ · talk) 11:07, 21 June 2021 (UTC)

Sandboxes in main module
Your recent edit started using sandboxes in the live module. This is of course not good. Could you take care of it? --Trialpears (talk) 11:32, 21 June 2021 (UTC)
 * Thanks for letting me know, fixed &mdash; Martin (MSGJ · talk) 11:37, 21 June 2021 (UTC)