Final Fantasy Wiki
Register
Line 165: Line 165:
   
 
:The goal is removal of bloat, load times do not matter since everything is cached anyway. Link css right now is a bloated mess, not even sure how much turning a lot of it into variables will fix the problem. Either way while it makes sense to keep visited links, as that is good web design, there's no way we need external link colors, the icon depicts if a link is truly external ([https://www.google.com/ like so]) and it doesn't matter if other wikis have a slightly different color shade, very few readers will really care.--{{User:Technobliterator/Talk}} 23:12, June 28, 2018 (UTC)
 
:The goal is removal of bloat, load times do not matter since everything is cached anyway. Link css right now is a bloated mess, not even sure how much turning a lot of it into variables will fix the problem. Either way while it makes sense to keep visited links, as that is good web design, there's no way we need external link colors, the icon depicts if a link is truly external ([https://www.google.com/ like so]) and it doesn't matter if other wikis have a slightly different color shade, very few readers will really care.--{{User:Technobliterator/Talk}} 23:12, June 28, 2018 (UTC)
  +
::I don't see what "removal of bloat" accomplishes. Nobody cares how long the CSS is except us. [[User:Catuse167|Cat]] ([[User talk:Catuse167|meow]] ∙ [[Special:Contributions/Catuse167|hunt]]) 23:25, June 28, 2018 (UTC)

Revision as of 23:25, 28 June 2018

Request addition

I'd like to request the following code (encloded in PRE tags) be added to the CSS:

.noLinkColors a, 
#bodyContent .noLinkColors a.external,
#bodyContent .noLinkColors a.extiw {
    color: inherit;
}

Function: all links enclosed within any element that has class="noLinkColors" will use its regular text colors instead of the various blue. Such behavior is currently used in the user talk text bubbles top portion via hard-coded HTML, and can be greatly simplified via this CSS class. As I want to develop a customized text bubble template as well, having this CSS class would greatly simplify my task too. -PanSola 07:06, 18 January 2008 (UTC)

CSM
V Ninjas
V Hunters
V W Mages
V Bl Mages
CSM
V Trainer
V Thieves
V Trainer
V Hunters

Add

I don't actually know if this code will work. Bluer would know but he's not here. Add this:

body.page-Mix_X_Magic_Glitch .subpages { display: none; }

And if after at least a day Mix/X-Magic Glitch still displays as a subpage, then I'll think of something else. 'kay?  ILHI 15:01, 21 April 2009 (UTC)

Watchlist colours

So... is the addition of the 4HoL styles the cause of the loss of the red/green for showing changes on watchlists? If so, does anyone know how to fix it? I miss my colours T_T Black's bland and unhelpful; I prefer being able to see if an edit is + or – at a glance -- Sorceror Nobody 21:46, June 28, 2010 (UTC)

EDIT: I got distracted while writing this, and by the time I came back and clicked "Save" the colours were back. Yay! -- SN

seriesb

Can somebody please tell me the use of having a class for .seriesb{ color: black; background: white } ?

I can't see the traditional series' logo ever changing. It's like expecting Coke to go green. (No pun whatsoever intended) - Henryacores^ 19:26, April 18, 2012 (UTC)

This is why.

Seriesa
Seriesb
No class

Also, if we decided to use a class system for navigation, we could get the class would also add a px border when used in one. We don't do that, but we should do that. JBed 19:36, April 18, 2012 (UTC)

"table.board" class

I have just added the table.board class. It will be used for {{Dissidia Map}} and similar so the grey tiles are default, and other general formatting is done automatically. JBed (talk) 00:29, January 1, 2013 (UTC)

"table.table" changes

I just forced tables with the "table" class to have a white background and black text. This means that if someone changes the colour of the text or the background of a page, the tables won't change too.

Added link colours

I just added link colours to all the black colours. Which seems redundant however the Halloween redesign did not respond well to us changing the colours. Now if we change the wiki's link colours those in the classes will remain the same.

I also added an "SL" new:visited link. It means if you click a red link the colour will change to show you've been there, previously there was no notable difference. I've also forced Oasis to do the same under normal conditions because I noticed it wasn't. JBed (talk) 23:27, January 3, 2013 (UTC)

I later added a link colour for normal visited redlinks within articles because Oasis didn't use them by default. JBed (talk) 17:17, January 8, 2013 (UTC)

Stupid question: if all these changes just fix Oasis (and I support them by the way) why aren't they being added to MediaWiki:wikia.css instead? C A T U S E 01:19, January 9, 2013 (UTC)
I understand your concern, and it would make sense and apply in exactly the same way. However my justification is:
  1. If they change monobook (though they said they wouldn't) to some of the Oasis things then it would fix it already.
  2. Because it is a style we want applied across the entire site, even if it is already applied to monobook. If we want to change the dead-link colour we would change it here for the entire site.
  3. As sort of explained above, easier to manage with having all CSS here.
But probably my main reason is that I see Oasis's CSS as Wikia's CSS. And everything in Common is FFWiki's CSS, and everything in the other two are just tweaks. I If want to apply something to both skins, even if it's already there in Oasis, since it's classes we want all across FFWiki I think it makes more sense to be here.
Although I've just realised the .WikiaArticle class is used which is Oasis exclusive unless something has changed. I'll investigate what removing that class does when I get around to analysing and recording WikiaCSS.
tl;dr: Personal preference. 79.69.199.77 15:58, January 9, 2013 (UTC)
Ah, okay.
Anyhow, from what I've noticed, .Wikia classes are usually Oasis-only or affect things MediaWiki did not create, like blogspace. Which I guess makes sense -- Monobook (and Vector, though Wikia did not bring along Vector when they updated to 1.19 despite it being superior to Monobook in quite a few ways <_>) is mostly just raw MediaWiki stuff, not all that much customization needed. C A T U S E 04:51, January 10, 2013 (UTC)

"table.nav" class

I added a "nav" class for tables. See the coding for {{navbox FFX}} for how it works. Essentially it makes it much easier for people to write nav templates without needing to copy and paste styles, just remember to use the class "collapsible collapsed nav", and margin-left:55px on the title div. I could have also put that in CSS. Maybe I will. JBed (talk) 15:36, January 4, 2013 (UTC)

"a.newcategory" color

I just added a colour property to "a.newcategory" which makes it bad-link red. Oasis at least was showing them as fine-link blue. That's not helpful. For an example of this working, go to Special:Wantedcategories, pick a category and pick a page that uses it. JBed (talk) 16:30, January 7, 2013 (UTC)

Brigadea -> FFABa

I moved the Brigadea and Brigadeb class over to FFABa and FFABb. I left the previous classes intact on a temporary basis.

You can tell which class in in use by a little circle that will appear.

Of course, it's much harder to tell on the "b" classes. But I imagine they'd always be changed at the same time as the "a" classes so it's not that important. JBed (talk) 15:09, January 15, 2013 (UTC)

a.external colour

I added a line that makes the external link colour #3366BB, a lighter blue than the normal link colour. This occurs normally in monobook, but not in Oasis. So now it's in Oasis. JBed (talk) 01:00, January 27, 2013 (UTC)

.archive and related

I added classes for archive-style things. You can see an example on Talk:Mom Bomb (Final Fantasy XII). Wrap a discussion in a div with the class "archive" to get the red outline. To get the header, inside that div and at the top you would put another div with the class "header". if you just wanted the header, then you would do class="archive header" in one div above the text. JBed (talk) 18:27, April 2, 2013 (UTC)

Versus XIII to FFXV Class Code Change

Could someone please change the class codes of Versus XIII to those of Final Fantasy XV as it was rebranded.—Kaimi (999,999 CP/5 TP) 13:02, June 11, 2013 (UTC)

Yes, Kaimi, we know why. We should get new colours for them first, to match the new logo. -- Some Color Mage ~ (Talk) 13:09, June 11, 2013 (UTC)

IE

FUCK YOUUU JBed (talk) 16:50, June 24, 2014 (UTC)

...and this is why, god knows how many years after IE6, IE is still the worst browser. How bad does it look? C A T U S E 18:26, June 24, 2014 (UTC)
Well I fixed an IE issue that stopped the JS loading, but now we've got the overlapping logo issue.
It doesn't load any of Wikia.css, and it doesn't load some of the end parts of Common.css. That stuffs mainly related to navs and link colours. Wikia concatenates Common and (Monobook/Wikia) CSS and JS files to reduce loading times and HTTP requests. Which is pretty cool... but IE9.
I'm gonna make a "fix" now. If IE lt 10 import Wikia.css. That fixes that portion of the issue. Keeping all the rel and ser classes separate because IE9 is dumb feels dumb, but that seems like the easiest option. It might be easier to handle nav bgs and tnav link colours on load in JS rather than in CSS to save on selectors??? JBed (talk) 18:30, June 24, 2014 (UTC)
Yeah. Could also use the opportunity to clean up some of the code. For example: we no longer really need the April Fools' logo and that could be commented out, and since Jeandeve seems to have given up on trolling Fae, we can get rid of the display:none on her masthead. C A T U S E 18:43, June 24, 2014 (UTC)
Well, Wikia.css isn't the problem, Common.css is too big that Wikia.css/monobook.css doesn't even get a chance to load.
Owait, I just realised that I can't get IE10 because this computer is Vista, not 7. That's why I stopped caring about IE9! This computer's using too old of an OS. People still using Vista should switch to another browser.
Welp, I don't care to make any other fixes. If I were to make another change it would be to tell IE lt 10 W7 users to update their browser, and Vista/XP users to switch browsers. 2.102.228.249 19:03, June 24, 2014 (UTC)

Old table.navbox code

Remove since we use the metatemplate now?--Magicite-ffvi-ios Technobliterator TC 11:34, October 18, 2014 (UTC)

An Edge case: CSS list-style

With the rule written for ol and ul as list-style: outside none decimal and list-style: outside none square, Edge presents an edge-case where it fills in the wrong values for the rules it's shorthand for (namely list-style-type, list-style-position, and list-style-image. This causes it to generate the rule list-style-type: none and hide all bullet points and numbered lists' numbers on every page.

I ask that you switch these to list-style: outside decimal none and list-style: outside square none to fix this for Edge users. Thanks. Ribose5 (talk) 21:36, May 22, 2017 (UTC)

Tooltips unsee

The css for {{Foot}} in .tooltip-contents need to put white color for text as default style. I can change it in the Template itself, but I rather put it in css to avoid any dispute changes. Because some changes due to FFXV, the style become obsolete for some template such as {{Foot}}. The user will see black text inside the hover box when hovered a certain text like this (See what I mean...). If no changes in a week, I will change the style in the Template itself. SNN95Talk or Bincang? 13:29, May 30, 2017 (UTC)

A (B)

I don't see black text. Even in the example above where the container sets the text to black. JBed (talk) 19:20, May 30, 2017 (UTC)

Here how it look in my computer screen (in the black box).
Tooltips unsee

Refer for discussion foot templat {{foot}}

SNN95Talk or Bincang? 12:00, June 3, 2017 (UTC)
Okay, that is strange. Now that's what I see! And we did just have a skin change but I decided to investgiate the structure and I don't know why that would have changed anything (or even why it was ever showing light text for me).
Amended CSS. Hopefully things are fixed. JBed (talk) 15:13, June 4, 2017 (UTC)

Cleaning up the CSS

Just giving a head's up about some edits I will be making to the CSS in the coming week(s?). Basically, our CSS has become a mess, with unreadable bloat added everywhere, most of which I am responsible for, as over the years I (and others) have just been adding to it and been inconsistent about placing classes everywhere. Therefore, I will be doing a major cleanup of the CSS, that for the most part, should not affect the site's appearance a whole lot, but may have a slight impact on page loads. The changes that will be made:

  • Using more consistent, smaller, simpler, commenting. Basically having bloated comments doesn't look good and increases the file size unnecessarily.
  • Using CSS variables to store lots of colors that remain the same throughout. This way, we can change just the variable to affect multiple elements at once.
  • Grouping some classes together.
  • May possibly rename some classes if the old name makes sense. For one thing, thinking of renaming table.table to table.article-table for readability, will require a huge bot job in mainspace/talk pages/templatespace/template talk (maybe userspace too?).
  • Obviously removing everything Monobook related.

Things I am considering (will check in Chrome Dev Tools before this though):

  • Consistency, none of this "all styling in one line" stuff.
  • Removing custom link handling and just using ThemeDesigner?
  • Removing a lot of the custom formatting that doesn't seem to make a huge deal? i.e. custom thumb display seems unnecessary now, same with most things in "general fixes and formatting" that aren't templates.
  • Prioritizing larger, more visible templates over smaller ones.
  • Removing anything that seems to be for a deleted/replaced template (duh).
  • Looking at sideicon css (I know that right now they're broken, but ideally I'd like all sideicons to use only one template at the top of a page instead of lots throughout).
  • Moving dialog box to another import, or somehow to Releases.css?

If anyone notices any appearance bugs, apologies, these may be a result of the above changes!--Magicite-ffvi-ios Technobliterator TC 12:33, June 27, 2018 (UTC)

I don't think readability on the CSS page is a good reason to change table to "article-table". I'm sure you can think of other reasons, I just don't think that's a strong one.
Definitely against just using ThemeDesigner for links because they don't use :visited colours. :visited rocks. JBed (talk) 19:21, June 27, 2018 (UTC)
.article-table is a whitelisted class, meaning it is considered/parsed as portable and recognized as such, which helps the mobile skin a lot, plus there's no confusion as to what it does when it's given that name. It's also the class that the majority of other wikis use, so anyone coming here to edit from another wiki will be familiar.
Totally forgot about visited links, it's probably worth keeping our link CSS then, even if it is huge.--Magicite-ffvi-ios Technobliterator TC 22:38, June 27, 2018 (UTC)
Those are very compelling reasons to switch to article-table. I support. JBed (talk) 22:57, June 27, 2018 (UTC)
Is there a list of whitelisted classes? It seems like it might be worthwhile to switch to them across the board now, so long as they don't run the risk of overriding our styles on PC. In particular, doing them all in one batch saves a good amount of bot work. Cat (meowhunt) 00:34, June 28, 2018 (UTC)
The following classes are whitelisted for portability:
  • article-table/WikiaTable/wikitable for tables
  • sortable/mw-collapsible/mw-collapsed for other table related things
However, just to be clear, this applies only to tables, and whitelisted classes with regards to any other template is not something we should worry about. When those templates are classified correctly, they will display correctly on mobile regardless, so there's no point fretting over the portability parser for them. There are classes like collapsibletr and scrollable for functions that sadly will probably never be portable, but it's acceptable because those tables still display fine on mobile without them. Therefore, aside from article-table, I don't think we should worry too much. There are two possible ways we can play around the parser further though:
  1. Obviously, our codename classes (FFVII etc) are not whitelisted, and probably won't be. However, pi-theme-FFVII, and anything beginning with pi-theme-, is. We could probably speed up MediaWiki:Releases.css if we changed it, however I don't think it should be a high priority, given how tables will display fine on mobile anyway.
  2. Now there's one thing with regards to flexboxes in divs which use the multicolumn class. The reason I chagned this to use the {{multicol-begin}} templates is so we could change this in some cases. multicolumn obviously isn't parsed as portable, but we can trick the parser with data-layout="multicolumn" as is done with our infoboxes right now if we want to.--Magicite-ffvi-ios Technobliterator TC 01:01, June 28, 2018 (UTC)

I don't know what you think you're gaining from removing external link colours and .new:visited colours. I hope it isn't load times. JBed (talk) 22:31, June 28, 2018 (UTC)

The goal is removal of bloat, load times do not matter since everything is cached anyway. Link css right now is a bloated mess, not even sure how much turning a lot of it into variables will fix the problem. Either way while it makes sense to keep visited links, as that is good web design, there's no way we need external link colors, the icon depicts if a link is truly external (like so) and it doesn't matter if other wikis have a slightly different color shade, very few readers will really care.--Magicite-ffvi-ios Technobliterator TC 23:12, June 28, 2018 (UTC)
I don't see what "removal of bloat" accomplishes. Nobody cares how long the CSS is except us. Cat (meowhunt) 23:25, June 28, 2018 (UTC)