(9 replies, posted in PunBB 1.2 troubleshooting)

Connorhd wrote:

This is Green!

No it isn't.  tongue


(76 replies, posted in News)

Connorhd wrote:

you can't test the size of the image

Sure you can!  (well, you can check it with javascript)  Check out the javascript I posted above.

That script, btw, could just as easily be adapted to display a hyperlink instead of the image based solely on the width of the image.


(76 replies, posted in News)

Paul wrote:

roo: the problem isn't big images breaking the boards layout. If the board is on a page on it's own thats not really a problem. The problem is when the board is integrated into an existing layout e.g. it is the middle column of a three column layout. Then it would blow the whole site apart.

ah, I see.  You guys are far more thoughtful than I'd be.  That never would have occurred to me.  yikes


(76 replies, posted in News)

I haven't seen minmax.js, but another javascript alternative that will work would be this:

//shrink any in images div#punviewtopic greater than 500px to be 90% wide
function handleImages() {
    if(!document.getElementById('punviewtopic')) return;
    var pics = document.getElementById('punviewtopic').getElementsByTagName('img');
        for (var i = 0; i < pics.length; i++) {
            if(pics[i].width > 500) {
                pics[i].style.width = "90%";    

It just checks for div#punviewtopic, and if it's there, it shrinks all images within it to 90% wide of its parent element.  It only shrinks images that are more than 500px wide so smilies and avatars will not be affected.  Only images larger than 500px will be scaled.
Run the script when the page loads, and it'll do the magic.  It's a pretty simple, W3C DOM comliant solution. Although, again, it may not be as sophisticated as you're looking for.

edit:  and if the [ img ] tag just slapped in an <img> tag instead of wrapping it up in divs, you could change that if statement above to read:

if(pics[i].style.width > pics[i].parentNode.style.width) and it would be even smarter than just specifiying a pixel width.


(76 replies, posted in News)

I think if the board's admin allows images, then the board's admin should be aware of the pros and cons.

If it were up to me, the [ img ] tag would just create an <img> tag, and if the layout breaks on a thread where people post desktop pics, so be it.  It's not like it makes the page less usable, it just makes that person's post ugly.

Offering up php, javascript, and css solutions is fine, but I think its extra credit.   I'd leave the image issue to those who use images.  I've seen images used on many, many message boards, and having large images stretch the page is a pain, but having a single image overflow from the layout doesn't bother me a bit, I can skip past it.

Perhaps not as elegant as you were looking for, but it's definitely less bloat.


(76 replies, posted in News)

The new mark-up hooks are welcomed with open arms!  w00t!


(15 replies, posted in Feature requests)

Oh please, no!

There's not any need at all to alter the structure of the <h1>.  .punwrap h1 {} will isolate it, as will .brdtitle h1 {}

Also, I don't think in-line styles are ever a good idea, and I can't remember where, but I did encounter one instance of an inline style.  I think that all style should be separated from content so that extermal CSS can do its job without interference from style attributes.  That includes mods.  If someone creates a mod and applies inline styles to make it match Oxygen, then it's more difficult to make it look right in other themes -- or boards with user-selectable themes.

px is the most logical choice for screen sizes.  It's also easiest to use.

The reasons for using ems or percentages or other relative measurements are two-fold:  WinIE can resize text set in relative sizes but not type set in pixels (when the user chooses to alter the font size for better readabiliy); and fans of elastic design that want the entire layout to enlarge and shrink when the user switches font-sizes use relative sizes like ems.

I recommend pixels to people learning CSS because it's easiest to understand, and because they don't inherit their values.  That is, if I make the body 12px, and <p> tags 14px, then all <p> use 14px type.  If, however, I set the body to .7em and <p> to 1em, the <p> is 1em relative to its parent (the body) so it renders at .7em.  That can get very confusing if you have nested elements with different font sizes in ems.


(26 replies, posted in PunBB 1.2 bug reports)

I don't see the peekabo bug anywhere Paul... some margins vanish and what not, and most of the rollovers aren't fancy in WinIE, but I don't see any obscured content.  Is there anywhere in particular you that you noticed it? 

And the default font size might be a touch small, it's noticed more among the Mac crowd probably because we typically use higher screen resolutions.  The actual size in pixels, however, is absolutely identical on both platforms.


(26 replies, posted in PunBB 1.2 bug reports)

oh... I thought I nabbed that one... I'll dig back into it and seek it out.  Thanks for the heads up.   There's a lot of little things that need attention in that theme, I'll add that to the list.


(26 replies, posted in PunBB 1.2 bug reports)

Paul wrote:

Just thought you should know, MaxAttack is broken in IE6, not that users of desktop iPods would be much concerned smile

I just popped in to the MacAddict forums. They say criticism builds character. My character is now well and truly built.

Broken?  I understand that's it's pretty funky in IE, but I didn't think it was broken...

But given the scope of the site (MacAddict) and the age of WinIE, I don't mind that IE can't render it properly. 

Oh, and as for the criticism, they do that whenever anything changes.  Don't let it get to you.   Actually, I'll put that a better way:  Ignore the whining, only listen to constructive criticism.  That weeks about just about all of the comments right off. smile  (I go by registered_user over there, btw, and I'm no stranger to them whining about stuff and calling it constructive.)


(26 replies, posted in PunBB 1.2 bug reports)

Will do.  It might not be until later this week though.  I'll be as speedy as I can.


(26 replies, posted in PunBB 1.2 bug reports)

Tell you what...  If you'd like, I'll happily go through some of the pages and make notes on how I'd do things, and pass that list along to you.

I think that some of the mark-up could be trimmed down, but having extra wrappers in there is a real boon to designers.  What if the designer wanted to put a shadow around each post?  Or come fancy image as a border?  As it is now, you leave open many options to the designer and that's a very good thing.  But there are perhaps a few things that I'd do differently.

I won't presume to know the mark-up or the forum as well as you do, but I'd be happy to share what I came across when trying to come up with a theme that relied more heavily on images.  From there you could go through it and implement that which you like and trash what you don't like.

I figured I'd e-mail it to you, but I can put it in a thread too if you'd prefer.


(26 replies, posted in PunBB 1.2 bug reports)

If there is a work-around using those classes, I can modify the css to that theme.  smile


(17 replies, posted in Programming)

Yup, it's the clear:left that does it.

If there's one bit of advice I can offer when it comes to working with CSS it's to keep it as simple as you possibly can.  It's easy to get very complicated very quickly with CSS, and it tends to cause trouble when you do.  smile


(17 replies, posted in Programming)

Paul wrote:

The difference in the way they line up is because Gecko calculates the top margin of box1 from the top of main not the top of the screen. I had that problem with profile and admin. The way around it is to put a wrapper div around the whole lot and give that a top margin instead.

For you next exercise buzzkill put main before the floats in the markup and give the left column a full height background colour.

Good info!  There's another way around that, however, that doesn't require an extra div.

Set the margin-top to both #navBox1 and #main to 0, and set the body to have padding-top of 12px.  The body itself is, afterall, just another container.  smile


(12 replies, posted in PunBB 1.2 discussion)

the section of mark-up is here:

<div class="linkst">
    <div class="inbox">
        <p class="pagelink conl">Pages: <strong>1</strong></p>
        <p class="postlink conr"><a href="post.php?tid=5955">Post reply</a></p>
        <ul><li><a href="index.php">Index</a></li><li> » <a href="viewforum.php?id=40">PunBB discussions</a></li><li> » Changing the layout</li></ul>

        <div class="clearer"></div>

to make it look like you're after, I think you'd need something like this (mind you I haven't tested it, and it's probably going to require some fiddling to get it right):

.linkst .inbox {
position: relative;

height: 36px;
.linkst .inbox p.conl {
position: absolute; 
right: 0; bottom: 0;
.linkst .inbox .conr {
position: absolute;
bottom: 0; left: 0;
.linkst .inbox .conr a {
margin: 0; padding: 0;

.linkst .inbox ul {
display: block
text-align: left;
margin: 0;


(17 replies, posted in Programming)

I second Paul's suggestion of using floats.  There's also no need for an extra div (though I'd probably use one for simplicity).  Anyhoo, I whipped up a quickie version of the basic layout you are talking about.   You will notice that both of the nav divs are given float: left, and the bottom one is given clear: left as well.  That forces it to fall under the first one.  You'll also see that the first nav div gets a 20px bottom margin like you mentioned.

Is your server running Apache and do you have access to .htaccess?  I'm no expert on it, but I think that adding this to your .htaccess file would do it:

RewriteCond %{HTTP_REFERER} !^http://www.yourdomain.com/.*$ [NC]
RewriteRule .* http://www.yourdomain.com/login/ [R,L]

It basically says that anyone coming from an address that isn't http://www.yourdomain.com/ is automagically sent to http://www.yourdomain.com/login/

It may or may not work, I'm not really that knowledgeable when it comes to this stuff.

Rickard wrote:

The easiest way would be to include the style author bit in a small PHP script. E.g:


$style_author = 'George W. Bush';
$style_url = 'http://www.whitehouse.gov/';


and then name it style_author.php or something.

While I'm not excited about your choice in authors tongue , a standard little php file with variables like that would be excellent.  Though I do agree with Frank H, and that $style_name should probably be included as well.

$style_name by <a href="$style_url">$style_author</a>

I thnk that's about all it'd take.  Granted it could be fancier, but I think it would go against the simplicity otherwise found in punbb.

sah-weet!  cool

Re: designer credit:  FWIW, I am using :after and content to get my credit on there, but a means to parse html might be nice (to generate a link is what I had in mind).  CSS generated content isn't parsed.    I suppose it could be well argued that it's bloat, but on a fundamental level, it's no more bloated than having the existing credits. wink

Paul wrote:

It's not part of the markup. The menu separator is in the language file. It's also there for the main menu though it's invisible by default. You can change it to '' instead of ' | '. The point is somebody might want to use some other symbol as a separator which you couldn't replicate without using a graphic.

Now that's some good info!  You guys are a step ahead of me!  I'm still a bit concerned for boards with different themes, but there is mostly a workaround with css if need be.   That bar could be added with :after on modern browsers, but IE has no recourse.  I suppose that the Administrator could put <span>|</span> in the language file as a workaround for boards with multiple themes, but that doesn't lend itself very well to theme designing in such a way that themes can be installed on any punbb forum.

Paul wrote:

From as design point of view I do see your point, it's just that it feels like overkill for PunBB. I assume you used li + li.

Actually, I didn't use li+li.  The problem is that you can't be sure where a given list item will appear because of delete and edit are different depending on a user's permssions.  I used:  .postfootright li a[href*="delete.php"]:hover  I'd bet that it won't show up for WinIE because it's a few years behind in its standards support, which I can live with, but just thought I'd bring it up.  Though, on some level, it's kind of satisfying to know that WinIE users are missing out.  I feel like I'm donig my part.  :evil:

But seriously, without an identifier added to those links, there's not a way in the world to style those links individually in WinIE.

Paul wrote:

It's not nitpicking, it's refining. Even though PunBB is at version 1.2 the markup and css is really at version 1.0 so there are bound to be improvements that can and should be made.

Very cool.  And for a version 1, you're doing quite well.   Two thumbs up from me!

edit:  on a side note, I'm 25% 1337 because my postcount is 7.  big_smile

edit again:  There's another mark-up bit that's peculiar.  When a user is logged out you get an nbsp in:

<div class="linkst">
    <div class="inbox">
        <p class="pagelink conl">Pages: <strong>1</strong></p>
        <p class="postlink conr"> </p>...

That one is kind of a thorn in my side because I'm using the <p> to house the left end of a rounded corner button, and the <a> to hold the right half (the text is the wording on the button).  But when the user is not logged in, you see just the left half because the nbsp; makes the <p> tag appear even though it's technically void of content.

Oh, you know, I had another thought:  If you do choose to have a style directory structure, it might be a nice touch to have the forum parse a very simple text file (included in each theme, and given a certain name and location in the style directory) to give the designer a little credit in the footer somewhere.  The text file might even be just one line, or parsed down to the first 256 characters to prevent it from being abused.  It would be a nice little nod to theme designers to have a means for them to place a small link on the bottom of the page like they can with that other forum.

Re: markup

I don't mean quirks as a bad thing, the mark-up is actually quite nice.  But there are a few areas that I find peculiar, and that's why I say "quirky."

For example, the use of non-breaking spaces.  In the <dd class="usercontacts"> there are nbsps insterted before the web address, and I'd think that semantically they might be separate definitions, but at the very least, the nbsp needn't be there, some margin or padding would do the trick just as well. 

Along the same lines, it's remarkably helpful to stylize links when either the enclosed text is wrapped in its own span or the link is wrapped in its own container.  The end result allows a designer to use the technique popularized by alistapart's sliding doors article.  I've only created one skin (and it's in progress, I'll let you know when it goes live) and I've found that most links are able to be styled with the sliding doors approach since most are in lists or other wrappers, but user contacts is a notable exception.

here's another that I find quirky:

        <div id="brdwelcome" class="inbox">
            <p class="conl">Logged in as <strong>roo</strong><br />Last visit: Today 12:50:10</p>

            <div class="clearer"></div>

I think the break tag in that passage should be removed and instead have the Last visit part be wrapped in its own container.  A span or even its own paragraph.  It's workable, however.  I was able to single out that break and apply display: none; to it, but it is quirky to have a break tag sitting there for reasons that appear mostly presentational. 

I find it a little odd that there is a bar | between Report, Quote, etc.  I don't feel that it should be a part of the markup as it requires a designer to remove it if they choose an alternate means of styling that link.  The same effect can be achieved by adding border to one side of each list item, and by adding a class to either the first or last item in that list to which there is no border applied.

Also, it might be a nice feature to identify individual links.  The main nav might get an id on each <li> like <li id="index">, <li id="userlist">, etc.  The list at the bottom of each post might also be given classes <li class="report">, <li class="quote">, etc.  As it is now, I've applied different styles to each link by using css selectors that aren't supported in WinIE.  Not that I particularly care about WinIE, but having identifying attributes on those list items would make styling easier and more flexible.

Again, as it is, the markup is very workable, and the tags and classes are very well thought out and applied, but these are a few things I encountered.  Overall, it does a bang-up job of giving a designer everything he needs to style the forum, and again, I was able to work past nearly every one of these issues.  I didn't want to get into it earlier because I feel that I'm largely nit-picking, but you did ask.  wink


I'd still really like to have odd and even classes added to the topic list and forum list <tr> tags.  The thread view has .rowodd and .roweven, but the topic view does not.  It would permit alternate row colors in most browsers which do not support the CSS3 selectors that are otherwise required to pull this off (feasibly).

I've got one other request.  In the help page of 1.2, the img tag description automatically goes to images/themeName_new.png, I think it would be nice if pointed to style/themeName_images/themeName_new.png, or something of the like so that styles can be completely self-contained.  That's minor, I realize.  But it would lend itself well to people making themes so that a standard folder structure could be implemented and new themes would be ftp and go.

While I'm making a wish list, wink  I think support for a [list] tag would be nice, though it doesn't get used nearly as often as it should. 

All in all, I'm thrilled with the software.  It's very nice, and while I think the new markup has a few quirks here and there, I'm pleased overall.  Pat yourselves on the back for a job well done.

Thanks for the reply.  If it's just database differences, I'll try to squash them as I go.