I was incorporating some of the suggestions I had read on this board. Things were going well. I deleted a style I had created, that I realized I had no need for ... and somehow, my design interface has become corrupted.
In the preview and compile windows, all is well. The page width for html is as I want it. But, in design, every single word goes to the next line. It's near-impossible to edit.
I don't think that the style I had created and discarded should have affected design mode in any way. What can I do to reset this?
I have definitely narrowed it to the style sheet. If I switch to another, the "edit" mode is usable. But I have spent a lot of time getting the styles as I want them in the working style sheet. What is the gap that I need to fill?
Since it appears to be in multiple styles, I'd look at the html and body styles first. It looks like you probably set a line-height value to a large amount.
Lisa Eagles may soar, but weasels aren't sucked into jet engines. Warning! Loose nut behind the keyboard.
It'd be difficult to suggest anything without seeing the actual CSS.
It might be related to using the float and clear properties in your styles. The Flare editor tends to mess things up when you use these, and I normally disable Enable Object Positioning (in View > Show menu).
I had in fact introduced a "float" style, Dave. That might be it.
I'm still not quite sure what triggered it, though. I went to a backed-up (but not current) version of my CSS and compared it to the corrupted version (I converted both CSS files to text and compared the text in Word). I still couldn't spot the problem, but I was able to identify the changes in styles I want to retain and transfer them to a copy of the backup. I'm back in business, though it took awhile.
If anyone else has any ideas as to what might've caused this sudden change, please post -- it would've been easier to undo or reset something. Thanks for the help and suggestions.
LTinker68 wrote:Since it appears to be in multiple styles, I'd look at the html and body styles first. It looks like you probably set a line-height value to a large amount.
LTinker68 wrote:Since it appears to be in multiple styles, I'd look at the html and body styles first. It looks like you probably set a line-height value to a large amount.
do you have a width property set somewhere?
That could be it, too. I was looking at the vertical spacing and thought you meant that, but now I see the width appears to be really narrow, too. The width is also most likely set on the html or body tags, or possibly somewhere on the masterpage, most likely the bodyProxy. If you do print output (e.g., PDF) and that's fine, then it would point to something on the masterpage or something the masterpage looks to. If the print output is also narrowed, then it would definitely be something in the stylesheet.
Lisa Eagles may soar, but weasels aren't sucked into jet engines. Warning! Loose nut behind the keyboard.
Thinking back ... it first appeared when I was trying to change the output page width for Webhelp. (I was looking at some examples and I liked that look.) I thought it required a body proxy, so I created one. That didn't have the effect I was looking for. Then I realized that I didn't need the body proxy; I could have simply changed the body's width settings. I set the body's medium (default) width to 800 px. Voila! The output looked great. The design mode was also fine. That made the body proxy I had created unnecessary, so I deleted it.
That's the point at which the design mode no longer displayed properly. Yes, it seems the width was miniscule -- but I couldn't find a way to set it back. It's as though design mode was at a loss, trying to use settings in the deleted body proxy -- which shouldn't have been called, as far as I can tell.
I had never set any body width smaller than 800 px.
I made that change again to the copy of the older CSS backup and everything is fine. It seems that the creation, then removal, of the unwanted body proxy affected the CSS in a way that negatively impacted design mode only -- all outputs compiled fine. I could test this by creating another body proxy, then deleting it, but I don't want to press my luck.
Just to clarify, the bodyProxy isn't unwanted. That's just a placeholder to signify where in the masterpage the topic content should be positioned. It's the same with your breadcrumbProxy -- it's not the actual text, but a placeholder for the text that will be inserted at build time.
You don't generally need to apply styles to the MadCap|bodyProxy style in the stylesheet, so maybe that's what you mean by the unwanted bodyProxy. You do need the bodyProxy tag block in the masterpage, though.
Lisa Eagles may soar, but weasels aren't sucked into jet engines. Warning! Loose nut behind the keyboard.
mattbnh wrote:I have seen this and if your problem is the same as mine, I think it is an editor glitch that is transient.
When I open a topic and it opens like this, I click on the either the Mode or Medium button in the XML Editor Toolbar and the topic returns to normal.
I don't think there is anything wrong in the topic itself.
Yep. That's how I get rid of it, too.
Inge____________________________ "I need input! - Have you got input?"
Thanks for the suggestions. I'll keep them in mind if it should appear again. In this case, though, it's definitely a corruption of the CSS. If I return to the corrupted CSS, the problem reappears, and changing the mode or medium doesn't "shake" it.
A CSS file is basically just a text file, so if you want to try to narrow down the problem instead of having to redo your entire stylesheet, try this... Use Windows Explorer to make a copy of the stylesheet file, then open the copy in Notepad and move it to the side. In Flare, open the stylesheet file using the Internal Text Editor. Delete everything in the file except the first few styles (h1-h6, p, etc.). Save the stylesheet file in the Internal Text Editor (but leave it open). Click on a tab for a topic and press F5 to refresh the topic, which should reload the stylesheet file. Most of the text will look very plain, but you should see the XML Editor return to normal. In Notepad, copy a few styles to the clipboard, making sure you get the opening { and closing } for each style. Back in Flare, paste those styles into the stylesheet file in the Internal Text Editor. Save the stylesheet, go to the topic and press F5. If the XML Editor still looks fine, then you know those styles aren't the problem. Keep repeating the process until you've narrowed down which block of styles are causing the problem with the XML Editor. Once you've narrowed down the problem, you can inspect the styles or delete them altogether and recreate them.
It sounds like a lot of work, but it's really not, once you get a rhythm. Plus copying-and-pasting styles is a lot easier than trying to recreate them from memory.
Lisa Eagles may soar, but weasels aren't sucked into jet engines. Warning! Loose nut behind the keyboard.
What I did was to convert the text files to Word; use the Word "compare documents" feature to identify the differences; and locate the styles I wanted to recover. I never was able to identify what was causing the problem (no obvious errant style) but I was able to get back on track. I'm holding onto the corrupted style sheet as a reference and curiosity.
I wasn't aware that this can also be a fleeting page repaint, per earlier comments -- that's also good to note.
Lisa -- out of intellectual curiosity I tried your suggestion. I was back on track but I wanted to know what had gone wrong. That "process of elimination" solution was just what I needed. I made a copy of the bad CSS and began paring it down.
The problem lines (not immediately apparent when reviewing the styles) came down to this:
html
{
width: 800px;
}
I had been focused on paragraph styles and hadn't considered a lingering change in the html styles -- and I still don't follow why that would affect design mode in the way it did. But the above proved to be the problem. Thanks -- I am able to go back to the original style sheet now.
