Global CSS, Please

Comments

  • dungeoncrawlers
    dungeoncrawlers
    Posts: 32
    I know new features are a pain to request, but is there any way we can possibly get a “global CSS” field added to the Campaign Settings? Think of it as the CSS that would go between the “” tags in the header, and would be displayed on all wiki pages, campaign log pages, and the home page.

    If the concern is users messing with the base layout, such as ads, etc. I think it would be easy enough to give each of those elements a unique class name, and then “filter/block” those very unique class names in the CSS string to prevent modification to those areas via “global CSS” functionality.

    The main reason for this is that it’s becoming very cumbersome to have to re-write in-line CSS elements for each page, and if a class could be defined globally that would save TONS of time. Also, there are elements that I’d like to modify that I currently cannot: link colors for example.

    Thanks,
    Justin
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    I'd love this too. I think I remember seeing someone mention the idea before as if it had been talked about, but I don't remember where. Regardless, this would be a huge help.
  • Figment
    Figment
    Posts: 132
    The main thread about campaign specific global CSS is here: "http://forums.obsidianportal.com/forums/5/topics/434":http://forums.obsidianportal.com/forums/5/topics/434

    It was also brought up "here":http://forums.obsidianportal.com/forums/6/topics/357, "here":http://forums.obsidianportal.com/forums/5/topics/456, "here":http://forums.obsidianportal.com/forums/3/topics/682, and now in this thread.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    Custom themes as discussed in that linked thread sound cool too, but I don't think that's quite the same as what's being talked about here. At least, what I'd like to be able to do is set up a few custom CSS classes for use in the HTML tags I write into my own content. The themes discussion suggests re-styling the common page styles, which is another animal entirely.
  • dungeoncrawlers
    dungeoncrawlers
    Posts: 32
    Exactly, Chainsaw. Even if not full control, maybe a dynamic “style sheet” with some limited control for global settings. I can see disabling the position functionality, and a few others, but I don’t see the harm in allowing global classes for divs (especially considering I can already define them in-line).
  • dungeoncrawlers
    dungeoncrawlers
    Posts: 32
    For example, the "Blue and Cyan" link colors clash rather badly with the layout design I'm working on for my current campaign. The cyan hyperlinks are the worse, and are nearly unreadable on the parchment div backgrounds. At least an option to "customize" some of the colors associated with our campaigns would be nice, but a fully customizable "style sheet" would, of course, be better.

    http://www.obsidianportal.com/campaign/worldbeneath
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    Considering we can inline style as much as we like, doing custom classes just as you described in your original post seems totally reasonable to me. It would be trivial to cross check the class names against the sites style sheets, but in my opinion, even that's pretty unnecessary.

    My compliments on your page, by the way - that's a neat trick with the header and background styled sidebar divs.
  • dungeoncrawlers
    dungeoncrawlers
    Posts: 32
    This CSS Style Sheet feature would still make things tremendously easier, however I thought I’d at least share my solution/work-around for the clashing link colors. It’s a bit of a pain, but it works:

    Use inline CSS to format your hyperlinks. This can be done by adding the following code somewhere inside of your < A > tag: Style="Color:#000000;"
  • dungeoncrawlers
    dungeoncrawlers
    Posts: 32
    Thanks for the compliment, Chainsaw. :)
  • Figment
    Figment
    Posts: 132
    Dungeoncrawlers, I have been using the inline css for changing the color of hyperlinks where color coding is important, but I can't image doing that for every link in the entire wiki. You're braver than I.
  • Triptych
    Triptych
    Posts: 18
    I'd love to be able to use a custom CSS for my campaign site.

    My wiki looks really dull and a bit hard to read.
  • gnunn
    gnunn
    Posts: 423
    I had an idea that might provide a temporary fix, and which might be useful for other purposes as well. What if we had a "GM clipboard" which appeared below the GM Only section on each page? Unlike the GM Only portion of an individual page, the information in the clipboard would be the same regardless of which page you are currently viewing/editing.

    This could be useful either for copying and pasting CSS or other code elements to help ensure a consistent look and/or as a place to keep global campaign notes that are not page-specific.
  • ShadowDrakken
    ShadowDrakken
    Posts: 4 edited December 2009
    I'd also like to see just an extra CSS page in the wiki that applies to all of the Campaign's pages. Themes are ok, but generally take more work than they're worth on both the back-end, and for the end user. By creating a special CSS page only accessible by the Campaign maintainers, you can very easily go beyond simple themes without any of the difficult back-end coding that themes require. As has been said already, you just run the CSS through a quick filter to eliminate any code that modifies ObsidianPortal's titles, footers, navigation and advertising.
    Post edited by ShadowDrakken on
  • Neph
    Neph
    Posts: 10
    You say "If the concern is users messing with the base layout, such as ads, etc. I think it would be easy enough to give each of those elements a unique class name, and then filter/block
  • ShadowDrakken
    ShadowDrakken
    Posts: 4
    Neph: the pseudo-selectors are exclusively CSS3. Some browsers implimented them with CSS2, but it's not actually part of CSS2, and not all browsers support it. It wouldn't be hard to filter them out along with filtering out the unique IDs. Between those two filters, there's no other tricks left to exploit. But I agree, the policy should include account banning and CSS deletion for attempts to bypass the site design.
  • Neph
    Neph
    Posts: 10
    Not to be all pedantic about it, but pseudo-selectors have been around since CSS1. For instance, :first-line was a CSS1 selector, which could be used to strike out an element that is in the "first line" of a div. The one I mentioned, :first-child, is part of the CSS2 spec (see http://www.w3.org/TR/CSS2/selector.html).

    It is true, however, that pseudo-selectors are getting even more powerful in CSS3, and could be used in ever-sneakier ways to target things for hiding, and that's the real crux of the matter.

    Unfortunately, I don't think the right approach is to filter out pseudo-selectors. They are useful in too many circumstances, and necessary for so many legitimate design choices, that it will only frustrate and confuse people to strip them out. Specifically-named id tags? Yes. Entire classes of selectors? No.

    IMHO, the safe thing to do is assume that someone given the ability to add style to a page will find a way to target an ad shown on the page, and move forward with your business model in a way that it isn't compromised if someone takes advantage of that. Ultimately, the question is whether the benefit OP will gain from having people make beautifully-crafted campaign pages (and the exposure and higher subscription rate that would bring) would be offset by the revenue lost by the (hopefully) small percentage of jerks who hide ads but don't get caught doing it. My guess is that it would be worth it, since the former is adding value for loyal customers and the latter is trying to wring revenue out of jerks who aren't interested in OP's continued success. To me, it's a no-brainer who to side with, but it's possible that I'm underestimating how many people would go hiding the ads.

    Of course, a third possibility, and one I think is probably the best solution, would be to make the global style sheet a premium-account-only feature. Given that this would allow people to possibly hide the ads anyway, making it part of the no-ads package makes it a great incentive for people who would normally be heavily invested in OP-based campaigns anyway AND it would mean neither side would have to deal with filtering CSS. As an added perq for OP, seeing the cool things people do with their global-CSS campaign pages would drive sales of the premium accounts.
  • ShadowDrakken
    ShadowDrakken
    Posts: 4
    Well, then another solution might be to create a CSS class builder rather than raw access to the CSS. It'd need to be a quick entry form, type a cssitem as a .classname, #elementid or elementtype (allowing only alphanumeric, period, hash and spaces, no colons or other symbols) and then allow the CSS to be entered into a textarea. When saved, it creates cssitem { } that can then be used for the custom theme. This makes it where you only need to filter for the specific class names used by the site (which can be easily parsed on the fly from the source template file for the wiki pages, rather than hard coding them), and leaves most of the power of CSS available. Granted, it's not the prettiest method, but it gets the job done, protects Obsidian Portal, and doesn't require them to change business model.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    What you're describing amounts to the same results that could be achieved with filtering, only with a more cumbersome interface. You're just filtering out the pseudo selectors by preventing the user from ever inputting them. You could achieve the same results with a simple RegEx find and replace against a user submitted CSS page.

    I would tend to agree with Neph, that the best way to do this is to implement some basic protection - simple filtering for the known class names and ids, and their pseudo-selector variations - and just be on the lookout for anyone going to the trouble of doing it the hard way, by selecting from the element types down. Combine that with making it a premium feature, so at least a few bucks are on the line, and issues should be really rare.

    There are even a couple of easy ways to help them spot violators:

    * Javascript that checks the vitals (display, size, position, etc.) of key page elements after page load, and sends up an investigation flag if they've been tampered with.
    * Periodic RegEx search of CSS for type selectors with or without pseudo-selectors, which might indicate tampering, followed by a simple visual inspection process.
  • Neph
    Neph
    Posts: 10
    Question: The premium version of the site is "ad-free" according to the subscriptions page. Does that mean that your campaign pages don't show ads on them, or does that mean that no ads are served to you, no matter which pages you view, but ads ARE shown on your campaign page to other visitors?

    If it's the former, there's no issue. Make the "global CSS" a paid-only feature, and don't worry about filtering the CSS to protect the ad placement (since there would be no ads to hide).

    If it's the latter, then there's still an issue, in which case, I think ChainsawXIV's approach is probably best: Strip out the obvious id-based CSS selectors to keep the casual jerk at bay, and then handle the rest with a little clever spot-checking of campaign wikis that generate zero ad revenue.

    "Well, then another solution might be to create a CSS class builder..."

    Boy, would it be a pain to have to manage selectors individually through a web interface. Bleh. And I don't see that being a fix unless you're choosing from a list of predefined selectors, which would be pretty limiting.

    "Javascript that checks the vitals (display, size, position, etc.) of key page elements after page load..."

    Using Javascript to check display, size, and position of an ad still isn't foolproof, since you could leave the ad alone and just z-index something on top of it using absolute positioning. You couldn't thwart this by just filtering CSS selectors, either, since you could theoretically use any DIV you could target - you'd have to filter CSS *rules*, too.

    I guess my main point is that you don't want to get into an arms race with the hackers, especially if their numbers are few and the damage they can do is small. I suspect the time the OP developers would spend making a CSS filter to combat a handful of jerks would be better spent (read: would make them more money in the long run) making features that generate more page views by making the site more useful for everyone, or by making the premium subscription more valuable so that more people upgrade to it.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    Subscribing just removes the adds for you, not from your campaigns, so some kind of protection would be required. Besides the adds though, there are some arguments to be made for protecting the general sight layout and such, not so much to prevent anything really bad, as to maintain standards of image and presentation.

    In any case, I agree. An elaborate solution is probably not needed. Something simple, with basic safeguards, would probably be more than sufficient. With those basic safeguards, the system is no worse off than it is now in fact.
  • Neph
    Neph
    Posts: 10
    Ah. Okay, so the simple solution of making it premium-only and not filtering the CSS won't work. Too bad.

    In terms of still needing to filter the CSS to essentially protect users from themselves, the way Blogger deals with that is to have a reset CSS control that is available without going to the pages with custom CSS. You could let people munge up their pages if they are so inclined, while still giving them a way to reset it all if they do something that makes their site unusable.

    Another possibility that occurred to me is that you could regex an ID selector for the content area to the start of each selector in the CSS. Unless there are some CSS tags that I don't know about, I *think* that would limit the scope of any CSS rules to the content area. In other words, the site admins could define the content area as skinnable, not the entire page with nav and ads. That way, you're not filtering on content, just on the format of the selectors, and a pretty simple one at that.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    I had a similar thought last night at dinner, and totally forgot about it before getting back to the computer. That approach would absolutely limit the styles to the user submitted content, and it's nicely elegant as well. It wouldn't even require structural changes to the existing setup, as the user's content is already wrapped in a div with the _page-body_ class.
  • Karelzarath
    Karelzarath
    Posts: 13
    I'd also love to see a way to define campaign-specific CSS that would carry across all the pages of a campaign. At the very least, a way to specify fonts and colors would be awesome. In particular, the header tags are just way too huge and ugly to use. This site is sooooo close to perfect that I'm amazed a CSS mechanism wasn't included.
  • Ferdil
    Ferdil
    Posts: 7
    Have the developers ever at least told us why they won't implement this feature?

    It would be a hell easier and cleaner this way. I'm already considering moving to another wiki site for the lack of this feature.
Sign In or Register to comment.

March 2024
Wrath of the Highborn

Read the feature post on the blog
Return to Obsidian Portal

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Discussions