Apache OpenOffice (AOO) Bugzilla – Issue 6229
SourceCast tob and left-hand navbar served when not wanted/page specific CSS data operates on top and left-hand navbar when shouldn't
Last modified: 2004-03-22 16:10:52 UTC
Problems in the following pages: http://es.openoffice.org/abc http://es.openoffice.org/barradenoticias In the first page we get SourceCast top and left-hand navbar served on pages that appear in the iframe (not wanted) as well as other default values on A tags etc, which get unnecessarily inherited. In the second page, we get the top and left-hand navbar served in a pop-up window, which reduces its already minimal utility (notice-me function more than anything else) to less than zero. http://es.openoffice.org/lecturas This page also had an iframe structure originally, and same problems as described above. I removed the iframe as a short term solution although the page is now fine as is, even if the SourceCast interaction problems did not exist (still problems with un-useful inheritance from site-wide CSS values though). However, as can be seen there would now appear to be the opposite problem: CSS info which should only operate on the content of the page also operates on the SourceCast top and left-hand navbars (in a curiously inconsistent way as far as font-size and colour are concerned).
This is not a bug, it's a feature (really!). In order to understand why this happens it is important to understand how SC creates webpages. When you understand this process, you will also understand why things happen the way they do in this bug. SC has a collection of static files -webmacro's- that are part of the skeleton of SC - they form the header of the page, the top and side bars, and the footer. The HTML we create to place on the side are pulled in on the fly, and the whole thing is presented like that as one single pages. The key here is to understand that *all* pages served by SC are served this way. So, when you create an IFrame (a particularly evil tag), this is a *new*page* for SC, so it is rendered, again, with the SC constructs. Within the context of how SC functions, this is expected behaviour. Your second example is a variance on this behaviour, where the javascript in your page calls another page, thus again forcing SC to create the constructs. Your 3rd example does not display on my browser, probably due to very good standards adherance. You see, the CSS you specify in your own page is a second CSS - there is already SC-specific CSS generated. These two conflicting CSS's will screw up the page, according to how depraved your browser is. To override this behaviour, and generate your own CSS, make sure your CSS specifies unique classes (use a prefix, like "my_par" or "my_th" for example, and then use the class="my_par" in your HTML). Let me know if it is not clear, and we'll take this to the list. ;-) Cheers, Martijn
closing issue
*** Issue 6230 has been marked as a duplicate of this issue. ***
For technical reasons we have to move the issue to another subcomponent tan 'www'. Sorry for bothering you with this generated notification message. There is no need for any action from yor side. Thanks for your understanding, Stefan