Brainstorming: What do we "need" template-wise?

[Don Chambers]

Other than that, I don't see anything left to do despite check the whole thing for double or unnecessary classes and ids (sounds like a job for Don )
YL

How did *I* get stuck with that?!!!!

Seriously - regarding dulpicate names, I cannot find any rule that says you cannot have both a class and an ID with the same name. IDs are meant to be unique to a page, classes can be used multiple times, but I find nothing on using the same name for both. In fact, I think a specified ID of ID="foo" will default to the class of .foo if the id of #foo is missing from the stylesheet.

Anyway, it is STILL confusing to have the identical name, so I personally think it should be changed. The only place I observed it was with respect to the comment, and related, tpls. And trust me, I have been over every single line of each of those TPLs dozens of times - unfortunately!

As far as "unnecessary" - that is pretty subjective. More classes is always better than less. I have yet to find anything unnecessary, or at least, anything "in abundance". There are scores of classes I have never seen styled, but you never know what might be of interest for some future template.

So, I suggest 1) disregard any classes that might be "excessive", or "in abundance" and b) focus just on these few instances of identical ID and Class names.

Does anyone have any examples OTHER than the commentform, and related tpls?

Again, how did I get stuck with this job?!!!

[d_cee]

Hi Guys

good to see how busy you've been in my absence

I'll download the zip later when I've time and check everything in Safari and FF mac - I've a lot of catching up to do everywhere!

Oh, and I'm sure the right sidebar margin was caused by a float left as I corrected it with a float right in a colourset I was working on before I was sick.

cheers

Dave

[yellowled]

Does anyone have any examples OTHER than the commentform, and related tpls?

Again, how did I get stuck with this job?!!!

a) No, I don't - but then I haven't really checked That's probably something to spend this afternoon on

and b) Well, you've proven to be efficient at it

As far as I have researched, having the same name for a class and an id is fine, but you're right: it's not beautiful. So we should probably check for those.

YL

[yellowled]

good to see how busy you've been in my absence

Welcome back, Dave

Oh, and I'm sure the right sidebar margin was caused by a float left as I corrected it with a float right in a colourset I was working on before I was sick.

Please check it anyway. Someone has contacted me via email reporting a problem with the yl15 template, which is basically the same as bulletproof in terms of basic layout.

He reported that in IE7/Win, the right sidebar is displayed below the content. I've just asked for more details (screen resolution etc.), and I haven't heard about something like that before, but it's certainly worth checking out.

Also, I've decided not to update the sandbox to v1.2 at all. It was meant to be temporary in the first place, the new xml icon class already works for the categories plugin, the other plugins work in my devblog, you guys have your own dev blogs ... so why put up with the hassle of updating the sandbox?

So let's check Stage 1 of my todo list:

1. Accessing the blog without saving the options first: I don't see how to solve that. Plus, I'm sorry, but I think that's just user failure. We can't bother to foresee every possible mistake users might make.

2. Safari float issue: If it's fine now, fine

I'm gonna check for some of those abundant and/or double classes/ids now.

YL

[yellowled]

I almost forgot about these:

1 - we should set all the calendar background colours to inherit
2 - we should set the theme chooser select to 90%

Dave, could you give me a list of the calendar styles and also the relevant classes or ids for the theme chooser? I know I'm being lazy, but this spares me to install the theme chooser in my dev blog ...

Thanks,
YL

[d_cee]

Hi YL

Up late tonight!
the calendar code is just these

Code: Select all

table.serendipity_calendar {
   text-align: center;
   background-color: transparent;
   height: 150px;
   width: 98%;
}

.serendipity_calendarHeader {
   background-color: transparent;
   vertical-align: middle;
   font-weight: bold;
}

and the template chooser

Code: Select all

#theme_chooser select{
width: 90%;
}

[yellowled]

Up late tonight!

Yup, pulling a graveyard shift

the calendar code is just these

Ah, thanks. I thought it would require new ones, slight misunderstanding. Maybe I should get to bed. Will do

YL

[d_cee]

Hi YL

I checked out the new zip in Safari - the sidebar right margin problem is worse now I'm afraid, although on the bright side I haven't found any other problems (yet). The right margin margin appears to be 49px on a fixed width of 970px and it's the same in FF 1.5 mac.

I've posted safari screengrab http://www.daves.me.uk/images/Bulletproof.jpg

catch you later

Dave

[Don Chambers]

OK - I reviewed the files for the dulpicate ID/class issue. The offenders I have located are comments.tpl, commentform.tpl, plugin_contactform.tpl and plugin_dynamicform.tpl. Ultimately, what it amounts to is ONE conflict of a class name being the same as an ID. There is ONE that is REALLY close, and in general, lots of similarity to the point of confusion.

Near identical class of serendipityCommentForm and anchor id of serendipity_CommentForm (underscore being only difference:
COMMENTS.TPL:

Code: Select all

<div id="serendipityCommentFormC" class="serendipityCommentForm">
<div id="serendipity_replyform_0"></div>
<a id="serendipity_CommentForm"></a>

PLUGIN_CONTACTFORM.TPL and PLUGIN_DYNAMICFORM.TPL:

Code: Select all

<div class="serendipityCommentForm">
<a id="serendipity_CommentForm"></a>

Identical use of class and ID:
COMMENTFORM.TPL, PLUGIN_CONTACTFORM.TPL and PLUGIN_DYNAMICFORM.TPL: - form id of serendipity_comment:

Code: Select all

<form id="serendipity_comment" action="{$commentform_action}#feedback" method="post">

COMMENTS.TPL: - first class defined is also serendipity_comment:

Code: Select all

<div id="serendipity_comment_{$comment.id}" class="serendipity_comment serendipity_comment_author_{$comment.author|@makeFilename} {if $entry.author == $comment.author}serendipity_comment_author_self {/if}{cycle values="comment_oddbox, comment_evenbox"}" style="margin-left: {$comment.depth*20}px">

Option 1: Do nothing.

Option 2: Change form ID to serendipity_comment_CommentForm. At least in CSS, it becomes pretty obvious the tag is for the form, not the individual comment.

Option 3: (still minimal effort): In addition to option 1, also change anchor class of serendipity_CommentForm to serendipity_CommentForm_anchor. Not really sure that is necessary as I have yet to encounter a template that bothers to style the anchor, but once again, it is pretty obvious what it is should it ever appear in css.

I wonder why the form has an ID at all, unless it is either required, or to prevent a general "form" tag in css from affecting this particular form. Another inconsistency is comment.tpl's use of both an ID and a class while the other 3 tpls use only a class. I suppose "Option 4", COULD be to take a closer look at that, and unify the 4 tpls with one method or the other. Despite my numerous other changes, now incorporated in BP, I have not changed any of the tpls for this issue - wanted to run it past another few pairs of eyes first..... either that, or YL can do it when he finishes his next graveyard shift!

[yellowled]

I checked out the new zip in Safari - the sidebar right margin problem is worse now I'm afraid, although on the bright side I haven't found any other problems (yet). The right margin margin appears to be 49px on a fixed width of 970px and it's the same in FF 1.5 mac.

Hmpf. So what is it exactly we're talking about - it's not the two white margins on the left and right, it's the fact that the red sidebar doesn't extend to the right completely, right? How did you style that exactly?

I'd also like to check how the same stylesheet looks in other browsers, is this online yet?

YL

[yellowled]

Option 2: Change form ID to serendipity_comment_CommentForm. At least in CSS, it becomes pretty obvious the tag is for the form, not the individual comment.

Option 3: (still minimal effort): In addition to option 1, also change anchor class of serendipity_CommentForm to serendipity_CommentForm_anchor. Not really sure that is necessary as I have yet to encounter a template that bothers to style the anchor, but once again, it is pretty obvious what it is should it ever appear in css.

This anchor is not even meant to be styled. It's meant to be used as kind of a skiplink so visitors can be directed to the form directly since there's other content (article, comments, trackbacks) on the entry page.

That's why I think we shouldn't touch anchor ids at all. It might break vital features of s9y. That's not what we want to do

... either that, or YL can do it when he finishes his next graveyard shift!

Hrm, that would be in about ... 4 hours. Thank God I'll probably at home waiting for calls on the cellphone, so I can hopefully get some work done now

So, I say we go with option 2. I have included that and all the other stuff (hopefully) from the past few days in yet another zipfile. Sandbox has been updated, too - with the latest BP snapshot, not with a v1.2 snapshot.

This pretty much leaves us with solving that Safari issue ... although I have to admit I have not run any excessive tests on this for quite some time other than checking it in FF2 and Opera 9, which are probably the 2 browsers least likely to present any problems

YL

[Don Chambers]

OK - option 2 is under consideration as I agree with leaving the anchor class alone, although not for the same reasons (the class should have nothing to do with what is being emitted by s9y, right?!)

Anyway, that leaves my final point open:

Another inconsistency is comment.tpl's use of both an ID and a class while the other 3 tpls use only a class. I suppose "Option 4", COULD be to take a closer look at that, and unify the 4 tpls with one method or the other.

[yellowled]

OK - option 2 is under consideration

No, it is already in the latest zip

Another inconsistency is comment.tpl's use of both an ID and a class while the other 3 tpls use only a class. I suppose "Option 4", COULD be to take a closer look at that, and unify the 4 tpls with one method or the other.

Oops, overlooked that one. Anyway, it's not 4 tpls in our case, it's 3 - we don't have a comments.tpl. I think it's perfectly fine not to have one, but I'm not sure what id="serendipityCommentFormC" is for anyway ..? Plus, I don't really know why we need id="serendipity_replyform_0", so I guess I'll just comment those out for the time being.

I also made some changes to the style.css to adjust to Don's latest changes to the contact form. No harm, no foul - just some small adjustments needed to make it look like it's supposed to again

So, time for some bad news.

I ran some tests on this under Win/XAMPP/1024x768. Firefox 1.5, Firefox 2 and Opera 9 look fine as expected. However, the IEs ... let's put it this way: IE7 looks fine with a little fix (it needs the ie.css), which is great. If I was doing a template just for my blog, this would suffice. However, that's not the case, so maybe we need some fixes.

IE 5.5 doesn't work - the right sidebar is displayed below the content column. I think we can neglect that. However, IE 5.01 and 6 have the same issue, depending on the width of the browser window. It looks fine in 1024x768 on my Win machine, but once you start dragging the browser window, the right sidebar 'jumps around' - can't describe it any better, one time it's at the right place, 2px more, it's not.

This is weird, but I seem to remember we had that before with another template. It's too bad Carl isn't around much, he would remember this.

The obvious solution for this would be to have extra stylesheets for IE7 (turning ie.css into ieseven.css) and IE <= 6 (oldies.css sounds nice ). That way, we could assign fixed widths in px for IE <= 6. At least that's what came to my mind. If you guys have a better solution, shout it out

YL

[Don Chambers]

IE 5.5 doesn't work - the right sidebar is displayed below the content column. I think we can neglect that. However, IE 5.01 and 6 have the same issue, depending on the width of the browser window. It looks fine in 1024x768 on my Win machine, but once you start dragging the browser window, the right sidebar 'jumps around' - can't describe it any better, one time it's at the right place, 2px more, it's not.

That behavior is extremely common in any of these templates that float the various columns.

Try this for serendipityRightSideBar: float: right; clear: right;

Looks to be a few other issues as well, let me see what I can come up with.

EDIT: Besides what I mentioned above, I noticed that the banner was also shrinking at a point, and had the same right margin problem that Dave pointed out. I think I found the cause - setting font-size: 75% in #wrapper. Take it out there, and set it for the content and sidebars instead.

Oh - one other thing - looks like I am no longer Owen Stubbs!!! I asked Garvin to switch my name to my true name, not that it is any more exciting, just thought it might be less confusing in the future!

EDIT AGAIN: Is it really necessary to have BP require 1.2? I am not running that on my test blog (neither is your sandbox), which means I cannot switch to it for testing unless I edit the code. Is there anything in there besides the icon swapping specific to 1.2?

[yellowled]

That behavior is extremely common in any of these templates that float the various columns.

Try this for serendipityRightSideBar: float: right; clear: right;

I'll try that later tonight when I get back home.

EDIT: Besides what I mentioned above, I noticed that the banner was also shrinking at a point, and had the same right margin problem that Dave pointed out. I think I found the cause - setting font-size: 75% in #wrapper. Take it out there, and set it for the content and sidebars instead.

Hm, I'm wondering whether we need this at all. Dave asked for this, as far as I remember to make it easier to style something ... Edit: It was for the original contact form, so we could leave it out altogether. Personally, I'd prefer that, especially since it's a template framework.

EDIT AGAIN: Is it really necessary to have BP require 1.2? I am not running that on my test blog (neither is your sandbox), which means I cannot switch to it for testing unless I edit the code. Is there anything in there besides the icon swapping specific to 1.2?

No. You can simply edit the last line in the info.txt to make it work (1.1 instead of 1.2) in your test blog. And you're right: if the icon swapping isn't used, this runs on 1.1 as well.

YL