Not signed in (Sign In or Register)

Discussion Tag Cloud

Vanilla 1.2.1 is a product of Lussumo. More Information: Documentation, Community Support.

    •  
      CommentAuthorMicah
    • CommentTimeJul 10th 2012
     

    This is a place to discuss any thoughts related to the Custom CSS / Campaign Theming that we’re working on. In a nutshell, we’re exploring the option of allowing people to define their own campaign-wide CSS rules. We’ve got a working prototype, but we’d like some more feedback before releasing it to everyone.

    If you’re not part of the beta, don’t worry, we’ll be releasing it soon enough.

    If you are part of the beta (or have ideas), think about these questions:

    • Are there any malicious CSS tricks we need to be especially aware of? We do some sanitizing and sanity checks, but CSS hackery is not something I’m terribly familiar with.
    • What changes to the markup are necessary to support maximum flexibility in theming? We’re happy to add extra divs, spans, classes, ids, etc, etc. If there’s a particular CMS out there that does a good job with this, please point us.
    • How can we roll this out (new markup, specifically) without destroying existing campaign theming? Do we need to support both the old and new markup styles? That would be a real pain on our end, but I can understand if it’s necessary.
    • Is there anything else we should be considering at the same time? What am I missing?

    Thanks again for all your help!

  1.  
    I’m not sure on the limitations of the flexibility of control you have over parsing the CSS before outputting, but one thing I would suggest is to limit the value of the z-index to 1 thru[specified value]. Then force a global z-index value with a value greater than that specified value to be loaded after the custom CSS output. This would be to keep the OP header bar, and login component at the top-most layer always. This will prevent anyone from creating any sort of misleading “false logins” or hiding the Obsidian Portal branding. Should probably also do the same for footer/copyright information as well.
  2.  
    ^^ Not sure that came across clear. For instance, by limiting the value of custom z-index to 9999, and then forcing a z-index value of 10000 to the OP header, login box, and footer, you would assure that they are always on top of any custom elements created.
    •  
      CommentAuthorLangy
    • CommentTimeJul 10th 2012
     

    Oh hell yes.

    HTGN’s got a good point about having a maximum z-index, but you should also allow negative z-indexes (they’re used to create the custom backgrounds that we use).

    I honestly can’t think of any reason you’d need new markup; I’ve already utilized a custom CSS style for one of my campaigns (overriding the site’s CSS using a Firefox plugin to make some of the default colors a bit darker, fitting in with the rest of the page better). I can’t see any reason you’d need anything new for the markup, though – just a place to input the campaign’s CSS style rules.

    It’s great to hear about new OP functionality like this!

    •  
      CommentAuthorKallak
    • CommentTimeJul 10th 2012
     

    Did some minor experimentation with the custom CSS last night, mostly just copy/paste code from sites see what all properties and such worked. Things that I noted:

    -Easy capability to change core OP elements (wiki item/character slug color, main-column background color, etc..) is monumentally kickass!
    -Style elements associated via class (ie, .classname) worked fine, however, style elements associated via id (ie, #idname) did not work.
    -Sometimes elements being altered by style would appear unchanged in preview mode, but then changed once the page was saved. Other times not. More testing needed.
    -Content property (requiring pseudo element :before or :after) does not appear to work.

    First impressions: Very cool. The capability to make quick site wide changes is awesome, not to mention “hiding” all the styling in the custom CSS makes the page source easier to read for less net savvy players who would still like to make alterations to pages or additions. Campaigns that are “properly” coded with full CSS implementation in mind (start planning now!) can easily be given an entirely new look from the custom CSS area alone. The concept is a huge leap forward for OP.

    That said (and granted this isn’t really CSS related per se, but still worth mentioning), I believe people with custom top or side navigation setups (like me) will still desire some sort of “include” feature to get blocks of code onto every page – as CSS isn’t really setup to handle this (particuarly with the Content property not working) – but based on what I’m seeing with the custom CSS, such a feature could likely be put into place via a similar format.

    More to come as I keep experimenting with it.

    •  
      CommentAuthorMicah
    • CommentTimeJul 10th 2012
     

    Includes and other templating will have to wait. I’d like to be able to support it, but it’s just out of scope at this point and much harder to define than allowing CSS. I’d really rather not try and build a templating engine, although we may have to do something like that at some point

    The z-index points about branding and positioning false links is something I’ll have to think about. Catching and sanitizing that kind of thing would require a CSS parser and then some rules to check. That may be doable, but parser writing is up there with templating in my list of things I don’t want to do.

    Keep the ideas coming…

    •  
      CommentAuthorKallak
    • CommentTimeJul 10th 2012
     

    Another sidenote, CSS rollover test = successful.

    rollover test page

    •  
      CommentAuthorLangy
    • CommentTimeJul 10th 2012
     

    To be honest, the z-index bit is something that someone could mess with even without CSS. CSS only makes it easier, rather than anything else.

  3.  
    ^ Technically, that's correct. z-index can be modified with Inline CSS via the style property of elements even without this upgrade. But I'm assuming any sort of parsing would be done at the pre-output level, and not to the individual data field, thus would solve the issue for both inline and "style sheet" css.
  4.  
    Technically a lot can be done without utilizing the z-index. If it came down to having to loose the flexibility of CSS overall (especially the new global CSS "style sheet"), I would rather loose access to the z-index all together. That would greatly simplify any parsing routine if push comes to shove.
  5.  
    Technically, I use the word "technically" a lot.
  6.  

    yes…but that’s just a technicality…technically speaking.

    dlaporte
    violent skies

    •  
      CommentAuthorLangy
    • CommentTimeJul 11th 2012 edited
     

    Hell no; the z-index is required in order to do a few things, like the custom background images that are so popular. Breaking that many games all at once is probably not a good idea.

    EDIT: Though the custom CSS would probably allow us to do the custom backgrounds properly, removing the ability to use the z-index property would break a lot of sites all at once until everyone fixes them.

    Also, there’s some z-index stuff that I require with a DST I recently created; even if z-indexes would be disallowed on other stuff, not allowing them with custom DSTs could be problematic.

    •  
      CommentAuthorChainsawXIV
    • CommentTimeJul 11th 2012 edited
     

    This is a great feature, and after playing with it a bit on my test campaign there’s honestly not a whole lot more I’d ask for from it, though I’ll keep looking for details. At this point, I have only two things to add:

    On the cosmetic end, it would be good to make the OP logo in the top navigation bar a transparent PNG so that it blends against backgrounds better.

    On the more technical end, in addition to users hiding things you just don’t want them to as discussed above, there is the danger that they will hide the text area used to edit their own CSS, the button used to submit their changes, or one of their parent elements, rendering it impossible for them to fix their own mistake.

    I’ve got an easy fix for these issues though:

    Create a second non-user-controlled CSS entry which is applied after the user’s, and contains rules for mission-critical elements. Anything you’re comfortable with the user overriding you leave where it is, and anything vital you move into the new entry, along with a few new rules which enforce display and alpha values on things which shouldn’t ever be hidden. Because CSS entries are processed in order, anything set there will automatically trump what the user may have specified.

  7.  

    A couple other notes, not so much about this directly as about things it shows up as in need of a bit of love:

    - The drag-handle under text areas (example) should probably be converted to transparent PNG.

    - Some buttons are button tags, some are spans, picking one would look better and be easier to style.

    •  
      CommentAuthorMicah
    • CommentTimeJul 12th 2012
     

    All good comments, let me hit a few (in no particular order):

    The z-index discussion is good. We may implement something along the lines of limiting the z-index values, but as discussed someone can just inline style what they want. We really don’t do a lot of pre-rendering or manipulating. We basically take the HTML and CSS you give us, do some basic sanitizing, and then send that to the browser. We mainly look at structure and don’t consider semantics. Trying to determine z-values of particular elements is much more semantic than anything else we do. It’s a tough call, as I don’t want to leave open known vulnerabilities, but at the same time I hate the idea of spending lots of time fighting a war that’s only in my head. So far we’ve been blessed with non-malicious users (and very awesome users, in fact) so I hate fighting shadows.

    I like the idea of a final, mission critical stylesheet. I was also worried about people making the site unusable for themselves, and this would work well to prevent that.

    Transparent png for the logo is a good idea. Not sure why we haven’t done that yet.

    Button vs link/span on “buttons” has been a pain in our ass for a long time. Anyone have a good guide on making button inputs look decent? Or, is there a way to make submit inputs with links and spans? I really hate the default HTML buttons.

  8.  

    For the buttons, simply doing them all the same way, using the same class(s) would be a big help from a CSS standpoint, as we could then re-style them to our hearts content without targeting things individually.

    I don’t know of a better canned solution for custom buttons off the top of my head, but its a simple enough concept that I’m sure there are some out there. Personally, I quite like the standard interface elements as presented by browsers these days, but I know that this is more because of their uniform presentation and resolution independence than for aesthetic reasons, and I can understand your distaste. If you bullet point what you consider to be the vital features and qualities you need, and the deficiencies you see in the default inputs, I’d be happy to do some digging though.

    •  
      CommentAuthorLangy
    • CommentTimeJul 14th 2012
     

    I have a suggestion, though what I want to do with it would only really work with a few other changes to the site.

    For CSS styling, I’d like to be able to style elements by ID.

    What I’d like to do with this is to restyle the Wiki section of a campaign entirely, moving the ‘Create New Page’ button all the way up to the top of the OP sidebar right below the User Profile. Then I’d hide the rest of the OP sidebar, and utilize the space freed up to expand the content section of my wiki.

    The only way this would work out well and without removing any nice features is if the ‘Previous Versions’ and ‘Tags’ section of the wiki pages are moved to the Edit page, which honestly is probably where they should be anyways. The rest of the stuff in the OP sidebar really doesn’t need to appear on every Wiki page; instead, I think they’d be just fine appearing solely on the campaign’s Home page.

    Another thing that might be needed would be an overall class being added to all Wiki pages. That way, I’d be able to style the Wiki pages separately from the non-Wiki pages.

  9.  

    You can style by ID already, and most or all of the elements you’re talking about have IDs assigned to them. I haven’t actually tried it, but you should be able to do everything you want to do except the bit where things show up in edit mode that don’t in normal. That, I fully agree, would be a great feature – apply a class to the page in edit mode that’s not there in normal, so that we can style differently in one mode than the other.

    •  
      CommentAuthorLangy
    • CommentTimeJul 17th 2012
     

    You can style by ID? Kallak earlier indicated that you couldn’t. That’s excellent.

    Are you sure that there’s an overall ‘wrapper’ class added to Wiki pages, to allow us to style them differently from the other pages? I haven’t seen one when looking through the source code. Ideally, different page types would have different wrapper classes.

    •  
      CommentAuthorChainsawXIV
    • CommentTimeJul 17th 2012 edited
     

    You can definitely style by ID, using the normal #id rule setup. That much I’ve tested.

    You’re correct however that the different content types aren’t differently classed at the moment. That’d be handy. Most of the individual elements have ID’s already however, so you can target them easily enough.

  10.  

    I’m only vaguely learned in the ways of CSS, and you guys are testing out some quite awesome code here.

    To be completely honest, I almost wet myself when I read about the rollover. That’s something I’ve been wanting to do for ages. Good lord. You guys have made my year.

    •  
      CommentAuthorKallak
    • CommentTimeJul 18th 2012 edited
     

    “You can definitely style by ID, using the normal #id rule setup. That much I’ve tested.”

    Something is off here, cause this definitely is not working for me..

    EDIT: As a point of clarification, applying style to default OP elements by ID works for me (like the main-column background from my earlier post, etc.) but styling content that I write into the pages by ID is what is not working for me. Have you tested that with success?

    EDIT 2: Hmm, apparently using the id tag under div’s and such doesn’t work when coding content for pages?

    •  
      CommentAuthorChainsawXIV
    • CommentTimeJul 19th 2012 edited
     

    Ah, there’s the problem. The CSS works fine, but the id parameter is not allowed in your html-based page content (presumably because you could do something invalid like use the same id as a standard element elsewhere on the page, and break things). For content you’re creating yourself though, you can just add a unique class for the same results.

    •  
      CommentAuthorMicah
    • CommentTimeJul 19th 2012
     

    It looks like we do strip out the id attribute. It doesn’t seem like too much of a security issue to allow user-specified id’s, especially considering how much else is allowed, so I could remove that restriction if it’s desired.

    You’re correct however that the different content types aren’t differently classed at the moment. – What does this mean? I think this may be what I was trying to express when asking if people wanted more semantic markup. If you want us to add more classes and such we can do that, I just need a little guidance on what to add. I suppose I could also just go nuts and add tons of classes to everything.

    In any case, based on the fact that everyone seems generally happy with this feature as-is, I’m planning on rolling it out to everyone in the next couple days. We may do a quiet rollout, make sure it’s generally working, and then make a big announcement.

    Thanks again for all the help and ideas, and if you have more ideas, please keep them coming.

    •  
      CommentAuthorLangy
    • CommentTimeJul 20th 2012
     

    The different content types that need classes or IDs are the bits on the sidebar – for Wiki pages, the profile section, then the tags, the tag list, the previous versions, tools, latest updates, quick stats, and fans sections.

    Further, different page types should have different IDs to allow us to specify different styles for different page types. For example, all ‘Wiki’ pages should have a ‘wiki’ class that covers everything on the page, all ‘character’ pages should have a ‘character’ class, the character list should have a ‘characterList’ class, etc.

    •  
      CommentAuthorMicah
    • CommentTimeJul 20th 2012
     

    What if we attached a class to the body element to identify the current page?

    Potential Classes:

    • wiki-page
    • wiki-index
    • adventurelog-index
    • adventurelog-post
    • character-index
    • character-page
    • item-index
    • item-page

    and so forth…

    Would that help?

    • CommentAuthorMugMug
    • CommentTimeJul 20th 2012
     
    @Micah:

    A couple suggestions related to your list of potential classes:

    1) Adding a class "edit-page" that is only used as an additional class (i.e., class="wiki-page edit-page") would solve the desire to distinctly style edit and display pages, without having to create a separate edit page class for each page type.

    2) The class "adventurelog-post" breaks the implicit naming convention used in the other classes ("foo-page"). Recommend using "adventurelog-page" instead.

    Walter
    •  
      CommentAuthorLangy
    • CommentTimeJul 20th 2012
     

    Yep, that sounds exactly like what I’d like, Micah; I’d also follow MugMug’s suggestions. Making it so the various sidebar bits can show up in both the ‘edit’ page and the ‘view’ page for each type would be nice, too (though I assume some of them will be hidden by default).

    Anyways, great that you’re putting this out there. Definitely looking forward to it, even though it totally means a rework of my campaign again (eventually, anyways). After that, just work on making ‘includes’ available and you’ll make tons of people happy, happy, happy;)

    •  
      CommentAuthorkillervp
    • CommentTimeJul 20th 2012
     

    I agree with MugMug as well- consistent naming conventions would help!

    •  
      CommentAuthorMicah
    • CommentTimeJul 21st 2012
     

    I’m doing an overhaul of the markup right now, and it actually looks halfway decent. There are a few places that need work, but most pages already have a div with a class explaining the page’s purpose. I’ve added some more divs/spans in places where we just had text hanging undecorated. I’ve also focused on the display side, not editing, since display seems like a higher priority. Custom styling for the edit forms is less important.

    I hope to launch this to everyone sometime in the next week.

    •  
      CommentAuthorMicah
    • CommentTimeJul 21st 2012
     

    Below is a list of what I’ve done so far. Unfortunately, I’m sure some of these will be breaking changes in a couple of cases, most notably changes to the character and item pages. I really hope it doesn’t break the DSTs, or at least not too much. But, the goal was to achieve some consistency and make overall styling simpler. Since we’re rolling out the custom campaign CSS along with this change, hopefully fixing any issues will not be too painful and part of moving styling out of the pages themselves and into the overall CSS.

    I apologize if this causes anyone any pain, but I thought it best to just rip off the band-aid and go for it.

    Big Changes

    • Make sure top-level divs (ie. the ones surrounding the main content) have at least an ID and possibly a class. In the case of lists, it only has an ID. Examples: “wiki-list”, “advnture-log-list”, “wiki-page”, “character-page”
    • For single entities (a page, post, character, etc), the top-level ID includes the ID of the item (ie. “wiki-page-my-page-name” or “character-page-my-dude”). The top level class will just be the short version of that (ie. “wiki-page” or “character-page”) The goal here is to allow separate styling of individual pages, if you’d like.
    • Add a matching class on the <body> element for all the top-level containers (“wiki-page”, “wiki-page-list”, “campaign-home”, etc.)
    • Changed “game-item” and “game-character” to just “item” and “character”
    • “blog_post” becomes “adventure-log-page”

    Small Stuff

    • add a class “wiki-list-all” when showing all wiki pages
    • add a class “wiki-list-tag” when filtering wiki pages by tag
    • add a div with class “pc-list” on the characters list page
    • add a div with class “npc-list” on the characters list page
    • changed “tag-list” on character index to <div> instead of <span> with <br/> above it
    • add a div with class “list-footer” at the bottom of the character list
    • add a div with class “list-footer” at the bottom of the wiki page list
    • chaged “game-character-display” to “game-character-page” on the surrounding div of a character page
    • changed id of “avatar” on character/item pages to be a class of “character-avatar” and “item-avatar”
    • complete overhaul of character/item pages to add much more semantic markup
    • add a class (filter-tag-description) for the header when filtering wiki pages by tag
    • add a class “npc-list-title” and “pc-list-title” on the character list page
    •  
      CommentAuthorMicah
    • CommentTimeJul 22nd 2012
     

    My current plan is to release this to everyone on Tuesday or Wednesday of this week, after the frenzy of Ennies voting dies down.

    I’ve also put together a set of guidelines and if you have any thoughts on things I’ve missed or am unclear about, please let me know.

    •  
      CommentAuthorKallak
    • CommentTimeJul 22nd 2012
     

    I have a suggestion for getting more novice users started on using the custom CSS. Make a series of images for the various page types (character, item, etc…) and make diagram labels on which class/id they are set by. This way newer themers can have a visual reference to guide them when making changes. Maybe add a few links for CSS tutorials that you think are adequate.

    •  
      CommentAuthorChainsawXIV
    • CommentTimeJul 22nd 2012 edited
     

    The guidelines page looks mostly good to me, but it may be worth outlining (what I hope will be) a few common exceptions to your red-zone policy. Rules as written for example, my test campaign where I’ve been playing with this is violating the guidelines, but I don’t think there’s anything unreasonable going on there. Specifically, the following things should be expressly allowed:

    • Altering page-level styling of things like fonts and the body background
    • Styling of campaign banners, as they’re user submitted anyway

    Edit: For what it’s worth, I think that the more permissive you are with regard to users altering their pages, the less of a policing issue it will end up being. If your statement on the red zones was more along the lines of “Everything in these areas (except your campaign banner) must remain visible, or you risk action against your account.” it would fulfill the same objective in a simpler, clearer, and at the same time less restrictive way.

    •  
      CommentAuthorMicah
    • CommentTimeJul 22nd 2012
     

    Great point. I should be less aggressive in the verbiage. 99% of our users are fantastic and I shouldn’t talk to people as if they’re trolls. I’ll make the updates that you suggest.

    •  
      CommentAuthorkillervp
    • CommentTimeJul 23rd 2012
     

    Thanks to all of you that helped test this! Us noobs cannot wait to steal from you!!

  11.  

    Spotted another issue that should get fixed – on the Characters and Items tabs, the footer is inside the the content block, instead of outside. I haven’t dissected the issue, but I’m guessing there’s a missing closing tag somewhere in the HTML.

  12.  

    I can’t wait till this is rolled out! Great work everyone!

    Question for anyone that can answer: Micah’s write up says this will be for Ascendant members only. Does that mean as long as the GM is Ascendant that everyone in the campaign will have access or just the GM (co-GM? as well?) will have the ability to edit style?

    (Sorry, I know I’m not part of the beta, but you got me all excited for these changes!!! So I had to ask.)

    ~Flash

    Heroes Unchained – From Slaves To Legends

    •  
      CommentAuthorMicah
    • CommentTimeJul 25th 2012
     

    You bring up a good question. Unfortunately, the CSS is only editable by the GM since it’s on the ‘Edit Campaign Settings’ screen which is restricted to the GM. Even co-GM’s can’t get access to this screen.

    This isn’t really because we don’t think players should be able to edit this stuff. It’s mainly because that seemed like the most reasonable place to put the CSS editing controls. Maybe there’s a better place, but I can’t think of one off the top of my head.

    For now it will stay where it is (since 99% of the time it’s the GM doing all the styling), but I’ll try to think of some way to give players access to it.

  13.  

    Awww….that makes me cry. I do 99% of the style editing for our Heroes Unchained site (as I am the co-GM as well). Please let us know if you figure something out Micah. (I know I’m one of the 1%, but I’d be forever grateful!!!) Thanks for the response and hard work.

    ;-)

    ~Flash

    •  
      CommentAuthorMicah
    • CommentTimeJul 25th 2012
     

    It’s clunky, but you can always just send a txt doc to your GM and ask them to paste it into the custom CSS textarea. Definitely not a perfect solution, but a workaround until something better comes along.

  14.  

    True. Now that I think about it, I can always test on one of my campaigns, and once a style has been set, it shouldn’t need to be changed that often. Thanks for the idea.

    Any more thought on when this will be implemented for the rest of us noobs? ;-) Can’t wait to start playing around with the styles.

    •  
      CommentAuthorLangy
    • CommentTimeJul 25th 2012
     

    The lack of a co-GM being able to edit this kinda sucks:/ I’d really like it if co-GM’s could get as much control over a game as the actual GM; me and Caring are true partners on Edgerunners, but I’m only a co-GM since he was the guy with Ascendant access when we started it and you can have only one GM.

    I guess I’ll have to do the CSS styling on my test campaign and just have him upload it when it’s good:/

    •  
      CommentAuthorMicah
    • CommentTimeJul 25th 2012
     

    Ok, all the updates are deployed, and custom CSS is enabled for everyone. There seems to be an issue with expiring the cache for the CSS, so if you make edits and the CSS doesn’t update that’s a known bug. We’re working on it.

    Also, I hope the markup changes we made are not too damaging to peoples’ campaigns. Like I said…rip the band-aid off.

    •  
      CommentAuthorkillervp
    • CommentTimeJul 25th 2012
     

    Here is the link for the help guide

  15.  

    This feature is working great so far. I’ve just finished my first pass at styling my current campaign, and things are coming along great I think. Thanks! That said, there are just a couple of lingering issues – not with the styling itself, but revealed by it – that would be great to get fixed:

    • The footers are inside the content blocks on the character and item index pages
    • The Obsidian Portal logo in the top navigation should be converted to a transparent png
    •  
      CommentAuthorMicah
    • CommentTimeJul 26th 2012
     

    I’ll look into the footers today. You mentioned it before and I just didn’t have time to get to it. As for the logo, I’ll see about that. I’m really not that great at photoshop so even simple things like making a background transparent are kind of difficult for me. But I’ll give it a shot.

  16.  

    I don’t have ‘shop at work, but I can bang the logo image out for you in two minutes or less when I get home from my game tonight and email it over to you. If I had the original PSD file for it I could probably knock that down to thirty seconds (with a probably imperceptible increase in image quality), so send that my way if you’re so inclined.

  17.  
    Regarding the 'Ascendant only' part of this, if we downgrade to a normal membership after editing the CSS will the styles stay edited or will they revert to default?