CSS doesn't show in Edit mode

[birdboot]

Try specifying a particular CSS file in the adminstration for the user/role.
This worked for me (in C3). In the 'Styles and Fonts' section, you have to
select 'Show only CSS styles included in this CSS file:', not 'Show all CSS
styles'. Not much use if you need to use more than one CSS file, but seems to
solve the problem where the stylesheet is attached to an included header.

[Holden-ar]

well ive got the same problem.
Images are ok, but css isnt ok when previewing templates and when editing.
My css is w3c validated.
So, what should i do?

[dfps@work]

I tried a bunch of solutions: 1) Move the CSS stylesheet up the page, i.e.
closer to the top. 2) Used both the @import method and the LINK REL method to
include the styles. 3) Because we use multiple style sheets, I couldn't try the
specify-the-stylesheet-in-the-user-permissions trick. 4) We use the ASP
extension, so the ASPX/extension fix didn't apply. To make matters even more
frustrating, Edit mode would sometimes (rarely) display the CSS properly!
However, I was never able to replicate this. So Contribute seems to want to
display the styles, but some bug is blocking it 99% of the time. My solution
was to take the @import style sheet code out of the include file. While
Contribute will include the HTML contents of include files (at design time in
Edit mode), it seemingly won't reach into those referenced style sheets and
apply those styles at design time. Now that my stylesheet is called directly
from the HTML document (and not indirectly via the include file), the styles
now appear OK in Edit mode. Epilogue: I've been grappling on-and-off with
this bug for months now. While I'm relieved to have a solution, I'm bummed
out: because I thought Contribute couldn't handle pure CSS sites, I used hybrid
table/xhtml code to relaunch my site. If I had known the fix was as simple as
taking the CSS out of the include files, I could have coded pure XHTML. I
suppose I could just modify the templates now, but geeeeeeeeez, what a hassle
this has been. I'm also bummed that (as pointed by other forum posters) this
bug has received so little attention from MM.

[robant_robz]

I, too, have a site set up to use include files for the header and footer. The
CSS file used for my site is mentioned in the PHP header code, so it's not
being called at all in Contribute. So the solution I keep reading everywhere is
to use the 'Administer Website' function for this. So I've done that. But to no
avail - NONE of my styles are showing up in the styles dropdown menu. I've run
both stylesheets against the validator mentioned above, and they've both come
back as 'Valid'. So what gives here? What am I missing? Thanks in advance!
Rob Zazueta

[mzanime.com]

If your style sheets arent showing in edit view then the reason is because
Contribute can't find your CSS due to one reason or another. Contribute should
be able to find a CSS file using either absolute or relative links, regardless
if your using the <link> element or @import rule.

It does not, however, interpret ASP (or other serverside scripts) while in
edit mode. So if you have some dynamic scripts anywhere within the CSS call,
then it is a good bet that it won't find your style sheet.

For instance, this won't work:

<style tyle="text/css"> @import("<% varStyle %>.css"); </style>

Also, if you have your CSS call (or entire header, for example) inside of an
include its a good idea to make the CSS an absolute link instead of a relative
one. Also, I'm not sure how Contribute would handle an @import rule inside of
an @import'ed rule, because I typically never do that, but if thats the case
with any of you I'd suggest taking the CSS out of your 2nd @import and put it
into the first one, to see if Contribute will see it.

[itchylick@yahoo.com]

Good news. I was having this same problem for some time and think I
found the solution (not sure if this applies to the asp folks). I am
using a server side include inside the head tags to call my style
sheets. Again, the problem in Contribute was that the styles were not
rendering in edit mode and the page would fall apart. Here's the fix:

The extension for your ssi's must be .shtml.

That's it. Give it a shot.

[itchylick]

Make sure the extension for your ssi is .shtml. Styles should then render correctly in edit mode.

[mzanime.com]

itchylick, your on crack. You can have include files use the ".asp" extension,
the ".shtml", or even ".html" extension and they will render. The only thing
that I have had problems with is PHP includes, version 2 will not render those,
not sure about version 3.

** If you have the ACTUAL <link> or @import code inside a script block it
will not work though **

[itchylick]

Of course you can use a number of different file types as ssi's. You might also
expect that they'd be treated the same way in Contribute's edit mode. They
didn't for me.

I am using a server-side include in the head of my pages to a file that calls
my external style sheet. The problem I encountered (as did the original poster)
was when in edit mode, the styles would not render and the page would fall
apart. I was unable find a solution until I came across this article today ...
[url]http://www.macromedia.com/devnet/contribute/extreme/extreme002.html[/url]. The line
that caught my attention was "Also, make sure that users who create pages with
includes know to add the .shtml extension to the filename." So just out of
curiousity and a dwindling set of options I changed the filename of my ssi from
..htm to .shtml ... and guess what? It worked. My pages now render correctly in
edit mode. As to why this is happening I couldn't tell ya. I'm just glad I can
move onto the next problem.

Not on crack. Just trying to help out.

[Jeff Radwill]

Interesting thread.
Does it bug anyone that the only font-size styles available are the ones
specified in the CSS (x-small, smaller, etc.) yet all of the standard type-face
sizes are available (18, 24... 72!?)

Also... if you add a <p>Some Text</p> (using Enter key)... and then delete the
Return, C3 leaves the </p>.

As in...
<td<Old text</td>

(Press enter, type new text)
<td>Old text

<p>New Text</p></td>

move cursor to end of old text and press Delete

<td>Old Text New Text</p></td>

[mbbblue]

We've just discovered the same apparent bug on our intranet site. :|
When initially building the main template for the site, the css styles were
correctly displayed in both design and edit modes. Since some amendments were
made to the template, suddenly the pages would appear okay in C3 browse mode,
but would revert to no styles being applied when the users edited the page
causing confusion for the users believing they had caused the apparent error.

The css styles were also not available to them, only the default Heading 1...7
etc. :confused;
To resolve the issue I created a testpage.asp in C3 (the template displayed
okay in the New page preview window) and put this file at the lowest level in
our directory structure (the file had no apparent styles applied) I then
proceeded to publish the file to the web server. I then navigated to the file
in my browser and everything was okay. I looked at file in C3, and the page
appeared okay. However when editing the file it reverted to no styles being
applied. :(
I then took advice from the forum, within this thread, and edited the template
file simply cutting and pasting my css reference, placing the code as the
second line in my <HEAD> tags, updated the site pages based on the template,
and republished those pages to the web server. Now in the browser and
Dreamweaver nothing has really changed other than where the css reference is
placed. In C3 we see that the page appears okay in browse and edit modes.
Thanks to the forum and this thread I appear to have applied a solution for
our problem. :)

[mzanime.com]

Jeff wrote:

> Also... if you add a <p>Some Text</p> (using Enter key)... and then delete

the Return, C3 leaves the </p>.

It doesn't -always- do this, but yes, it can be a challenge if your trying to
keep the code of all pages on your site validly follow the W3C spec..

At my old job, we had a staging server and also an external server, which the
public could see. Only our users could see the internal server and thats where
they worked on pages. We had some ASP code in there which would display a W3C
validator link only if the current page was loaded from the staging server IP
address, and the link was hidden if the file was viewed from the external
site's IP.

It may be a good idea for you to do something like that, it would greatly help
eliminate errors in your code caused by Contribute, because those kind of
things only happen sometimes. You could train your users to click the validator
link (before sending their page off to review) and if it throws an error, then
contact their administrator to fix it.