I just want a title style.... >:

[3lliot]

Ok so I've read that Flare won't let you create 'parent' styles. So I figured I could just edit the CSS and create a style called 'title', but when I do that it doesn't show up in the available styles in the topic editor. Presumably because it's not officially a 'parent' tag.

If I make it a class under something else (e.g. h1.title) it's all good. But I don't want my title style to be a class of h1. Not for any particular reason, other than the principle of the thing, and being able to do what I want.

I've also tried calling it .title, but then Flare assigns it as a class of whatever it thought it was associated with last (be that p, or h1 or whatever). But then I can't see it to edit it in the style editor.

What is going on?

Also, I can't find where all the default styles are inherited from. When you open the style editor, you get dozens of lovely styles. When you open the css in the text editor, you only get those that you've edited. So your stylesheet is just an appendix of some other stylesheet. Is it the case that any style sheet you add to the project really contains only 'virtual' styles, and is only populated when you start editing the default styles? How can you edit the actual CSS?

As an example of the madness, I tried to change the colour of the <a> style earlier today (in a newly created stylesheet) & it just wouldn't stick. but I received no explanation why it wouldn't stick, it just didn't. So I had to create a class under <a> to change the color. So now I have to manually assign that class to all my hyperlinks, which is ridiculous. Am I missing a trick here..?

There's a lot of documentation about styles (e.g. the big pdf) but nowhere, as far as I can see, does it explain how Flare manages the CSS files and the limitations on editing them. which appear to be 'you can't edit them, you can only create new classes'.

</confused>

[NorthEast]

The items you see in the stylesheet editor is a list of the standard (X)HTML tags, and a number of Flare-specific tags with a MadCap| prefix.
You can apply style properties to these tags, and add your own style classes; but you can't add your own custom tags.

To get the best out of Flare, it's worth spending some time learning the basics of HTML and CSS; a good website is http://www.w3schools.com/

Although Flare's stylesheet editor might show some properties for these styles, most* of these are not actually contained in your stylesheet; they just represent what is being used in Flare's editor, which is also what you might typically see in a browser.

For example, if you open a HTML page that has no stylesheet, browsers will still display it with some default styles; e.g. text in a h1 tag will be displayed as a large heading, and text in a b tag will be displayed in bold.

Selecting hide inherited will hide any tag that's not defined in your stylesheet. In the stylesheet editor Advanced view, you can also display Set (locally) properties, to only show properties defined in your CSS file.


* There are some exceptions though. Some of the MadCap| styles do have properties that are added to your stylesheet, or rather they are added to a secondary stylesheet MadCap.css which only exists in the output. Examples of these styles are the black border lines on the Breadcrumb and MiniTOC proxies.

[i-tietz]

In the Flare stylesheet editor you get a pool of styles to chose from. Also all tags are listed, because MC cannot know what tags or classes you want to edit.
In the actual stylesheet only those tags and styles are added that are set, i.e. which don't have the default values.

And in the Stylesheet editor I see the same list of settings for each tag and class even for the (Generic Classes) (the class .title would be one). I simply use the option Show: Alphabetical List.


Oh, and the a tag is pretty complex because of its pseudo classes - you should change the colors there, too.

[3lliot]

Ok thanks. I understand html & css. I just figured that because the stylesheet contained an entry for <a>, I'd be able to edit the font colour. Could you tell me how to do that without creating a new class?

Also, if Flare uses xml, why can't I define & style a new tag? is that to constrain the tag set to xhtml? and isn't that defeating the purpose of it being extensible?

cheers
-E

[i-tietz]

The editor uses XHTML, not XML. That's a big difference.

And you edit the pseudo classes in the stylesheet editor:

edit_a_in_stylesheet.png

Make sure you're in the right medium and have the complete list to chose from.

[LTinker68]

Also, if Flare uses xml, why can't I define & style a new tag? is that to constrain the tag set to xhtml? and isn't that defeating the purpose of it being extensible?

I think you're confusing structure with appearance. XML is for establishing structure to content. CSS is for styling how you see the info contained in the structure. CSS has its own set of standards that have to be adopted by browsers, so it's not end-user extensible in that fashion.

The XML in Flare is mainly in the supporting files (most of the stuff you see in the Project Organizer tab). The XML Editor and output is XHTML.

[rob hollinger]

I can understand wanting to use a css class called Title, but to have a main style called Title will cause browsers to have issues with it.
Title is a reserved tag and will not be displayed by any browser that I know of regardless of where it's located in the html code.

What is the reason for wanting a "title" style?

[3lliot]

I must have a bizarre understanding of xhtml then - I thought it was extensible html, i.e. you could define your own elements but the structure rules were more strict to make it html-compliant.

So I guess when you're applying a 'style' in Flare (e.g. via the styles panel), all you're really doing is changing the class attribute for the selected element - you can't actually change the element itself?

I think the reason I'm expecting stuff I probably shouldn't expect is because I worked for a bit in arbortext epic, so I got used to the flexibility.

[LTinker68]

So I guess when you're applying a 'style' in Flare (e.g. via the styles panel), all you're really doing is changing the class attribute for the selected element - you can't actually change the element itself?

No, you can switch between elements, to an extent. If you open the Stylesheet Editor, set it to Advanced view, and set it to show all styles, then you see a reaaalllly long list of tags and classes. To prevent you from having to scroll through that long list of tags and classes in the Styles pane (and drop-down list), MadCap grouped some tags together, and which tags (and generic classes) you see in the Styles pane depends on the type of tag the cursor is currently within. For instance, if you're in a paragraph, then you see the paragraph tag and all its classes, the heading tags, any generic classes you've (manually) created, and so on. If you select text in a paragraph, then you see the span tag and its classes, and any generic classes you've created, etc. If you're in a list, then you see list-related styles.

So if you're in a paragraph, you can't switch to a list from the Styles pane (unless you're mimicking a list using auto-numbered paragraphs). The only way to go from a paragraph to an HTML list is to click the list icon in the toolbar above the XML Editor. Once you've done that, you'll see li tags and its classes. (To select a different ol or ul class, you have to right-click on the ol or ul tag in the show blocks area and select a different class there.)

If you're in a list, there are two ways to get to a paragraph tag. If you want a paragraph inside your line item, then you click the drop-down area next to the List Actions icon and select Make Paragraph Items. If you want to get out of a list back to a normal paragraph tag, then you can either click the outdent icon in the toolbar or toggle off the list type icon.

Oh, and to get to a DIV or blockquote, click the indent icon to bring up the Group popup screen (or whatever it's called). You can select the blockquote tag or DIV class from there.

[3lliot]

Ok thanks Lisa. When you say generic classes, what do you mean by that? are those classes that can be applied to any element? as in when you create a class, edit the css & remove the parent (e.g. create p.class1, then delete the p in the css so you're left with .class1)?

[3lliot]

Also, something else that's confusing me - I created a class for <a> - let's call it a.class1 - which is in my default stylesheet, but when I try to delete it, I get a message saying 'the style a.class1 cannot be removed since it is inherited and not defined in this stylesheet'.

[3lliot]

Ignore that, I just deleted it from the css. It does seem bizarre though.

[i-tietz]

Ok thanks Lisa. When you say generic classes, what do you mean by that? are those classes that can be applied to any element? as in when you create a class, edit the css & remove the parent (e.g. create p.class1, then delete the p in the css so you're left with .class1)?

If you look at the pic I inserted in my last post , you will see the group (Generic Classes) in the list at the left.
1. right click on the stylesheet in the Content Explorer
2. chose "open with" | internal text editor
3. You insert this line:

Code: Select all

.title { }

4. close and save the stylesheet
Now you will see that class in the group of the generic classes and you can go on with formatting.

You can assign those generic classes to everything, means: spans of text, paragraphs, lists, tables, divs, ... => You will see it in the styles pane or the styles picker in any situation.
We have that sort of thing in our projects to insert invisible text to improve our search results - our generic class is called .invisible.

[RamonS]

I must have a bizarre understanding of xhtml then - I thought it was extensible html, i.e. you could define your own elements but the structure rules were more strict to make it html-compliant.

Technically, you can extend any way you like, but the matter is that the parsers in the browsers need to know what to do with a tag. Again, technically, there are ways to tell the browsers, but there is no guarantee that it will work reliably across browsers or at all. Think of XHTML to be HTML that must adhere to the stricter XML rules, which mainly amounts to making sure that tags are closed properly. That said, while XHTML is still valid to use and supported the W3C decided to fold the intentions of XHTML into the HTML5 path as there was little sense in maintaining two very similar standards.

[Andrew]

RamonS is right. Here's a page that explains the issue, and one method you can use.

[LTinker68]

Also, something else that's confusing me - I created a class for <a> - let's call it a.class1 - which is in my default stylesheet, but when I try to delete it, I get a message saying 'the style a.class1 cannot be removed since it is inherited and not defined in this stylesheet'.

Most likely you created it in the default medium (recommended) but you were in the print medium when you tried to delete it. You'd need to switch back to the default medium view in the Stylesheet Editor to be able to delete the class.

[3lliot]

Ok, thanks for all the info guys.

[Aaahh, DTDs... the good old days :]

-E

[3lliot]

Also, something else that's confusing me - I created a class for <a> - let's call it a.class1 - which is in my default stylesheet, but when I try to delete it, I get a message saying 'the style a.class1 cannot be removed since it is inherited and not defined in this stylesheet'.

Most likely you created it in the default medium (recommended) but you were in the print medium when you tried to delete it. You'd need to switch back to the default medium view in the Stylesheet Editor to be able to delete the class.

Thanks Lisa. You'd think for such a likely occurrence, a more informative error message would be called for...

[RamonS]

Thanks Lisa. You'd think for such a likely occurrence, a more informative error message would be called for...

Not with Flare/.NET. The utterly useless error messages that Flare spews out are an annoyance since the first release of Flare. I guess adding features always takes precedence.

[LTinker68]

Thanks Lisa. You'd think for such a likely occurrence, a more informative error message would be called for...

Not with Flare/.NET. The utterly useless error messages that Flare spews out are an annoyance since the first release of Flare. I guess adding features always takes precedence.

I'm not sure in this case that it's a .NET issue. The Stylesheet Editor is something MadCap created. It's built on .NET technology, but that particular error message is one that MadCap would have had to create since the stylesheet file itself is a flat file and I don't think any browser would particular care if it found a style defined in the print medium that wasn't defined outside that medium (i.e., in the "default" medium area of the stylesheet file). So in this particular case, I think it was just a case of a programmer thinking he was being explicit enough when he could have added more details.

[RamonS]

I meant it more in general. Often enough the .NET errors are just shown and neither help the user nor support nor the programmers. Writing code to properly report errors of any kind requires effort and is not one of the glamorous tasks, but it is something an app like Flare should include.

[i-tietz]

(changed the subject of this post to sth more fitting)

In german systems those messages are often titled "unerwarteter Fehler" (=unexpected error). I find that name frighteningly precise, because it's exactly that - unexpected.
Of course the developer can do sth against or around it - if he is aware of those errors ...

[RamonS]

There are still measures that can be taken that make even an unexpected error (aren't most errors unexpected?) produce a meaningful message. Such a message should include the current status, where the error occurred (code module), what the actual and expected input was, and what the expected outcome was. For potential or predictable errors the message should include suggestions on how to avoid the error, although many of those cases can be prevented by designing the UI and logic correctly. Errors occur because the programmer allowed for making that error.
The problem with proper error reporting is that it does not add any practical functionality to an application. On top of that, it is very tedious work. If the decision is to make a new gizmo or help users and support in time of crisis management will almost always decide in favor of a new gizmo. Having a new feature enables sales. Customers are initially not impressed when the sales rep brags about the excellent error handling, it probably would backfire. But once customers use the app proper error handling is a key component to maintain high levels of support and thus customer satisfaction, which equals to customer retention. Implementing this quality will not foster initial sales, but it will keep the annuities coming, which often rake in more than the initial sale.
Errors will happen and it then comes down to how the vendor responds to them. I am sure that the response will be tremendously faster and better when more information about the error condition is available. For this case, Lisa indicated the most likely reason why that message might come up. How much time would it have cost the developer to add that into the message? Three seconds? And how much time would it have saved the many users? If developers really truly care about user experience there is no discussion about the answer to this question. That assumes the developers really understand fully what they are coding and who the users are and what they do. I've come across folks who just code whatever satisfies the requirements and passes the tests without knowing the big picture. They are not developers, but just code monkeys.

[i-tietz]

If developers really truly care about user experience there is no discussion about the answer to this question. That assumes the developers really understand fully what they are coding and who the users are and what they do. I've come across folks who just code whatever satisfies the requirements and passes the tests without knowing the big picture. They are not developers, but just code monkeys.

The developers you know care for users or even usability? Lucky you!!
My almost 30-year-experience with developers tells me, that generally they don't. If you're lucky you get a head of department who enforces that sort of thing - in that case you get solid software and programming ... but it doesn't happen very often - my personal experience and experience from other people telling me stories: in 10 to 15% of all cases ...
Usually it's a jumping from one ticket or feature to another - not looking left or right - just getting rid of the tickets on their account. I could tell you all sorts of stories. And that only from the company I'm working for now - adding the stories from my whole IT career would take days.
And agile programming doesn't make it any better - without the strict head of department TAs are lost in space.

Watch out - SATIRE:
In Germany we have a health insurance for artists - the premiums are exceedingly low, because they're subsidised. Rumour has it that quite a few developers tried to get in there - regarding themselves as artists.