I think we should consider these rules as part of the best practice:
1. Never use FCKEditor styles. There is the ability to create FCKEditor styles in the Publish application. The user goes to the folder properties of one of the primary Publish folders and can edit the styles. Those styles show up when editing a page in Publish and the user can select them. However there is a big problem with these styles. They’re implemented using <span> tags. E.g. <span style=”font-family: Helvetica,Arial,Verdana,sans-serif; font-size: 24px; text-transform: uppercase;”>My Style</span> The problem is that if I now wish to change that style I will have to go through every Publish page and try to remove the style and then re-apply. They’re also extremely messy and often customers create pages that become unmanageable because of all the span tags. It doesn’t seem to make sense considering we could be using CSS styles.
2. Contain all Publish pages in a div (e.g. <div id=”PublishPage”>) The best way to go is to have the styles of the customer’s interface dictate the Publish page styles. However, sometimes the customer wishes to have different formatting for their links or headings in Publish pages in contrast to the rest of the Intranet. Therefore I propose that all Publish Pages live in a div called “PublishPage”. That way we can easily edit interface_<customer>/common/style.css and add #PublishPage a { font-weight: bold; color: #0000ff; }. If the styles aren’t defined for this div then they just get the normal styles.
Alexander N. Polyanskih, 04/02/2009 22:31:
1. About not using FCKEditor styles...
They are not implemented using <span style=”...”>, but implemented exactly as you define them in XML file. For example, default XML file has style called “Marker: Yellow” defined this way:
This is good and works everywhere, but has that disadvantage of inserting styles directly into page content instead of using CSS from separate file. So if you wish it to be defined using class name, you need to change style definition in XML file to this:
This way you can define any styles. This is a power of defining styles in XML file - you can not only ad new tags, but also change attributes of existing tags (such as add attributes to image tag).
2. Wrapping pages content into named <div> - not a problem at all and I think this should be done in VI by changing all pub_....html files in default VI. For example, interface_default/main/pub_main.html now looks this way:
Discussion
I think we should consider these rules as part of the best practice:
1. Never use FCKEditor styles. There is the ability to create FCKEditor styles in the Publish application. The user goes to the folder properties of one of the primary Publish folders and can edit the styles. Those styles show up when editing a page in Publish and the user can select them. However there is a big problem with these styles. They’re implemented using <span> tags. E.g. <span style=”font-family: Helvetica,Arial,Verdana,sans-serif; font-size: 24px; text-transform: uppercase;”>My Style</span> The problem is that if I now wish to change that style I will have to go through every Publish page and try to remove the style and then re-apply. They’re also extremely messy and often customers create pages that become unmanageable because of all the span tags. It doesn’t seem to make sense considering we could be using CSS styles.
2. Contain all Publish pages in a div (e.g. <div id=”PublishPage”>) The best way to go is to have the styles of the customer’s interface dictate the Publish page styles. However, sometimes the customer wishes to have different formatting for their links or headings in Publish pages in contrast to the rest of the Intranet. Therefore I propose that all Publish Pages live in a div called “PublishPage”. That way we can easily edit interface_<customer>/common/style.css and add #PublishPage a { font-weight: bold; color: #0000ff; }. If the styles aren’t defined for this div then they just get the normal styles.
1. About not using FCKEditor styles...
They are not implemented using <span style=”...”>, but implemented exactly as you define them in XML file. For example, default XML file has style called “Marker: Yellow” defined this way:
This is good and works everywhere, but has that disadvantage of inserting styles directly into page content instead of using CSS from separate file. So if you wish it to be defined using class name, you need to change style definition in XML file to this:
and define this class in CSS field:
.marker_yellow { background-color: Yellow; }This way you can define any styles. This is a power of defining styles in XML file - you can not only ad new tags, but also change attributes of existing tags (such as add attributes to image tag).
2. Wrapping pages content into named <div> - not a problem at all and I think this should be done in VI by changing all pub_....html files in default VI. For example, interface_default/main/pub_main.html now looks this way:
and should be changed to
and that’s all. No need to change all pages.