Friday, June 10, 2011

Being force fed Ektron CSS

I am currently working on an Ektron site. We had the home page looking good, but wanted to add a news feed. After being given the required HTML, I created a new blog in the workarea, made the required XSLT (tweaked from a previous project) and dropped a BlogEntries control onto the page. This completely broke the page – the fonts had changed, spacing was completely out.
The culprit was the Ektron blog CSS. Ektron is smart enough to only load the CSS required for a particular page. So when the BlogEntries control was added, the Ektron CSS URL changed from something like-
workarea/csslib/ektronCss.ashx?id=EkOneCss+EkTwoCss
to
workarea/csslib/ektronCss.ashx?id=EkOneCss+EkTwoCss+EkBlogsCss

Whilst it is admirable of Ektron to try to reduce your page load, the problem with this is twofold-
  • Using XSLT, I have no requirement of the Ektron CSS.
  • The Ektron CSS is at times terrible.

Here, in particular, is the offensive piece of CSS in the \Workarea\csslib\blogs.css
p, li, div    
    {
    margin:0in;
    margin-bottom:.0001pt;
    font-size:10.0pt;
    font-family:Verdana, Geneva, Arial, Helvetica, sans-serif;
    }

Dear CSS designers of the world, imagine for a second that you had the following CSS forced upon you by a developer. You would go spare trying to override it. Maybe you could use “inherit” and “!important” to work around it, but either way it’s a lot of work.
So, we had a previously fine page suddenly rendered ugly by the choice of Ektron server control. Our options to solve this are-
  • Workaround the CSS. As mentioned above, this is quite laborious, and be sure to budget for rehab for your CSS developers.
  • Delete the offending code. Main problem with this is to remember to re-delete upon upgrading Ektron. If it’s just one bad CSS snippet that’s not too bad. Also, you need to take responsibility for any side-effects of deleting this. For a blog control, this will be minimal, but overriding some of the horrible widget and Page Builder CSS will make the in-page editing ugly or unusable.
  • Nuke the Ektron CSS via JavaScript.
  • Rebuild the control without using the blog control. This may mean re-implementing functionality which is normally out-of-the-box from Ektron.
Ektron could solve this by-
  • Improving their CSS. Mainly by removing loosely scoped selectors.
  • Add a DisableCSS property to server controls, effectively giving the developer the chance to say “Leave it Ektron, I’ll take care of the CSS for this control”.
  • The improved framework API and MVC/MVP style controls would offer viable alternatives, though there is nothing stopping Ektron injecting CSS for these controls.

We’re still weighing up our options, but it looks like we’ll rebuild the control without using the BlogEntries control. A half-hour implementation has become a four-hour implementation, and CSS that I do not want nor need has been force feed to my site visitors.

4 comments:

  1. JS and Css handling is something we're committed to improving in each release. We address this in 8.5 with new control types that give you complete control over JS.CSS, and JS and CSS registration itself (finally) becomes a fully documented API.

    In the meantime, you can always do something like this in PreRender

    foreach (Control control in this.Page.Header.Controls)
    {
    Ektron.Cms.API.EktronCssControl ektronCss = control as Ektron.Cms.API.EktronCssControl;
    if (ektronCss != null)
    {
    //do your thing here
    }
    }

    -Ted Henry
    Ektron Engineering

    ReplyDelete
  2. The easiest way to avoid this problem is prepend your css with the id of a containing div. For example "#content p, #content li, #content #div". The id will cause your CSS to have a higher specificity than Ektron's thus moving it up on the cascading order (http://htmldog.com/guides/cssadvanced/specificity/). It takes some getting used to but at least you won't have to worry about Ektron's CSS anymore.

    ReplyDelete
  3. "Ektron could solve this by- Improving their CSS. Mainly by removing loosely scoped selectors." Yes, I absolutely agree. As Ted Henry pointed out above, revisiting older controls and fixing their scoping and cascading effects to not conflict with sites css rules is something we're looking at with every release. The blog control is on the list. Btw, I just finished recording a developer podcast with Ted that you might find interesting-- we have an interesting conversation that moves from challenges facing front-end developers in general on the web today, to ektron's new templated server controls, to html5 v silverlight. Expect a link for this to be coming out via blog/twitter soon.

    ReplyDelete
  4. I love this suggestion the most "Add a DisableCSS property to server controls, effectively giving the developer the chance to say “Leave it Ektron, I’ll take care of the CSS for this control”." We are developers and we want control over how our controls look.

    ReplyDelete