edit

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)Reply

Interaction between Asbox and Infobox

edit

Following a discussion at WT:FOOTY#Francisco Wagsley, 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 'em (talk) 17:26, 11 March 2021 (UTC)Reply

@Spike 'em: 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
/* reveal area occupied by an asbox */
div.asbox {
  background-color: #efefff;
  border: 1px solid blue;
}
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. --Redrose64 🌹 (talk) 09:39, 12 March 2021 (UTC)Reply
Redrose64, 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) —TheDJ (talkcontribs) 12:25, 12 March 2021 (UTC)Reply
@Redrose64:, 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 'em (talk) 12:29, 12 March 2021 (UTC)Reply
Or, based on the suggestion from TheDJ, I added .asbox{overflow:hidden} to the style tag just before the div, and that created a box just around the text and left the infobox unaffected. Spike 'em (talk) 12:33, 12 March 2021 (UTC)Reply
And finally, I changed my common.css to
div.asbox {
  overflow: hidden;
}
and that fixes all the problematic articles. Spike 'em (talk) 13:02, 12 March 2021 (UTC)Reply
@Spike 'em: I don't know what you mean by I added .asbox{overflow:hidden} to the style tag just before the div - which style tag is that? The MediaWiki software does not allow use of <style>...</style> tags, although they would indeed be used to enclose CSS rules - if they were whitelisted. --Redrose64 🌹 (talk) 10:20, 13 March 2021 (UTC)Reply
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 'em (talk) 10:53, 13 March 2021 (UTC)Reply
Hello, just visiting from Module talk:Adjacent stations/Amtrak#Klamath Falls station 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)Reply
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 'em (talk) 10:34, 15 March 2021 (UTC)Reply
Spike 'em, correct. I think we can make the edit request.
Please apply the following change to Template:Asbox/styles.css: diffTheDJ (talkcontribs) 12:29, 15 March 2021 (UTC)Reply
To editors TheDJ, Spike 'em, Redrose64 and Mackensen:   done, and thank you all very much! P.I. Ellsworth  ed. put'r there 18:18, 15 March 2021 (UTC)Reply

i18n unfriendly normalization

edit

This line,

		local tsort, cat = args['tempsort' .. v], mw.ustring.gsub(args['category' .. v], '[^%w%p%s]', '')--remove all hidden unicode chars

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 %w, %p and %s 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)Reply

This can be applied to fix this. −ebrahimtalk 19:18, 22 March 2021 (UTC)Reply
The code is there for a very good reason: see Template talk:Asbox/Archive 4#Obscure errors. Any changes must not cause those problems to recur. --Redrose64 🌹 (talk) 21:53, 22 March 2021 (UTC)Reply
Interesting issue. LRM, RLM shouldn't be used at titles of course but ZWNJ is different, running
sql fawiki` with `SELECT COUNT(*) FROM page WHERE page_title LIKE '%‌%' AND page_is_redirect = 0 AND page_namespace = 14;
(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)Reply
  Done @Ebrahim: I've made a similar change to the last-requested one. Izno (talk) 01:43, 5 June 2021 (UTC)Reply
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)Reply
@Ebrahim: Please make it obvious in our 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 invisible_chars) 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)Reply
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=1027068468ebrahimtalk 22:39, 5 June 2021 (UTC)Reply
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)Reply
  Done — Martin (MSGJ · talk) 11:07, 21 June 2021 (UTC)Reply

Sandboxes in main module

edit

MSGJ 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)Reply

Thanks for letting me know, fixed — Martin (MSGJ · talk) 11:37, 21 June 2021 (UTC)Reply

imagealt parameter in Category:Stub message templates needing attention

edit

Is there a particular reason use of the |imagealt= parameter is tracked in Category:Stub message templates needing attention? I am not really understanding what needs to be "fixed", unless the fix is removing the parameter. Best, HouseBlaster (talk • he/they) 01:31, 23 September 2024 (UTC)Reply