the code for gradients is not correct!

When I observed that my gradients were going right to left instead of top to bottom, I went in and changed rotation  -90deg to 180deg and things looked fine in Firefox — but I wasn’t REALLY understanding the problem —  Doing that made the gradients misbehave in Safari, which my client was using — He thought I’d gone batty putting a gradient band on the right side of  some home page widgets.

This morning I found this article:

http://foundationphp.com/blog/2012/10/28/fireworks-css-properties-pane-gets-gradient-wrong/

with a wonderful explanation of why / how fireworks gets it wrong and a better approach to fixing it.   It turns out I only need to modify the last rule that the smartest browsers will employ.  By modifying all of them, I just confused myself!

A certain page on a website was causing IE8 to switch into “compatibility” mode — and to display as if it weren’t paying attention to any media queries, which it otherwise could handle.

I found a meta tag to add to force it to stay out of compatibility mode — and then it would just display NOTHING!  View source,  the content was all there,  but just a big white screen!

Other pages with similar elements were displaying OK.   A few pesky validation errors could not be eliminated, but they weren’t breaking other pages.

Before beginning to attack the long content of the page, I decided to try making a new menu item for this page.  I did, but before trying the menu link, I copied the  Joomla link and tested viewing just the article (no menu id, no modules)  in IE8.   It worked  fine, but was missing a few styles.

Turns out I had styled a few things on this page with a  .menu-### selector, so of course those styles weren’t in play.

I went back and edited the article with a wrapping div with an ID  and replaced the .menu-### selector with the #new-id for these 8 rules.  

Now the page was broken again!  

Narrowing in, I disabled 4 of the 8 rules.  — OK.  I kept narrowing until only the rule with a :first-line selector was left.   Commenting this style out, the page was fine.  turn it on,  the page displays NOTHING!

I was able to use a :first-child selector to  achieve the same appearance  — without having to alter the html,  because the two line list items had been turned into links.

The JCE editor coded it as two separate links with the between them.

I was able to select     li  a:first-child  and apply the font-styles I wanted.

If any list items are NOT converted to links, they’ll lose the styling, but I’ll deal with that if I must.

As if absolute positioning isn’t complicated enough….  I think I always assumed that an object would move to position 0,0  as soon as position:absolute was declared.

But in fact,  all my tests of browsers today seemed to leave the element where it was and only adjust the position – relative to it’s positioned containing block — if the offset is specifically declared.   (This is not very clear in the w3c specs.)

Thus, in two different students’ work, I observed absolutely positioned elements remain where they normally would have been in one dimension while being positioned in the other dimension with the declared offset.     Declaring the other offset as zero  (top:0;  or left:0;)  caused the element to adjust to the viewport as no other positioned elements had been defined.

I found this:  (http://www.charlescooke.me.uk/web/lab_notes/pos_abs/index.html)

It is only the offsets which are measured with respect to the viewport and that only sometimes. If no offset is specified i.e. if it is unmentioned rather than set to zero the positioned element will remain where it would have been in normal flow. In other words positioning the element need not necessarily change its position from where it was it may just change its status to ‘positioned’. A method frequently employed is to set the declaration
position: relative;
either on the body or on a div without including an offset. It then becomes possible to position other elements with respect to the body or div without further ado.

Which makes the distinction between unmentioned  and set to zero offsets.

I was grumbling about browsers being too kind and not referring back to the containing block or viewport in this case, but in fact, this is the common interpretation.

The interesting thing you can do with this is to have something act like a fixed position element, but not fixed to the viewport — by not mentioning any horizontal offset, the absolutely positioned sidebar remains offset from the top of the viewport and horizontally where it would have been otherwise.

I’m preparing notes for the html / css class I teach at the Marlboro College Graduate School and at the same time helping a colleague troubleshoot a ready-made Joomla! template.  

Needing to override a styling rule, there are many possible ways to make a rule more specific without using !important!

Firebug (Firefox extension) and CSSEdit (part of Espresso package from MacRabbit) are two tools that will help you identify the style rules currently  in play.   Of course, you could just edit the stylesheet and make changes to the rule directly,  but sometimes you want to keep all of your custom styles separate, in which case you may need to increase the specificity of the selector.

If the rule in question targets only a class,   i.e.    .alert,   you could increase specificity by simply adding the element selector,  i.e.  h1.alert.

Often, though,  template stylesheets already are using quite complex selectors. 

I made a note to play “Could you be more specific, please?”  as a classroom activity for my students — presenting them with some real-life selectors and analyzing  their suggestions for getting more specific.

What’s the most elegant solution to the problem?

The following rule was in the stylesheet for a Joomla component I use: 

    div.thumbs_div a:hover, a:active, a:focus{
    background-color: transparent !important;
    }

Do you spot the syntax error which caused me no end of grief?

I finally did!

Continue Reading

This topic came up at Joomla! Day New England — how to get template styles to show up in jce styles dropdown and to affect the content in the editor window.

For some time now I have been installing the JCE editor for my clients to use on their Joomla sites.   And each time I have to make a decision about how to configure the editor, because this can be done in different ways and “It Depends…”  is always the right answer.

Here are a few possible issues:

1.  If the site has a colored background or image for the body tag, then the editor will also display that background — and it’s hard to edit black text on a dark background!

2.  Some templates include css something like this:

body { text-align:center ; /* for ie */ } div#wrapper { text-align:left; /* reset text alignment */ width:748px; /* or a percentage, or whatever */ margin:0 auto; /* for the rest */ }

This was for early versions of IE and we no longer need to use text-align:center; in order to center the page in the browser window, but… if you have these styles, then everything is going to appear centered in the editor window if you use template.css styles.

3.  If I want the client to be able to choose and apply special styles to the content, I need to think about what’s enough and what’s too much.

Back in May of 2009 I posted about a solution for the background color issue — it was coming up with WYSIWYG-Pro.

That solution involved modifying the template’s html to include a class on the body tag. And then, in template.css, set

body {background-color:white;} —  this will be in play in the editor window

body.body {background-color:dark;} — this will be what displays as the background when site is viewed in a browser.

This works  if you configure JCE to use the template.css styles.

But..   This will also display all classes used in your template.css   including things like .moduletable  and .menu.  On a large site with many custom styles, this could be overwhelming, when all your client needs is the ability to use  a few styles for controlling floated images, or a style for .quote,  .quotee,  or .alert.

In this case, I would opt to NOT use the template.css file, and to create a special  editor_content.css file, including only the classes and styles that I need the client to have access to.

If I choose to create a separate editor_content.css file, there is no need to add the class to the body tag, as I can create a rule setting a white or light body background (and aligning text) that will apply in the editor window.

Using conditional statements you can control whether your template creates a div and module position for a left or right sidebar depending on whether a module exists for any given page.   But this does not cause the content to stretch to fill that available space when no sidebar modules are present.

It IS possible to use conditional statements in the opening php block of your template to set values of variables which are then used in the template to create divs with different classes depending on the modules present.

For this example I’m using a liquid design with a left column width of 20%, and a right column width of 30%.   Left and center columns are floated left, right column is floated right. Two background images are used to create the faux columns. The content area will be either 50%, 70%, 80% or 100% depending on the presence of modules for the left or right columns.

I add these 4 lines to the opening php block:
if($this->countModules(‘left + right’) > 0) $layout=”50″;
if($this->countModules(‘right’) <= 0) $layout=”80″;
if($this->countModules(‘left’) <= 0) $layout=”70″;
if($this->countModules(‘left + right’) <= 0) $layout=”100″;

and in my html I reference that variable wherever needed like this: