Jump to content


Photo
Issue

External link's underline spreading through a space

wiki

  • Please log in to reply
21 replies to this topic

#16 TechAngel85

TechAngel85

    Akatosh

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 12,053 posts

Posted 27 December 2014 - 10:56 PM

Just a gentle reminder that the css extension will be going away when the wiki skin is refreshed. Far too much hacking going on with it.

 

 

There will be things implemented in the skin within reason based on feed back when we get to that point. But yes, we do need consistency within the Wiki, and the css extension is being used for purposes it was not intended for. Sorry, but it's being abused and will continue to be as long as it's available.

Certain styling can still be applied in wiki text, but modifying major elements that isn't supported by MW will be discontinued in the future.

We've had some discussion on this in another thread or PM...can't remember which but it's something that the Staff and Z feels should remain. Yes, it's use should be limited on STEP-based Guides. We all agree with this. Z has already taken care of some of this by improving the default CSS based off some of my personal CSS edits (mainly spacing related) and removing its use on most of the Guides. We've been making an effort to reduce its use on the official STEP content; however, the main reason to keep it is for the non STEP-based Guides that we have around (SR, Fallout:NV, Fallout 3, Oblivion, Mass Effect, etc). These Guide should be not be restricted to the STEP-only "theme" as they're not STEP Guides nor STEP related...not to mention they're well known and are popular.

 

Another reason is, it can be used to supplement an official Guide like its use on the ENBSeries INI Guide. Its use there is to align elements to a specific layout for the compares and the compare text. This would be possible using inline CSS; however, that is very inefficient. Since the code would be repeating 100s of times, it's far more efficient to use the css extension.

 

So there have been legitimate reasons to keep the extension around voiced by Staff.



#17 hishutup

hishutup

    Daedric Prince

  • Super Moderators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 2,584 posts

Posted 27 December 2014 - 11:07 PM

If someone remembers the link, where to look or the pm conversation can you share or add me so I can take a look through it?



#18 phazer11

phazer11

    Chatroom Supervisor

  • Super Moderators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3,287 posts

Posted 27 December 2014 - 11:12 PM

Same.



#19 TechAngel85

TechAngel85

    Akatosh

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 12,053 posts

Posted 27 December 2014 - 11:23 PM

It was in a PM, I added you all.



#20 hishutup

hishutup

    Daedric Prince

  • Super Moderators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 2,584 posts

Posted 27 December 2014 - 11:43 PM

thank you, I kind of don't know what to think.

It appears that this was dropped on to everyone and it also seems that s4n is not going to change him mind.

 

Inline css is definitely not something that I want to deal with...

I did that when my guide was tiny and it was a massive pain and never looked right. 

Then someone mentions the css and all my worries were gone.

I could apply my css to what ever I wanted to and I edit all the pages css by editing hte one page. 

There are several things wrong with the wiki whether it be issues, limitations, compatibility I would have never guessed that the css feature would be removed because it is amazing.

 

I will be open to other options but the css has proven its flexibility WAY beyond expectation.

 

Do any of the other guide writers know about this?



#21 stoppingby4now

stoppingby4now

    Sleepy

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 4,281 posts

Posted 28 December 2014 - 12:05 AM

It was agreed that the CSS extension was not going to be ripped out from under everyone. The underlying agreement was that the skin would be updated to better accommodate as much as possible for what is being used currently, as well as investigate additional functionality that has been requested from time to time.

 

The fact is, we need consistency in presentation, and the CSS extension breaks that. It's use has spread beyond it's intended purpose, which was a stop-gap for the STEP Guide until a skin refresh, which admittedly has been a long time coming. We purposely did not advertise it's use because we did not want it being used for mainstream editing, but that obviously did not last.

 

As to the other guides for other games, the Wiki is a single system and all pages hosted on it will need to conform to its look'n'feel, and the primary purpose is currently for supporting STEP for Skyrim. However, we can certainly look into options for providing separated spaces for other games where they can have their own distinct look'n'feel.

 

This impending change also is not going to be a huge loss in functionality either. Styling can still be applied within the rules of the MW parser. Eliminating the CSS extension will prevent the breaking of display for elements that should not be touched, unless it's a skin level change. Re-use of ANY wiki markup is not a valid excuse either. That's why templates exist to prevent repetitive coding.



#22 z929669

z929669

    Ixian Inventor

  • Administrators
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 9,258 posts

Posted 28 December 2014 - 12:15 AM

EDIT: s4n :ninja: me, so keep in mind the following is based upon posts before his last preceding this post

 

as s4n alluded, we can create optional HTML classes in addition to the defaults. These classes will be 'compatible' with the site but allow a bit of 'customization' within the confines of a defined 'standard'.

 

I do like the CSS extension in today's context, because we currently have not defined any 'final' standards as is apparent by the changes I already made to headings and default text coloring; however, I agree that it is not ideal to have that extension. Better to define a final standard with some options as HTML classes defined in the CSS (I assume anyway ... s4n has more knowledge about implementation options).

 

I definitely agree that we have way too much customization happening throughout the site, and that we are making it way too easy to deviate from any standard with that extension. With the current skin and loose 'standard' we have now, the CSS extension is acceptable, but if we redesign the skin standard 'correctly' and accommodate acceptable deviations, all will be well.

 

My advice is to stop relying too heavily on the CSS extension, as those pages will need to be revised under a different skin that expects the Mediawiki standard CSS ... unless you want to use it to create examples for s4n and me to consider implementing in the available site CSS once the new skin is implemented.

 

It is important that all wiki pages outside of the User namespace have a consistent look/feel, so that users know immediately if they are on a STEP wiki page or just some other wiki page. Additionally, wiki and forums will have a consistent look/feel, rendering wiki-->forum navigation (and vice versa) relatively transparent, unlike it is today. The CSS extension would break that (inline CSS would too, but that is a chore, as it should be ... a deterrent top changing the standard).





Also tagged with one or more of these keywords: issue, wiki

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users