Fork me on GitHub

PostNuke Blue 100%?  Bottom

Go to page [-1] 1 - 2:

  • 'Quirks mode' rings a bell. Something I read somewhere at some point in relation to people having problems with graphics in particular in Mozilla/Gecko browsers. Your test site still runs it in Strict, so can't see if it makes a difference. Otherwise, it just needs a bit of CSS tweaking.

    IE 6 has a 'quirks' mode of its own, called CompatMode. It largely has to do with whether it should apply the CSS1 standards, or allow the sloppy code that works in older IE browsers, especially in relation to stylesheets. Or, as they put it, "rendering behavior is consistent with previous versions of Internet Explorer."
    Where it may be significant, and I'm not certain how far IE6 applies the CSS1 standards in Standards-Compliant Mode, is to do with the CSS Box model that has tripped up so many designers and spawned all sorts of clever CSS hacks to fool IE into rendering DIVs the same as other browsers. I've seen Javascript that specifically tests for this mode and applies slighty different Javascript syntax as a result, so it's presumably significant with JS as well.

    So, the lesson is, render a proper full Doctype WITH the URL to the DTD to have IE6 switch on Standards-compliant mode:

    Without the address to the DTD, it goes into backCompat mode, rendering like the old IE browsers.

    Article on MSDN, with 2 examples to be viewed in IE6:
    http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/compatmode.asp


    PostNuke and Tables:
    Note there is absolutely no reason to be religious about the whole table-less design thing, it can work for some sites, but not so well with a column-based CMS system that also requires a footer, like PostNuke. I did some tests a while back, and all the trouble you go to to overcome the problems with using DIVs where they're not really appropriate, just isn't worth the hassle, and the code, more so the CSS, gets messy. That might make Accessibility worse. CSS advocates, like on A List Apart, have a valid point in how things are laid out in the HTML code for people with screenreaders. But there are other practical considerations, so a balance needs to be struck.
    The problem was in the 'old' days of poor CSS support, and standards were relatively new, everyone used what they knew worked to force HTML to support nice-looking design that the original Mosaic designers had never considered, when an IMG tag was a novelty and Tables was for displaying data. The TABLE tag became endlessly nested just to use the padding and layout facilities, ie so things could be spaced and left and right aligned at the same time. In PostNukeBlue100 and others, like PostNuke-V, I've used a CSS technique that makes using tables just for alignment of 2 elements on a line redundant (the "more" links etc at the bottom of news articles). I refined it a little more, can't remember if it's in the current PNBlue100.
    Similarly, as you can see throughout PostNuke, tables are endlessly and needlessly nested. For instance, the OpenTable functions use TWO tables just to render a border and apply a bit of padding! In the days of NN4, that was necessary for compatibility, but irrelevant now. Nobody codes for Netscape 3 or Lynx anymore either. I use a simple DIV with a stylesheet declaration for border and padding. Far cleaner. Especially when you consider how often the Opentable function is called. And as it is modularised, each block etc adds its own tables, with the result of Table overload. And then they often use 3 tables where one will do, like one for the Header of a block, one for the Body, and one for the Footer of the block. Often a simple SPAN or DIV will do. Apply a class to it while you're at it, so people can style it later if they so wish, without affecting every other heading throughout the site.
    So, it's a question of moderation. You need a Table to do blocks that have graphical borders, especially if it needs to be flexible (block content may stretch it, Centre blocks need to fit to the screen). Tables with their rigid structure that doesn't allow overlap of cells is perfect for this. Also, the basic layout in the Theme is perfect for a Table (for a Column layout, anyway). Then you don't have to worry about overlapping DIVs and columns overlapping the footer. You may have noted I use a simple table in the theme, which DOESN'T include the column spacing, with LeftColumn, CenterColumn, and RightColumn IDs. Then not only can I apply the margins between the blocks here in CSS, I can for instance use this in stylesheets to apply style to a heading in the Right block only (hover style, for instance), and not the Centre. Moreover, the heading and content of the blocks has its own class, making customisation easier without affecting everything else with a generic PN-title class. Also, I can apply it to PN-title where it's in the centre only, not in side blocks.
    With PNBlue100, the centre Article blocks lent themselves to DIVs, because there is no graphical border, same goes for the default PostNuke theme. Compare that to how messy the cludgy code for the old PostNukeBlue was to SIMULATE borders, with 1-pixel cells and spacers etc using I don't know how many nested tables.

    It's a question of the right tool for the right job. There are a lot of instances where a SPAN or DIV, or just applying a class or ID to an element, is much more appropriate. Others, like graphical blocks or basic layout of the page, where a Table is entirely appropriate to keep things together. There's nothing wrong in using the HTML properties in the TABLE tag, either. In fact, I've sometimes found leaving them out and relying on CSS has unexpected results.

    -------------------------------------------

    The No Data thing just happens sometimes, I guess when the database is busy, it won't accept any posts for some time, say 15-60 minutes, then suddenly it's fine again. And yes, it can happen on other sites too, I just figure the site is overloaded at that point in time. I doubt it relates to me having a dial-up connection. I don't have the greatest ISP in the world, either. It just gets damn annoying when you type a reply, and can't post it. Especially when you really wanna finish up and go to bed or something.
  • PS: How's Xanthia progressing? Any timetable for PN 0.8 release?
  • Martin,

    The next release of Xanthia is not too far away - a few issues like these themes and compliant to finish up and Larry needs to finish some further performance tweaks. PN .8 is probably going to be ready around spring for those in the northen hemisphere. My lab site is running .8 so you've already had a brief look. I'm finishing up the users module at the moment as well as re-doing the installer to be more modular.

    -Mark

    --
    Visit My homepage and Zikula themes.
  • One thing I forgot to mention about the Opentable function. Whereas Opentable1, being 100% width, is perfect for a DIV, Opentable2 isn't, as it's meant to fit the content, and the default behavior of DIVs is to stretch to fit its container horizontally, but collapse vertically. There doesn't seem to be any way to make a DIV's width behave like a Table, which is to collapse to fit the content. Hence in this case, although hardly ideal, a single table with a single cell still has to be used for OpenTable2.
    The only core module I know using the OpenTable2 function is the old Stats module, but it seems judging from your site you've replaced that in PN 0.8, so I don't know if it's going to be used at all in PN 0.8.
    I made some minor changes on my copy of PostNukeBlue100 to do with Opentable2. It was using the same style as Opentable1 before, so now I have

    Code

    function OpenTable2() {
        global $bgcolor1, $bgcolor2;
        ?>
    <TABLE class="opentable2" cellspacing="0" cellpadding="0" bgcolor="<?PHP echo $bgcolor1 ?>">
      <TR>
        <TD>
    <?php }

    and I've added a separate opentable2 class in the stylesheet:

    Code

    .opentable {
        border: 1px solid #739FC4; /* $bgcolor2 */
        background: #D4E2ED url('../images/BlueStripeBgrnd.gif');  /* $bgcolor1 */
        padding: 8px;   
        margin: 0px 0px 15px 0px;
    }
    .opentable2 {
        background: #D4E2ED;
        border: 2px solid #739FC4; /* $bgcolor2 */
        padding: 6px 12px;
        margin: 6px;
        margin-left: auto; margin-right: auto;
    }


    I note you've updated the Doctype on your test site to Transitional, and indeed it seems to have solved the display problems. I also note you're not using my right blocks, though, which is fine except the padding is way off, namely there isn't any. Compare these screenshots, the first from your site, and consider the spacing:
    http://users.tpg.com.au/staer/images/Poll1.gifhttp://users.tpg.com.au/staer/images/Poll2.gif
    Also, something to define the back, like the second example, would be good. I believe there was in the original.
  • Currently the right block is a different template - me fiddling with the theme a little....

    The opentable functions are deprecated in .8. None of the core modules will use them. In a xanthia theme they correspond to the table1 and table2 templates.

    For a div of variable width try
    .

    Thanks again for taking the time to post of this info; very useful. As i've said to you before I don't pretend to be a expert in these areas (very much a backend coder....).

    -Mark

    --
    Visit My homepage and Zikula themes.
  • Cool. AutoTheme still uses the Opentable function, hence I mentioned it. Doing it in the template sounds better. Go on fiddle away, that's how we learn. It's gonna be interesting.
    Width: auto would make sense, but no dice (not as much sense as a more descriptive and intuitive value).
    For the sake of reference, this is how they calculate 'auto' on block-level elements:
    http://www.w3.org/TR/REC-CSS2/visudet.html#q6
    Sometimes you wonder how the W3C come up with certain things, and managed to leave other things out that's proposed by the browser makers, both in HTML and Javascript. They have their own internal logic, but sometimes that doesn't make for intuitive behavior.
    I won't pretend to be an 'expert' in these matters either, I'm a hack that picks things up on his travels, but then in IT and (web)design (and many other fields) 'expert' is relative. There's always an Ubergeek that knows more than you, and there is an awful lot to know. I prefer to have an application write valid code for me (all those metatags), and tweak it by hand, ie using Dreamweaver in split-screen mode, as I'm a visual person. (Dreamweaver still is not good with DIVs, so that has to be done by hand anyway). But like a designer said, I think on A List Apart, he was a generalist with a good knowledge of both coding and design, but not as good as some in either, hence when faced with competition for clients against designers, emphasized his knowledge of coding to get the upper hand, and when faced with coders, emphasized his knowledge of design. I suspect your knowledge of DHTML/XHTML is vastly improved over the last few months trying to hammer PN 0.8 together and making it well-coded and standards-compliant to boot. You'd know a bunch about CSS you didn't know before. That makes you a good allrounder, a good thing to be when going for that lucrative job interview against coders that may be as good or better than you, but know little about web design and HTML/CSS.

Go to page [-1] 1 - 2:

This list is based on users active over the last 60 minutes.