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

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

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 (talk • contribs) 12:25, 12 March 2021 (UTC)

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

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)

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)

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

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)

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)

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)

Spike 'em, correct. I think we can make the edit request.

Please apply the following change to Template:Asbox/styles.css: diff —TheDJ (talk • contribs) 12:29, 15 March 2021 (UTC)

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)

i18n unfriendly normalization

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! −ebrahim^talk 19:03, 22 March 2021 (UTC)

This can be applied to fix this. −ebrahim^talk 19:18, 22 March 2021 (UTC)

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)

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. −ebrahim^talk 18:31, 23 March 2021 (UTC)

 Done @Ebrahim: 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 −ebrahim^talk 09:25, 5 June 2021 (UTC)

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

Izno: My bad, sure, I didn't know about how to encode them like that in Lua, thanks for the pointer, https://wiki.riteme.site/?diff=1027068468 −ebrahim^talk 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! −ebrahim^talk 10:00, 11 June 2021 (UTC)

 Done — Martin (MSGJ · talk) 11:07, 21 June 2021 (UTC)

Sandboxes in main module

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)

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

imagealt parameter in Category:Stub message templates needing attention

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)