MediaWiki talk:Common.css

Non-existant icons

If we update {{item icon}}, {{skill icon}} and friends, we could use this CSS file to show Skill.png instead when the file doesn't exist, without using #ifexist. The change to the templates would be to add a span around the icon itself, with an appropriate class:

<span class="small thumb-icon">[[File:{{{1|}}}.png|20x20px]]</span>

For templates with the large parameter, it would instead have to be:

<span class="{{#if:{{{large|}}}|medium|small}} thumb-icon">[[File:{{{1|}}}.png|{{#if:{{{large|}}}|35x35px|20x20px}}]]</span>

And the CSS:

span.thumb-icon a.new {
  color: transparent;
  display: inline-block;
  font: 0/0 a;
  overflow: hidden;
  vertical-align: middle;
}

span.thumb-icon.small a.new {
  background-image: url(/images/thumb/7/74/Skill.png/20px-Skill.png);
  height: 20px;
  width: 20px;
}


span.thumb-icon.medium a.new {
  background-image: url(/images/thumb/7/74/Skill.png/35px-Skill.png);
  height: 35px;
  width: 35px;
}

*+html span.thumb-icon a.new { display: inline; } /* IE7 fix */
* html span.thumb-icon a.new { display: inline; } /* IE6 fix */

In my opinion this would be a lot better than the red links, at least in listings. I am no sysop on this wiki however, so I cannot change the CSS. — Rhoot 23:56, 19 June 2012 (UTC)

I still don't understand why everyone here is so scared of redlinks (icon redlinks don't even screw up layouts anymore, since the templates have been updated with a fixed-size div), but if this will solve the problem once-and-for-all so that people stop complaining about it, then so be it. —Dr Ishmael 14:53, 10 July 2012 (UTC)

Ugh, this isn't going to work well for skill icons, because they go through {{borderless}} which allows any value for the size and doesn't use presets (other than default = 96px display (128px file)). —Dr Ishmael 15:09, 10 July 2012 (UTC)

An argument in favor of redlinks

I think redlinks are important because they help contributors (new or veteran) tell when there's a concept/item/image missing from the wiki. I support any move to make missing images look less ugly (e.g. not break an infobox or {{skill icon}}), but I'm against any formatting change that hides the red entirely or even obscures it so it's difficult to see what's missing. – Tennessee Ernie Ford (TEF) 15:37, 10 July 2012 (UTC)

Can you link an example where the redlink is being hidden? (I'm not really sure where this code is being applied, and a specific example will help clarify it.) pling 16:34, 10 July 2012 (UTC)

I don't have a specific example. I just keep seeing people edit to remove redlinks and/or argue that they should be hidden using css. I posted here after seeing this edit with a summary of "auto-hiding redlinks". – Tennessee Ernie Ford (TEF) 16:54, 10 July 2012 (UTC)

It doesn't show up very often anymore, since Risky, I, and others have uploaded nearly all the skill icons, but it's still coded into a lot of templates.

• {{Skill infobox}} / {{Item infobox}} both run #ifexist: on the default icon name, and will show File:Skill.png rather than display a redlink. I can somewhat understand the usage here, since a redlink there would overlay the infobox title. Also, they pass the default filename as the link= parameter to the image, so the link is still available, although it's not obvious.
• {{skill icon}} / {{item icon}} accept a third parameter to show a different icon than the skill/item's default, and this was often given as "Skill" to avoid the redlink completely. These templates make the image link to the article, however, so there's no way to directly upload the missing image. Quicksand shows how this works.

—Dr Ishmael 18:45, 10 July 2012 (UTC)

That Quicksand example really needs to be changed - I had to turn up the screen brightness to see what the icon was actually showing, and as you said it links to the skill article rather than the non-existent file page. If we could create an icon that indicates "upload here" and takes you to the right place to upload it, that would be better. pling 19:32, 10 July 2012 (UTC)

<nods> Yes, that would be better. However, I think we generally want stuff to look broken when we are missing an important image or article; I think it's a mistake to pretty things up. (The wiki might have needed a different idea last July, but at this point in time, we want to show blemishes so they get fixed, not hide them so it looks nice.) – Tennessee Ernie Ford (TEF) 22:09, 10 July 2012 (UTC)

I agree that things should look broken if icons are missing, but does that mean they can't look nice? Since when are the two mutually exclusive? I agree for the most part on red links, and I see their use. I also think redirects such as light armor shouldn't exist just to get rid of red links. Especially when the article itself links back to the redirect. The one time I am in favor of prettifying (not necessarily hiding) red links is in tables. If we can get an icon that suggests the real icon is missing, I'd much prefer that over having it mess up the columns in the table.

My suggested CSS above would still make the icon link to the right page (for uploading the icon). I agree however (and have said before) that Skill.png is pretty crappy as a replacement icon. — Rhoot 23:44, 13 July 2012 (UTC)

If you read the OP, you can see that I support less ugly — when I said "a mistake to pretty things up," I meant making them look so nice we couldn't see the fact that something is missing. I want to stop people from hiding redlinks, which people have done in three ways on this wiki: creating non-useful redirects (noted again by Rhoot), commenting out images, and tidying up infoboxes to the point of removing any reference to the missing image. I'm all in favor of pointing to an icon (that looks nice) and reads: "missing icon" or "oops." – Tennessee Ernie Ford (TEF) 23:55, 13 July 2012 (UTC)

Table formatting; particularly display:inline-block

Anyone else seeing what I see? Firefox 16 is at the top, Internet explorer 9 at the bottom. (my monitor is 1920px by 1080). When I reduce the width by about a third, the table suddenly snaps to align on the left hand side of the page. This is awful for viewing. :/ --Chieftain Alex 17:46, 8 November 2012 (UTC)

Fixed in template:skill list dpl. —Dr Ishmael 18:35, 8 November 2012 (UTC)

Apparently inline block also stops people specifying custom table widths? (it just lengthens the border beneath the table >_> ) (i.e. its almost impossible to choose to display tables with a custom width) --Chieftain Alex 20:28, 16 November 2012 (UTC)

random long string of text to make box hit width

Box-shadow for mainpage

Could someone please remove the line

box-shadow:rgba(0,0,0,0.5) 0 0 .75em;

I inserted this line directly onto the mainpage design a while ago such that the shadow shows up on Internet Explorer 9, but since this line hasn't yet been removed, there is a double shadow on the main page for users of Chrome/Firefox (extra dark!) -Chieftain Alex 16:55, 16 February 2013 (UTC)

Done. —Dr Ishmael 17:16, 16 February 2013 (UTC)

Border rendering bug with rowspan on Firefox

This is how some of our tables render for me on Firefox:

(I set the borders to 10px to make the problem more obvious.) See the border under "Tech tree (Level)"? That shouldn't be there. According to DOM Inspector, it isn't there; that cell has no bottom border. It turns out to be this Firefox bug, which is triggered by using "border-collapse: collapse;" together with rowspan/colspan. Comment 15 there suggests roughly this workaround:

.table > tbody > tr > th { /* Workaround Firefox Bug 322810: */ border: 0px solid; }

which should go before this line in Common.css:

.table > tbody,.table > tbody > tr.heading,.table > tbody > tr > [rowspan],.table > tbody > tr > [colspan] {border:10px solid #aaa}

That workaround fixes the table in Guild mission for me. (I have not, however, checked to see if it breaks any of our other table header styles.) Any chance we could get it into our CSS? —The preceding unsigned comment was added by Dagger (talk • contribs) at 05:55, 8 May 2013 (UTC).

Double forward slash // in the font face urls

https://d1h9a8s8eodvjz.cloudfront.net//fonts/eason/v1/easonpro-italic-webfont.woff

I'm wondering why there are double forward slashes in the font face urls - if you change it to a single slash then it looks to pickup the same font file to my eyes. Any ideas why they are there? (noticed because I just copied the format to my own common.css for another font..) -Chieftain Alex 20:51, 13 February 2014 (UTC)

You'd have to ask Alfa-R, he wrote it all up and Tanetris just copied it over to here (June 2012). —Dr Ishmael 21:04, 13 February 2014 (UTC)

Thanks. Damn all these super formatting wizards going AWOL as soon as gw2 was released. (oh well) -Chieftain Alex 21:08, 13 February 2014 (UTC)

Should have said the first time: You're probably right that it's redundant, but I wouldn't bother changing it on its own. —Dr Ishmael 21:12, 13 February 2014 (UTC)

Explicit URL protocol

I was wondering why some URLs use the full path with protocol (http://wiki.guildwars2.com/images/3/3a/BG_gradient.jpg) versus a relative path (/images/3/3a/BG_gradient.jpg). From my understanding, both URLs mean the same thing (on this domain), and as it is mixed content warnings occur when using https on pages that use affected elements (but not on pages without them). Also, Monobook.css uses relative URLs throughout it. —Cat Slayer Calli 20:04, 2 January 2015 (UTC)

The stylesheets have been added to by many folk over quite a few years.. each with a different style. I don't think there is any reason for the variations other than that, so I've changed them all to use relative urls + wrapped them with quote marks. Thanks for the prompt. -Chieftain Alex 13:27, 3 January 2015 (UTC)

Narrow skill tables with longer-than-table shadows

hmm. A pity its for old browsers. I'm looking at the table on Shatter with firefox/IE10 + the shadow is way longer than the table. It is an unusual case that the descriptions are short enough not to reach 1000px total width. Is there a particular reason why the table isn't just set at "width:1000px" instead of "width:100%; max-width:1000px;"?

IE9 gets a narrower table without the width:100% thing, likewise IE8 (however IE8 can't even do the chatlink generator script). So i guess the "fix" is for IE8 + IE9.

IE7 is seriously broken in many ways, particularly the monobook tabs. Lol IE5. -Chieftain Alex 08:24, 8 July 2015 (UTC)

If you know of a better way to fix IE8+9 or to force the table to full-width on other browsers, go ahead. (Maybe something like what I did in the description header here?) According to some sources, IE8+9 still account for 22% of desktop users. —Dr Ishmael 12:38, 8 July 2015 (UTC)

Revenant

With the new profession, Revenant, the Common.css is missing some lines, starting by "/* STDT table classes */" the missing lines are:

/* revenant */
  .table.revenant > :first-child > tr:first-child,
  .table.revenant > tbody > tr.heading,
  .table.revenant > :first-child > tr:first-child > *,
  .table.revenant > tbody > tr.heading > * {
    background-color:#D16E5A !important;
    border-color:#A65747 !important;
  }
  .table.revenant > tbody > tr > th,
  table.table > tbody > tr.revenant > th {
    background-color:#E4A598;
    border-color:#BFA8A0;
  }
  .table.revenant > tbody > tr:nth-child(odd),
  .table > tbody > tr.revenant:nth-child(odd) {
    background-color:#F6ECE9;
  }

By "/* Remove after shadow for tables that have been centered, otherwise the shadow spans the entire page */" the missing lines are:

div.infobox.revenant dd,
div.infobox.revenant dt { border-color:#610!important; }

div.infobox.revenant .heading,
div.infobox.revenant .subheading { background-color:#610!important; }

and futher below:

div.nav.revenant .heading,
div.nav.revenant .subheading { background-color:#CC6342; }

div.nav.revenant dd,
div.nav.revenant dt,
div.nav.revenant table th { border-color:#CC6342; }

All the colors are based on Guild Wars 2 Wiki:Color schemes

Thank You! —The preceding unsigned comment was added by Keltz (talk • contribs) at 06:12, 13 August 2015‎ (UTC).

Hi Keltz. I'm aware that the proposed revenant color scheme isn't implemented in the common.css. It isn't there because although I proposed those colors on Guild Wars 2 Wiki:Color schemes, the only feedback I got indicated that they thought it was too close to the thief/engineer colours. -Chieftain Alex 08:34, 13 August 2015 (UTC)

It's been beaten into me that I have a limited eye for colour palettes, so I'll say that the only minor issue I see on Guild Wars 2 Wiki:Color schemes is the navigator colours being too close. Even then, they're probably miles apart. G R E E N E R 08:51, 13 August 2015 (UTC)

You have to bear in mind with this page that the colors shown for infobox + nav headers are different to how it finally appears, because you get a great big semi-transparent overlay gradient on top too. -Chieftain Alex 09:34, 13 August 2015 (UTC)

Thanks Chieftain, I suspected that you guys were aware, but seeing all professions with pretty templates, I was sad to realise that Revenant didn't have a colored one. Besides I think those colors fit pretty well, but yeah, I'm just one member of the community, sorry. By the way, I would have replied sooner, but I probably unwatched this page or something. Thanks Keltz (talk) 02:59, 27 August 2015 (UTC)

No problem + thanks for raising the issue before HoT was released ^^ -Chieftain Alex 07:08, 27 August 2015 (UTC)

Request for horizontal lists

May we have styles for horizontal lists, so that we don't have to use manual bullets and linebreaks? https://www.mediawiki.org/wiki/Snippets/Horizontal_lists. --BryghtShadow (talk) 14:57, 28 October 2015 (UTC)

That page doesn't have any examples. What does it do, and where would this be used? —Dr Ishmael 15:20, 28 October 2015 (UTC)

Allows lists (ul, ol, dl) to be displayed as horizontal lists (w:WP:HLIST). The CSS handles linebreaks and bullets. It would be used where we do manual horizontal lists, namely navboxes (e.g. Template:Achievement nav). So rather than:

[[Shadow of the Mad King (achievements)|Shadow of the Mad King]]{{bullet}}[[The Wondrous Workshop of Toymaker Tixx]]{{bullet}}[[Super Adventure Box (achievements)|Super Adventure Box]]{{bullet}}[[Bazaar of the Four Winds (achievements)|Bazaar of the Four Winds]]{{bullet}}[[The Queen's Gauntlet]]{{bullet}}[[Super Adventure Box: Back to School (achievements)|Super Adventure Box: Back to School]]{{bullet}}[[Super Adventure Box: Tribulation Mode|Super Adventure Box: Tribulation Mode]]{{bullet}}[[Boss Week]]{{bullet}}[[Blood and Madness (2013 achievements)|Blood and Madness (2013)]]{{bullet}}[[A Very Merry Wintersday (2013 achievements)|A Very Merry Wintersday (2013)]]{{bullet}}[[Festival of the Four Winds (achievements)|Festival of the Four Winds]]{{bullet}}[[Blood and Madness (2014 achievements)|Blood and Madness (2014)]]{{bullet}}[[A Very Merry Wintersday (2014 achievements)|A Very Merry Wintersday (2014)]]

we'd do:

{| class="hlist"
|
* [[Shadow of the Mad King (achievements)|Shadow of the Mad King]]
* [[The Wondrous Workshop of Toymaker Tixx]]
* [[Super Adventure Box (achievements)|Super Adventure Box]]
* [[Bazaar of the Four Winds (achievements)|Bazaar of the Four Winds]]
* [[The Queen's Gauntlet]]
* [[Super Adventure Box: Back to School (achievements)|Super Adventure Box: Back to School]]
* [[Super Adventure Box: Tribulation Mode|Super Adventure Box: Tribulation Mode]]
* [[Boss Week]]
* [[Blood and Madness (2013 achievements)|Blood and Madness (2013)]]
* [[A Very Merry Wintersday (2013 achievements)|A Very Merry Wintersday (2013)]]
* [[Festival of the Four Winds (achievements)|Festival of the Four Winds]]
* [[Blood and Madness (2014 achievements)|Blood and Madness (2014)]]
* [[A Very Merry Wintersday (2014 achievements)|A Very Merry Wintersday (2014)]]
|}

Here's a sample navbox: User:BryghtShadow/sandbox/hlist, and after styles added: http://i.imgur.com/W2TwPiI.png --BryghtShadow (talk) 13:53, 30 October 2015 (UTC)

Ah, it makes sense now. Yes, that looks like an extremely useful bit of code. CSS and JS snippets have been added. —Dr Ishmael 14:39, 30 October 2015 (UTC)

I went ahead and converted the achievement nav. Quite nifty. —Dr Ishmael 14:46, 30 October 2015 (UTC)

It seems we'll have to convert all navboxes to tables. Definition lists (a la Template:Graphical user interface nav) don't work with this. —Dr Ishmael 14:51, 30 October 2015 (UTC)

CSS to produce html bullets? The source is neater sure, but do we use long lists separated by {{bullet}}s enough to bother converting all the navs? -Chieftain Alex 15:44, 30 October 2015 (UTC)

@Ishmael To convert to hlist while retaining the definition list boxes, HTML can be used instead of wikitext.

;Permanent elements
:[[Skill bar]] • <!-- foo --> • [[Party|Party interface]]
;Temporary windows and panels
:[[Game menu]] • <!-- foo --> • [[Hints]]

becomes:

<dl>
<dt>Permanent elements</dt>
<dd class="hlist">
* [[Skill bar]]
* <!- foo -->
* [[Party|Party interface]]
</dd>
<dt>Temporary windows and panels</dt>
<dd class="hlist">
* [[Game menu]]
* <!-- foo -->
* [[Hints]]
</dd>
</dl>

--BryghtShadow (talk) 16:25, 31 October 2015 (UTC)

That still requires a fairly significant conversion, and it's better practice to avoid raw HTML (aside from div/span), so we may as well convert them to tables. —Dr Ishmael 17:13, 31 October 2015 (UTC)

visible extended shadow for skills table

On Monobook and Vector, the table shadow is extruding beyond the table. See screenshot. --BryghtShadow (talk) 07:23, 7 April 2016 (UTC)

The objective of

.table.skills {
    width: 100%;
    max-width: 1000px;
}

was evidently to try and get the skill tables to the same minimum width independent of the length of the descriptions/other columns. What actually happens is that the shadow inherits the width but not the table (doesn't matter if the shadow is there or not, the table still doesn't display at the right width). We could remove "display:inline-block" from all .table styles, or we could just override it on every invocation with "display:table". Is there another way we can do this, and still have a shadow beneath the table, without causing the shadow bug? -Chieftain Alex 17:23, 7 April 2016 (UTC)

collapsible-toggle has unnecessary margin-left

I noticed from Template:Skill types nav that .collapsible-toggle has an unnecessary margin-left: 0.5em that makes the spacing look awkward. ~ Fishrock ^(talk) 21:05, 2 September 2017 (UTC)

I'd suggest that in most cases you don't want the toggle to look like part of the text. originally it was a 1em margin... -Chieftain Alex 21:29, 2 September 2017 (UTC)

Perhaps, but it would probably still look better. Wikipedia itself has these as a part of the nav bar, so maybe I'll try to scrounge up the CSS to fix ours soon(tm). Perhaps we could go halfway for now, fixing the whitespace and only linking the "show"/"hide" text and not the square brackets. ~ Fishrock ^(talk) 21:34, 2 September 2017 (UTC)

div.nav px width

Please convert the px values to em values. I'm using a larger font size and nav tables having a fixed px width causes text to wrap onto a new line. --BuffsEverywhere (talk) 02:13, 16 February 2019 (UTC)

div.nav {
  width:500px; --> 38.5em;
}
div.nav .box {
  margin:5px; --> 0.25em;
}
div.nav dt {
  width:125px; --> 10.5em;
}
div.nav dd {
  width:325px; --> 27.5em
}

div.nav.thin .box {
  width:400px; --> 33.5em
  margin-left:50px; --> 4em
}
div.nav.thin dt {
  width:75px; --> 6em
}
div.nav.thin dd {
  width:290px; --> 24.5em
}

div.nav.wide .box {
  width:600px; --> 50em
  margin-left:-50px; --> -4em
}
div.nav.wide dt {
  width:150px; --> 13em
}
div.nav.wide dd {
  width:400px; --> 33.5em
}

Give me a hand by converting the numbers and I'll update it. -Chieftain Alex 21:05, 16 February 2019 (UTC)

I think it's simply dividing everything by 12? Not sure why your first two numbers are off or why you rounded some numbers. --BuffsEverywhere (talk) 22:21, 16 February 2019 (UTC)

http://pxtoem.com/ --Tolkyria (talk) 22:31, 16 February 2019 (UTC)

Thank you for making the adjustments Alex. Looks good. Can you update div.infobox as well? -BuffsEverywhere (talk) 13:06, 17 February 2019 (UTC)

.patchnote line-height adding too much vertical whitespace

Current styles

.patchnote { line-height: 2.7em; }

The current style is causing issues for long lines that follow an icon:

• Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
• 
  Lorem ipsum dolor sit amet.
• 
  Lorem ipsum dolor sit amet.
• 
  Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
• 
  Lorem ipsum dolor sit amet.
• 
  Lorem ipsum dolor sit amet.
• Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Proposed styles

.patchnote .icon, .patchnote .skillicon, .patchnote .traiticon { line-height: 2.7em; }

If we apply the line-height to just the icon wrapper:

• Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
• 
  Lorem ipsum dolor sit amet.
• 
  Lorem ipsum dolor sit amet.
• 
  Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
• 
  Lorem ipsum dolor sit amet.
• 
  Lorem ipsum dolor sit amet.
• Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

--BryghtShadow (talk) 04:31, 4 May 2019 (UTC)

.table.skills

Current

.table.skills { width:100%; max-width:1000px; display:table; }

Proposed change

.table.skills { width:100%; max-width:100em; display:table; }

Reason

Over the years the skill tables (concept created in 2012) lost its shape because additional columns (e.g. "Energy" column) have been added, columns have been removed (e.g. "Type" column isn't needed anymore, because the description states it as intro) and the numerical columns doesn't align properly anymore. However, the concept have not been adjusted to this changes. Therefore, I intend to redesign it, with a width of 100em, based on the concept of 2012. See also: here --Tolkyria (talk) 18:59, 22 August 2019 (UTC)

Right align edit buttons

Following on from legacy convention, we have a line which reads .mw-editsection { float:right; } in our common.css. The reason that mediawiki changed the norm to be left floating (see gw1:Template talk:Quest icon as an example) is that they figured out people were more likely to edit the section with the section edit buttons beside the headings.

Any significant objections to removing this CSS line to let it float to the left? -Chieftain Alex 08:57, 22 April 2020 (UTC)

If it increases the likeliness of wiki edits, then sure, go for it.

The only exception I can think of are tables, there it looks disturbing for me, e.g. Food, Greatsword, Shout. Maybe we could still use .table .mw-editsection { float:right; }.

Compare it with collapsible sections vs collapsible tables: While the right aligned show button for collapsible sections sometimes totally looks out of place and nobody can find it that far right (e.g. Superior Rune of the Air using {{collapsible section}}... I know that's an extrem example), it's totally fine (actually, it's the best place) for tables to have the show/hide button on the top right corner. --Tolkyria (talk) 15:45, 22 April 2020 (UTC)

Forgot that we would need to apply

h1 .mw-editsection, h2 .mw-editsection {
  line-height: 1.2em;
}
h3 .mw-editsection, h5 .mw-editsection {
  line-height: 1.15em;
}
h4 .mw-editsection {
  line-height: 1.1em;
}
h6 .mw-editsection {
  line-height: 1em;
}

to correct the line height for the [edit] buttons due to our css applied to each heading. Agreed sections within tables are "probably" ok if right-aligned, but honestly I don't think it looks that bad. -Chieftain Alex 16:04, 22 April 2020 (UTC)

I'm in favour of moving the [edit] to right next to the heading. I also think having collapsible toggles right next to their text could be beneficial as well since they should be more likely to be spotted there and so things can't be missed as easily as i'd imagine exact locations on Class I Magic Rift might be for example. I do agree that right aligned collapsible toggles in tables look weird when not in the corner though; whereas i wouldn't mind [edit] buttons being next to the text and not on the side for sections inside of tables (which do look a bit weird to me but i assume that's because i don't expect tables to be split by sections in the first place so it looks slightly out of place either way) though. Nightsky (talk) 03:45, 4 July 2020 (UTC)

I've moved them to the left. Let's see our edit numbers double overnight.

And jesus that Magic Rift page was terrible... I've limited the size of the div to 30em. -Chieftain Alex 10:09, 4 July 2020 (UTC)