Talk:Item display transition to CSS

Forums: Index > Help desk > Item display transition to CSS

I've been working on defining css attributes to control the appearance of content on the item pages.

This has the benefit of

• abstracting style from templates ( less clutter in templates )
• allowing for a different appearance for each skin ( vector / trueglass / etc )
• allowing for a user to overwrite certain style elements, should they choose ( more options, yay! )

With a refactored item display template, 9 css attributes can be defined to control appearance. ( Outer table / details table / images table, and their corresponding th and td cells )

My idea is that 9 attributes for each item base category ( armor / clothing / collectable / etc ) would be defined with distinct color patterns.

Since the appearance for item pages is currently static, I think the css definitions should live in mediawiki:common.css first, with the idea of migrating the definitions to vector.css, and trueglass.css ( and other skins ) as new layouts are created. Those could also serve as a reference point for users who wish to have a different look for how they can update their own ( user ) css to override default attributes.

Check out User:Joenuts/common.css for example attributes and Small_Candle for an example page that uses the attributes (although it's not EXACTLY the same, as the Chick skin changes some other appearance features ).

Anyone opposed to adding in these attributes to common.css? (*Note: this will not affect any wiki behaviour other than defining properties for html attributes that USE these classes, which right now are just a couple refactored item display templates. *)

Please let me know thoughts / suggestions.→ Joenuts (Contributions • Message) 17:51, January 16, 2014 (EST)

I am not opposed. Sounds like you know what are you doing. --Cru121 (Contributions • Message) 02:33, January 17, 2014 (EST)

I have no idea what you're talking about, but it seems like you do, so... go ahead? *g*

→ LrdSlvrhnd (Contributions • Message) 12:35, January 21, 2014 (EST)

I'm a tad late, but for the record, I'm certainly in favor of separating content from presentation. Aldyron (Contributions • Message) 09:39, January 28, 2014 (EST)

I'm trying to wrap my head around why you are wanting to make additions to common.css for these changes. Everything you did can be handled as inline styles within the table definition in the template using css shorthand to minimize template clutter. If well organized, it will still maintain good readability/editability (not sure that's really a word!!) without any performance load loss. One thing you should always concern yourself with is stylesheet bloat. Unused/little-used style definitions load on every page regardless if it requires that style or not. With enough definitions added for specific projects, bloat can become quite large over time and degrade page load times as the css parser parses every single class every time. Just food for thought... Now, I'm not opposed by any means, just more curious.

/offTopic on

Oh, and where are my manners... I'm Ague. I'm a well seasoned webdev with a focus on SEO and standards both client and server side. I've done some tinkering around this wiki over the years. If you ever have web programming questions, just ask on my talk page and I'll be more than happy to take a look and/or offer some advice.

/offTopic off→ Ague (Contributions • Message) 16:48, January 28, 2014 (EST)

Sure thing, hopefully I can answer your curiosity.

Style attributes can certainly be injected on the page itself at element level *BUT* you lose the cascading part of the CSS ( more like you get just S ). So if I wanted to define properties for all TD or TH elements for tables of a certain class, that can either be done once in a .css file, or once for each element in the table. 20 TH elements with 5 properties defined like padding-left,right,top,bottom and background along with 20 TD elements with the same properties means 40 locations on the page of "padding-left:10px;padding-right:10px;padding-top: 5px;padding-bottom 5px;background: #FFFFF".

( I should say, that I have not found a way with MediaWiki to define CSS class or id attributes from inside a wiki page, if you know of a way, I'm certainly open to learning. I know you can define style on an element level, or associate an element with a class or id, but not actually putting css definitions on a page. )

And when you wanna change something, you're looking at 20 replaces ( or 40 ) if you do inside the page vs once if defined in css.

Now, another benefit is that the attributes can be overwritten. I believe the priority for attributes for Mediawiki are Common.css -> [Skin].css -> User/Common.css -> User/[Skin].css -> attributes defined on page.

I plan on creating a simple help page which describes how some one may be able to overwrite the attributes that they dont like by creating their own User/[common] or [skin].css page. For example, if the yellow colors do not show up very clear on a users screen, they can edit that class for their profile and change the yellow to a red, or whatever they want.

With the attributes being hard coded on the pages, users lose the flexibility to make those changes.

Sidenote: Transitioning to using css may encourage more experienced designers to step forward and create some different looking themes! → Joenuts (Contributions • Message) 17:45, January 28, 2014 (EST) ┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

• That's not exactly accurate Joe. We employ <css></css> on DDOwiki which allows you to define the classes once at the top of the page (or anywhere really) for the whole page or template. (See this example of how it is used if you are interested. ShoeMaker (Contributions • Message) 17:58, January 28, 2014 (EST)

Yeah, the <css></css> module is definitely a lifesaver for things of this nature. It takes the stylesheet and uses jQuery to inject it into the <head> of the page. Rather ingenious actually. But I would definately look at the UserTabs example Tech mentioned. It does the same thing you are looking to achieve (keeping the css readily editable and it cascades down into everything using the template while maintaining strong flexibility for expansion.

You can also use div's if desired (I know that there is no wiki code for div's as tables are the wiki standard, but that always drove me nuts because div's are the W3C standard) and achieve more optimal results for deploying cross-platform without much need for a separate mobile stylesheet.→ Ague (Contributions • Message) 19:03, January 28, 2014 (EST)

• Very neat, indeed. I wasnt aware that that extension existed, much less was installed here. I'll do some testing in my test environment to find out order of precedence for attributes defined in various locations.

I definitely am a fan of having a clean / lightweight Common.css, but at the end of the day, I believe giving the user more options to be able to customize is important as well. Joenuts (Contributions • Message) 19:07, January 28, 2014 (EST)

I agree with you wholly with having lightweight external stylesheets. Makes for good webdev'ing. :) At the end of the day, the order of precedence is exactly how it is handled by all browsers -> (1) Browser Default, (2) External Stylesheets (the link's in the <head>), (3) Internal Stylesheets (CSS classes and definitions placed in the <head>, (4) Inline Styles. Style definitions farthest to the right will essentially overwrite those declared to the left on the list. User defined common.css gets appended to the MW common.css so user defined styles will also overwrite those in the MW file. Ague (Contributions • Message) 19:27, January 28, 2014 (EST)

• For the record, once I have some free time and everything in RL is more stable and I have internet at home and whatnot, I intend to finish my T:Named Item project. The template actually isn't the only part of that project, but the template part is very similar to what you've started working on Joe. And there is a reason I want to merge all of the various Named foo templates in to one. The other part of it is every page that uses T:Named Item in the Item: namespace will not use the default edit window. I've been mentally developing an interactive form ui to be able to edit item properties which should make it a ton easier for standard non-wiki-code-minded people to edit (and give them less options for making messes out of pages. But, that part of it is still a bit down the road and I have not decided if I want to do it as an on-by-default JavaScript gadget that registered users can turn off (although there will still be a "raw edit" type option on the page) or as an extension which I would need to get Xevo (Contribs • Message • Email) to install which would give me more backend power to manipulate things. Once I've had more time to think about it, and work things out, I'll give some more details and see if the majority like the idea. ShoeMaker (Contributions • Message) 20:02, January 28, 2014 (EST)