Ie6w and gaps [Site check]

[liorean]

Ok, I've been toying around with a tabbed interface for CSS/JavaScript/DOM browsers. I'm not sure how well it's designed - it's too large for my aim of "simple example" when I created it.

Site is at: <http://liorean.web-graphics.com/dhtml/tabs/tabs.html>

Files that are components of it can all be reached (for inspection) from the directory listing, <http://liorean.web-graphics.com/dhtml/tabs/>

In op7, when I tried to give the dl a clear: both; rule, it caused the same sort of gaps that ie6w has, so I guess that might be the problem. Or ie6w's float handling. Or it's box model, or it's list handling.

Except for the ie6w gaps, I'm wondering what happens when you open it first time, and consecutive times. Does the "Tabs" tab open? Is the text under the tabs/content or does it flow around it? Are there any visual artefacts? JavaScript errors?

Also, I'm wondering a bit about what browsers does and doesn't support the tabbed interface, so except for moz, ie6w and op7, test it in whatever you got.

TIA
// Liorean

[brothercake]

Safari very nearly works - the first tab I click, its layer appears directly underneath the main layer instead of over it. Clicking subsequent tabs replaces that second layer with the new ones, but the tabs at the top never appear to change. Opening one of the anchored-URIs directly - sometimes the right layer is there (but the tab still has a black bottom-border), and sometimes none of them show up at all.

Camino (moz1.3 for OSX) doesn't work - the tabs are there, but the definition layers are not there at all. All that happens is you click a tab and its bottom-border disappears.

mac/ie5 is worse than that - the definition layers are not there, and the tabs are not lined up either - each one is the full width of the screen and they're stacked on top of each other. I haven't looked closely at your code - but are you using "width:auto" and "float:left" on those tabs? If so - that always happens with mac/ie5 - floated block-level elements with auto width expand as much as they can and stack on top of each other. I'm still looking for a workaround for this problem ... Also in mac/ie5 - there's a gap at the very top of the page - above the black heading strip - with a euro symbol in it! The same gap is there in Safari but it's blank.

Clever stuff though - it's basically a stylesheet switcher, right? Presumably if it was gecko-only you wouldn't need the JS component at all?

Methinks it's time you bought yourself a mac ;)

[liorean]

Hmm, the problems now are not the same as in the original post - the gaps issue is "fixed", or at least patched together good enough for now. Now it's time to fix degradation and semi-compatibility issues as best I can.

In moz you can use pure CSS using the CSS3 pseudo-class :target to display the tabcontent areas, but hide everything else. You can't do the change in border colour, though, since it's on another element several steps away in the hierarchy. For any other browser which I have tried, the theme switcher is needed. (Yep, it's a style switching mechanism. My thought was that a theme switcher would be the perfect tool for this, and I had one in store already.)


It's just strange - it works in Mozilla, but neither in Camino nor Netscape 7.02...
I'm using css components that have been correctly parsed since pre-1.0, except for :target which shouldn't be necessary in any case since the theme switcher does it's work just as well.

I'm a little bit surprised Safari didn't get it right, but at the same time, if you manage to press the bit of the tabs that isn't a link, moz will also display two tabcontent areas at the same time. I should probably fork out the stylesheets to cover more in-between cases, so that I can get good degradation in more browsers. (And move the onclick handler to the links, to get rid of that specific problem.)

iem is a slight problem, which I don't think I'll be addressing. Let's wait for something better from Microsoft on the mac instead - saf and cam has good enough coverage for me.


Well, thank's for the input. I'll be updating and tweaking and then ask again.

[brothercake]

That mac/ie5 problem seems to be related to elements which normally have list-item display. I describe both the problem and the solution (I've just found) at http://www.brothercake.com/Ref/auto_float/

[liorean]

Does that work for li * {float: left;width: auto;}? If so, I guess iem won't be that much of a problem after all.

[brothercake]

Originally posted by liorean
Does that work for li * {float: left;width: auto;}?
Yeah it does

[liorean]

Oh, I see I didn't write what I thought:

Does it work for li>* or must it be li *?

In other words, must it cover all decendants or just children? If decendants, does there exist a difference between inline and block elements?

[brothercake]

It still works with the > selector

[liorean]

Oh, it works with the selector in that case, but what about nesting a small tree of spans or something? That was the thing I was wondering about, whether ONLY children were needed to have those properties, or if all decendants needed them. And of course, whether inline or block makes any difference.


Sorry for not being more clear about this from the beginning, but half my mind is occupied with building a more robust and fail-safe tabbed interface... ;)

[brothercake]

I don't know. If you make a test of the cases you had in mind I'll happily look at it.

[liorean]

I broke the theme switcher in op7 this time, but I think it will hold better from the onslaught of the mac browsers. Do you think you could have a look at it again?

TIA,
// Liorean

[liorean]

Update on the op7 breakage: It wasn't the theme switcher at all that was broken - it was a CSS problem. Bug reported to Opera (http://liorean.web-graphics.com/bugreports/opera/mutipleimport.html).
Just in case you wanted to know.

I'll be fixing this issue as best I can, but I can see it problems with all possible solutions so far.

[brothercake]

Safari now doesn't show any of the layers or tabs; but if you link directly to an anchor it does show that layer.

Camino shows the first layer only, and none of the tabs; even if you link to an anchor it still shows the same default tab.

mac/ie5 doesn't import any of the styles - it sees the plain list

It's fine in Opera 7 now - but I figure you knew that ;) Do you have a BTS number for the bug you reported?

Btw -

a question - what's the purpose of the "high-pass-filter"?

a suggestion - you should never use media="all" - do not allow a media type to read CSS unless you have a test device for it, otherwise you risk giving it formatting which may be completely unsuitable for the medium. Use media="screen" (in this case).

a comment - I see you - this whole thing is just an excuse to wash your head about various technologies :D

[brothercake]

re mac/ie5 problem - I know you get the evolt list as well, but for the benefit of others reading this, here's an explanation I was given; see http://www.l-c-n.com/IE5tests/ further reading.


http://www.w3.org/TR/CSS2/visuren.html#floats says.
A floated box must have an explicit width (assigned via the
'width' property, or its intrinsic width in the case of replaced
elements).

But you assign your floated boxes: 'width:auto;', this imho, is not an
explicit width.
Other browsers 'shrink to fit' the width when specified as 'auto', IE
mac doesn't, it stretches the box to the width of the parent box,
unless you specify margins etc. (The css2 recommendation is not very
clear on the matter. This will be corrected in css2.1, but that is
still at working draft stage.)

It is an unfortunate behaviour in IE Mac (and one that makes most
'tabbed interfaces' that have popped up of late fail in IE Mac). But I
wouldn't label it as a bug.

[liorean]

Originally posted by brothercake
Safari now doesn't show any of the layers or tabs; but if you link directly to an anchor it does show that layer.

Camino shows the first layer only, and none of the tabs; even if you link to an anchor it still shows the same default tab.Aaargh! Those mac browsers are driving me crazy. How I wished I had a mac to test things on...

I'm a bit stumped about Camino's reaction to the entire thing - it's supposed to be a trunk moz build with a native UI, right? Then why doesn't it work the same as moz on styling and scripting issues?mac/ie5 doesn't import any of the styles - it sees the plain list
Hmm, not what I wanted, but I guess it's acceptable. Anything is better than the 'tween browsers...It's fine in Opera 7 now - but I figure you knew that ;) Do you have a BTS number for the bug you reported?

Fine? I can't get the tabbed interface to work myself (I'm using 7.02, so there may be differences to 7.10)

Btw -
a question - what's the purpose of the "high-pass-filter"?


It's a high CSS compliancy test - the browsers that doesn't handle \" in strings will try to import <null.css?> and think the { begins a block that it doesn't understand and thus ignores. The more compliant will import <null.css?%22{> and the rest of the files, too. In other words, it's a way to hide whole css files from nonconformant browsers.

a suggestion - you should never use media="all" - do not allow a media type to read CSS unless you have a test device for it, otherwise you risk giving it formatting which may be completely unsuitable for the medium. Use media="screen" (in this case).

Only one problem - some versions of nn4 understands media="screen" but no other media value. Besides, media="all" is equal to the default for stylesheets without the media attribute, so it doesn't do any harm except saying explicitly what goes implicitly without saying..

a comment - I see you - this whole thing is just an excuse to wash your head about various technologies :D

Depends on how you look on it. As for the contents, you've got tme there. However...
The exercise as a whole is one in getting something that is quite advanced to work or degrade acceptably in ALL browsers that can't handle it. It's also my first try at multiple-level degradation - you usally don't see that many such around on the web, btw.

Mozilla is the only browser that can handle it on all points. (Leading the way, as always. Go Moz!)
Safari should be the closest after.
Opera shows yet again that it's not entirely reliable when it comes to the finer points of the older technologies, but it's got wide support for newer technologies.
Ie6w exhibits some of it's faults, but shows it has a strong engine underneath.
Ie5m is still better, but it it getting old. And finally, the veteran ie5w displays the same faults as ie6w, but a less potent engine.

[liorean]

Ok, this is getting a bit weird:

I have this in [default.css]:#tabbar{
display: none;
}

This is pretty straight forward - it means the tabs won't display in the non-tabbed rendering.

In [target.css] I have code that does only CSS3 specific stuff:/* hides tab contents that are not :target */
html>body dl#tabcontents :not(:target){
display: none;
margin: 0;
}

/* display tab contents that is :target */
html>body dl#tabcontents:not(:target) dd:target{
display: block;
}

/* Display tabs */
html>body ul#tabbar:not(:target){
display: block;
margin: 0 0 -1px;
padding: 0 0 0 .5em;
}Ok, that has a potential of disrupting things. First of all, they are the highest specificity selectors in the document. Second, they hide tab contents if tabs are not :target, while displaying the tabs.

What does this mean? First of all, that tab contents will not be displayed at initial rendering. Secondly, all those selectore use :not(:target), and thus only a browser supporting both of those will render anything from that stylesheet at all.

Third, this means we have conflicts with the other alternate stylesheets based mechanism. The alternate stylesheets mechanism will only be active when JavaScript is enabled, though, so I use JavaScript to remove the [target.css] stylesheet.

Well, on with the stylesheets - this is the point things are getting weird - in any of the alternate stylesheets, who have the same structure:
[filter-*.css]
&nbsp;&nbsp;[tabs-*.css]
&nbsp;&nbsp;[tabinterface.css].
In other words, they have one importing (filter) part, one specific (tabs) part, and one shared part.

Let's take the relevant rules per file, starting with [tabinterface.css]:/* Hide general tab contents */
html dl#tabcontents *{
display: none;
margin: 0;
}

/* Strange part: Display tabs */
html ul#tabbar{
display: block;
margin: 0 0 -1px;
padding: 0 0 0 .5em;
}

/* Strange part: Display tabs */
ul#tabbar{
display: block;
}

Now, what code is contained in the [tabs-*.css] file?/* Display correct tab contents */
html body dl#tabcontents dd.tabs{
display: block;
}


But wait - why did I colour code those two things? Well, this is what is my problem:
- Any of those should be enough.
- If it's put in [tabs-*.css], [filter-*.css] or [tabinterface.css] shouldn't matter.
- All problem browsers (saf, op7, cam) have problems with that and only that in of the rules in the alternate stylesheets.


Only the blue part is not enough for the problem browsers to display the tabs.
If I have both the red and the blue rule in [tabs-*.css] or [tabinterface.css], op7 renders correct, saf and cam not.
If I have only the blue part in [filter-*.css], op7 renders correct. (saf and cam not checked)
If I put the blue part in [tabs-*.css] the tabs display as a list. If I put it in [tabinterface.css], it doesn't display at all. (op7 only; saf and cam not checked)


I can see no reason for this variation - none at all. In short, I don't even know where to look. Especially since it works just fine in both moz and ie6w no matter where the blue rule is placed, no matter whether it's accompanied with the red rule or not.

I've determined a few things it can NOT be:
- Errors in the alternate stylesheets parsing and handling in the triad.
- Errors in the importation of the stylesheets in the triad.
- Inability to parse either the blue of the red rule.


In short I've had it fully functioning in each of the browsers at some time, except in cam, where I've at least had the tabs display.




So, to determine where the problem lies, I need the following testing:

Four tests in saf and cam: blue rule placed in [filter-*.css] or [tabinterface.css], with and without JavaScript enabled. (JavaScript is very important, as it's possible the JavaScript is the key part in this).


Brothercake (or anyone else), do you think you could do those tests?

Otherwise, if you have any ideas about what the problem might be, please tell me. This is a knify one.



If you help me solve this, I owe you one ;)

[brothercake]

Dunno mate; I'm not really a theory guy - I just mess around with stuff until it works right.

But if you wanna make up some test pages, like I say, I'll happily look at them and tell you or show you what happens.

[liorean]

Hmm, seems I've straightened out what the problem is (at least in the case of op7) - for some to me unknown reason, the first style rule in the [tabinterface.css] stylesheet seems get ignored. Evidently, something of the same kind happen in Camino and Safari. I know they don't ignore the entire [tabinterface.css] or they wouldn't hide any of the tab contents, but they seem to ignore more than the first rule in it (since I put the red, rule first, then the blue, then the rest), for some reason. Op7 ican be considered solved, but I don't know about saf and cam. Some versions of Netscape 6.2 and 7 seems to have the same problem as Camino, some not.

So, now I know the problem, but what is the cause? What might cause the triad to ignore some - but not all - rules in the stylesheet?



Brothercake, can you have a look at it in saf and cam? I've moved the blue rule to mid-stylesheet instead and wonder if that fixes part of the problem (the part of tabs not rendering at all), the entire problem, or does nothing at all. Same address as before.

[brothercake]

I'm looking in Safari - the tabs do nothing when you click the, like you said.

Blessed if I know why :( Is there a self-contained zip you can send me, so I'll put it on my mac and play around with it?

[liorean]

Not for the moment, but you can use the directory listing <http://liorean.web-graphics.com/dhtml/tabs/> to get all the files. I'll have a zip up as soon as I can.

(Oh, and I downloaded Moz1.02, so now I'm going to try to get at the cam/ns7 problems as well. )

[:edit:]zip is up, <http://liorean.web-graphics.com/dhtml/tabs/tabs.zip>

[brothercake]

It's tricky catering to those old moz builds. I remember how viciously I slated mozilla from 0.6 - 1.0 for its rendering instability, and how each minor version update was so radically different from the previous one .... I admit I would have been a lot kinder if I'd appreciated the value of standards-compliance at the time, but I was still lost in IE-centricity like [most] everyone else ....

I think it's a shame netscape 6 was ever released - it did more damage to the Netscape brand than M$ could ever have hoped for, and it's the reason why most netscape 4 users went to IE6 (that was my perception, anyway).

Damn shame - they may have the best browser engine in existence, but in the field of brand marketing they seriously need to sort it out. Oh no hang on ... what am I saying ... Netscape is AOL innit. Oh well that explains it; those who control the hegemony don't ultimately have to care :rolleyes:

Anyway - soapbox browser sociology aside - completely OT :o

[liorean]

Had a look at it in Safari? I'm stumped as to what the reason might be. The styles now work (for what reason I'm not sure) but the theme switcher doesn't.

Damn KDE for not having a Win32 port of Konqueror ready yet.



You're right about that point - Netscape really took a marketing hit to their brand when the pre-production state ns6 was released. They couldn't go wait any longer, though - the delays were already killing their reputation. They did a mistake in not waiting a year more with Gecko and just patch up nn4 to a 5 version, if you ask me.