Loading...
 
Skip to main content

Architecture / Installation


Browser compatibility problems

There are a couple problems with TikiWiki that I’ve been having pretty consistently, and I’m pretty sure it’s because I use Firefox as my browser instead of Internet Explorer. Several of my site’s other users use Firefox also, so I’d prefer if there were a way to fix these problems somehow.

1: Text frequently flows past the right-hand margin of whatever box it’s supposed to be in. In some themes this happens on Wiki pages. The theme I’m using currently doesn’t have this problem on Wiki pages, but it does on the debug page when the current URL there doesn’t fit on one line.

3: In the Wiki pages of most themes, there isn’t the proper amount of spacing between text and the edge of whatever sort of box it’s in. If you use Firefox, you can see this on the Wiki homepage: http://www.snakebird.net/fac/tiki-index.phpQuestion . The text of the introductory article there reaches all the way to the very edge of its box.

2: When I’m visiting the Wiki homepage while logged in, the elements of the page don’t horizontally align properly. The main body of the page is about 100 pixels wider than it should be, which means it’s slightly wider than my screen and I have to scroll right to view all of it. The header and footer elements are the proper width, though, so there’s about 100 pixels of space between their right-hand edge and the edge of the actual page.

Is there a work-around solution for any of these bugs, or do I just have to hope they’re addressed in the next version release?

Most of us use Firefox, except for a small number of people who attempt to work with a system called Windows.

Styles are not 100% compatible across all browsers, they all try their best, but not one is 100%

However as its a modified bluegreen.css I would suggest you restore the original and try again, its quite common for a newcomer to the heavy Tiki CSS files to change something and not realise its knock-on effects.


btw. Looks fine to me in Gentoo Linux, Firefox 1.5

Damian


> I can't say for sure, but I doubt that your CSS errorsQuestion are helping. I'd attempt to fix all the validation errors first, then see if the site still has problems.
>
>

I figured my CSS file could probably use some work. I customized it while I was using version 1.8.6, and then after upgrading to 1.9.2 I tried to update the theme file in order to match the changes made in the new version. Is there an easier way for me to update themes when I switch to a new version of the software, or do I just have to do it manually like this?

Instead of updating the as-delivered themes, its better to go ahead and create your own themeQuestion. This way you control the TPL and CSS files associated with your site. As long as your HTML validates properly, and your CSS accounts for display differences in each browser/OS combination, its not too hard to create a site that displays 99.99% identically.

If you're serious about cross-browser compatibility, I'd recommend using a tool like BrowsercamQuestion or BrowsershotsQuestion

HTH,

-RickQuestion


> >
> >
>
> I figured my CSS file could probably use some work. I customized it while I was using version 1.8.6, and then after upgrading to 1.9.2 I tried to update the theme file in order to match the changes made in the new version. Is there an easier way for me to update themes when I switch to a new version of the software, or do I just have to do it manually like this?


Anhinga, I, too, encountered cross-browser issues after customizing Tikiwiki. After several days of regressive testing, I found that a broken HTML tag was the culprit. (Apparently, Mozilla resolves broken HTML tag issues whereas MSIE does not.) In my particular instance, I had to extend the text size for a table field to accomodate the characters needed to include the tag closure. However, Tikiwiki itself appears to work fine in all the browsers with which I have tested it — LYNX not included.

> Anhinga, I, too, encountered cross-browser issues after customizing Tikiwiki. After several days of regressive testing, I found that a broken HTML tag was the culprit. (Apparently, Mozilla resolves broken HTML tag issues whereas MSIE does not.) In my particular instance, I had to extend the text size for a table field to accomodate the characters needed to include the tag closure. However, Tikiwiki itself appears to work fine in all the browsers with which I have tested it — LYNX not included.

Can you please be more specific about what files I would need to edit in order to fix this?

> > Anhinga, I, too, encountered cross-browser issues after customizing Tikiwiki. After several days of regressive testing, I found that a broken HTML tag was the culprit. (Apparently, Mozilla resolves broken HTML tag issues whereas MSIE does not.) In my particular instance, I had to extend the text size for a table field to accomodate the characters needed to include the tag closure. However, Tikiwiki itself appears to work fine in all the browsers with which I have tested it — LYNX not included.
>
> Can you please be more specific about what files I would need to edit in order to fix this?

Short of actually editing your site, no. You would probably do well to first confirm that the raw output of the "misbehaving" Web page is correct HTMLQuestion and renders consistently across browsers — without using a style page. (Save raw the Web page as a text file and delete/comment out the CSS links.) If there are any HTML errors, you will need to backtrack to determine from where the errors were introduced. If there are no HTML errors, prepare to have fun. You will need to start from the "last known good" version of the CSS file, and test each change that you introduce.

> Short of actually editing your site, no. You would probably do well to first confirm that the raw output of the "misbehaving" Web page is correct HTMLQuestion and renders consistently across browsers — without using a style page. (Save raw the Web page as a text file and delete/comment out the CSS links.) If there are any HTML errors, you will need to backtrack to determine from where the errors were introduced. If there are no HTML errors, prepare to have fun. You will need to start from the "last known good" version of the CSS file, and test each change that you introduce.

All right, it found two HTML errors. Here they are:

  1. Error Line 428 column 174: there is no attribute "widht".


...n" title="big grin" border="0" widht="15" height="15" />

You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).

This error may also result if the element itself is not supported in the document type you are using, as an undefined element will have no supported attributes; in this case, see the element-undefined error message for further information.

How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.

  1. Error Line 551 column 106: required attribute "type" not specified.


...com/static/scripts/translate_engl.js" >

The attribute given above is required for an element that you've used, but you have omitted it. For instance, in most HTML and XHTML document types the "type" attribute is required on the "script" element and the "alt" attribute is required for the "img" element.

Typical values for type are type="text/css" for and type="text/javascript" for .



What file do I need to edit in order to fix these? I’m not sure where the format information for this page is actually coming from, since it isn’t just a plain HTML page like the version I’ve saved.

EDIT: Some of the HTML tags aren’t showing up here for some reason. Is there a way to quote HTML code here without having this problem?