First, the centering of the text and everything- I removed that code. Everything except for the images should be always aligned to the left. I kinda like the images with the float removed and centered as the width narrows, but I will entertain any new ideas that you have of scaling the images.
Secondly, the error message shortening/heightening feature. I put in the styles directly from your upload. The buttons still appear outside the box at the beginning, and the error message border is still there, even though the <p> element is empty initially (no error has been output). When the error is output, the buttons may only move about 20px down. We may have a misunderstanding on this. The JavaScript does not change the display property of the error message box, but I did add that into the script to change it to block display when an error is output. It still does not achieve the desired effect.
Third, the animation does do well at all widths. The rows adjust nicely, but you said you noticed a glitch. I’ve seen nothing I’m dissatisfied with on the footer row.
(1) The text looks better to me. The top two centered images look OK, the last one seems to waste space, however it is centered like the other two, so it gets a pass.
(2) This link displays an image of what I see in Firefox. Buttons beneath the form; box for error message visible and text that I added visible; buttons move down as little or as much as is needed to accommodate the error message and its box. No misunderstanding about the JavaScript… you have to add a line of JavaScript to remove display:none or apply display:block, however you do it, at the same time the submiterror text is applied for that part of the feature to work as intended.
Please post a screen shot if what you see is different than what I see.
You’ll have to explain/describe what the desired effect is that you are not seeing. I don’t know what that is.
(3) The animation looks good to me. Earlier, you had described a sliding effect for the e-mail error tab, but I see you have implemented a dissolve effect instead. It seems a little slow, but looks great.
The “glitch” that I observe has to do with the transfer of the items in that row from horizontal to stacked. I’ll have to look at it again before I can offer a recommendation.
I believe our misunderstanding is what the effect is supposed to actually do when the error text is sent back. I thought the buttons are supposed to be initially positioned inside the graphic, and then moved down 100px or so to be underneath the graphic when the error text appears. In actuality, what I think you mean is that the buttons are underneath the graphic at all times and just move down about 30px when the error appears. Yes, I see the submit buttons there in my browser as it appears in your screenshot.
Yes, just like the left two screen shots in post #29. The position of the buttons remains below the #submissionform; however, if an error message is triggered, a space for the error message is opened up within #submissionform, thus pushing the bottom of #submissionform lower along with the buttons beneath it.
Do you see on your PC the same behavior that is shown in the screenshots?
and
Is that satisfactory?
Aside: I never considered positioning the buttons inside #submissionform initially, then moving them below #submissionform if an error were triggered. That strkes me as an unexpected change in the “look” of the form that might annoy users. It didn’t cross my mind.
Yes, I do see the same behavior as post #29. You may check the test page to see for yourself. I believe this is satisfactory and a useful feature.
Now, I’m wanting to know if you have any other ideas before I start copying this HTML over into my 30 or so already-existing landing pages. I already did that once, and now I’ll have to do it again. It is a very time-consuming, tedious task, and I would hate to have to do it all over again if you don’t think the site should go live quite yet without a couple of other tweaks.
In a previous post, you had mentioned an idea of how to scale images more efficiently. The other idea was to abolish #lpfoot and move the mailing list box and nav links up into #lpcontent.
With the image scaling, I don’t think that every image should have a scaling effect, which would change the way it’s coded. A lot of the images are very small.
OK, good. Just want to be sure we’re on the same page.
It’s an idea ahead of its time. Although I still believe that centering the smaller images creates wasted white space, the page is OK as it is. I don’t have a better solution, yet; just the belief that one exists. Don’t wait for this one.
Understood and Agreed.
No! Not my idea! You’ll still need a container for the “footer” stuff (mailing list form and links), so you may as well leave it named the way it is. There is nothing wrong with “#lpfoot”. The ID sounds odd because in your first, non-fluid design #lpcontent and #lpfoot were peer-level containers. In this new fluid design, #lpfoot is nested within #lpcontent as it should be now. There is no need to change the idname of #lpfoot unless you just don’t like the idname! Again: #lpfoot is already inside #lpcontent. There is nothing to move!
Understood. I can relate to “time-consuming” and “tedious”. My pet peeves are rework due to: poor planning (or poor descriptions of wishes) or rushing to get something out the door too soon. … time consuming.
I don’t see anything significantly wrong with the current design, except an accessibility issue with the stuff in the footer. When text-only is zoomed significantly larger, the layout “breaks”.
In the interest of expediency (bread and butter) you can certainly publish the site as it is and the majority of users will be satisfied. Those who are visually impaired and zoom text-only larger may have a problem in the footer, though. If you publish now, I would recommend continuing to improve the footer boxes and being willing to publish “version 2” after the footer is redesigned to be more accessible/zoomable.
This is “Proof of Concept” code for a fluid “call2action” box based on the images in your original design. This demo code expects the background-colors added to the image containers to be visible instead of images.
As it sits, it would require 9 individual images for :link and 9 more for :hover.
However, by using sprites, one can reduce the number of images required to 5 total.
Tested in IE8+, FF, Opera, & Chrome.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<!--
Another fluid image-based container. Proof of concept. Colored boxes represent image segment containers.
9 image background; 18 images with :hover; OR 5 (maybe 6) images total if sprites are used (recommended!)
This arrangement attempts to add fluid symmetry to a not-so-symmetrical fixed image design.
IE8+, FF, Opera, Chrome.
-->
<head>
<title>call2action Colors 5c</title>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<meta name="viewport" content="width=device-width">
<style type="text/css">
html,body {
padding:0;
margin-:0;
}
body {
background-color:#555;
}
#call2action {
display:table;
position:relative;
margin:0 auto;
}
#call2action .tl,
#call2action .tr,
#call2action .bl,
#call2action .br {
position:absolute;
width:20px;
height:50%;
}
#call2action .tl {
top:0;
left:0;
}
#call2action .tr {
top:0;
right:0;
}
#call2action .bl {
bottom:0;
left:0;
}
#call2action .br {
bottom:0;
right:0;
}
#call2action .tcl,
#call2action .tcr,
#call2action .bcl,
#call2action .bcr {
position:absolute;
height:20px;
}
#call2action .tcl {
left:20px;
right:50%;
top:0;
}
#call2action .tcr {
left:50%;
right:20px;
top:0;
}
#call2action .bcl {
left:20px;
right:50%;
bottom:0;
}
#call2action .bcr {
left:50%;
right:20px;
bottom:0;
}
#call2action .mid {
position:absolute;
left:20px;
top:20px;
right:20px;
bottom:20px;
}
#call2action .tl {background:#8f8 url('imgs/tl.gif') no-repeat left top;} /* top left */
#call2action .tr {background:#8cf url('imgs/tr.gif') no-repeat right top;} /* top right */
#call2action .bl {background:#fb8 url('imgs/bl.gif') no-repeat left bottom;} /* bottom left */
#call2action .br {background:#f8a url('imgs/br.gif') no-repeat right bottom;} /* bottom right */
#call2action .tcl {background:#faf url('imgs/tcl.gif') repeat-x left top;} /* top center left */
#call2action .tcr {background:#ffa url('imgs/tcr.gif') repeat-x right top;} /* top center right */
#call2action .bcl {background:#aaf url('imgs/bcl.gif') repeat-x left bottom;} /* bottom center left */
#call2action .bcr {background:#8ff url('imgs/bcr.gif') repeat-x right bottom;} /* bottom center right */
#call2action .mid {background:#fff url('imgs/mid.gif') repeat 50% 0;}
#call2action:hover .tl {background-image:url('imgs/tl-hover.gif')}
#call2action:hover .tr {background-image:url('imgs/tr-hover.gif')}
#call2action:hover .bl {background-image:url('imgs/bl-hover.gif')}
#call2action:hover .br {background-image:url('imgs/br-hover.gif')}
#call2action:hover .tcl {background-image:url('imgs/tcl-hover.gif')}
#call2action:hover .tcr {background-image:url('imgs/tcr-hover.gif')}
#call2action:hover .bcl {background-image:url('imgs/bcl-hover.gif')}
#call2action:hover .bcr {background-image:url('imgs/bcr-hover.gif')}
#call2action:hover .mid {background-image:url('imgs/mid-hover.gif')}
#call2action a {
display:block;
position:relative;
z-index:1;
padding:20px;
}
#call2action a:link,
#call2action a:visited {color:#009;text-decoration:none;}
#call2action a:hover {color:#fff;}
#call2action a:active {color:#f00;}
#call2action .message {
display:block;
font-weight:bold;
font-style:italic;
font-size:1.75em;
line-height:1.1;
text-align:center;
text-decoration:underline;
text-shadow:1px 1px 1px #000;
letter-spacing:1px;
padding:0px 6px 3px;
margin:0;
}
</style>
</head>
<body>
<div id="call2action">
<div class="tl"></div>
<div class="bl"></div>
<div class="tr"></div>
<div class="br"></div>
<div class="tcl"></div>
<div class="tcr"></div>
<div class="bcl"></div>
<div class="bcr"></div>
<div class="mid"></div>
<a href="">
<span class="message">This is Exactly what I Need to Do For Myself Right Now!</span>
</a>
</div>
</body>
</html>
So, I have been analyzing the new CSS in particular. Obviously, HTML is much more simple.
For the bottom link section, now #call2action nested inside of #bottomlink. I’m not quite sure why having #bottomlink as a container adds more stability to the page, seeing as all that #bottomlink has for attributes is aligning text to the center and padding. #call2action has relative positioning so that the absolutely positioned child divs can take on the positioning based on its parent as they are removed from the document flow.
There is also a sort of table-like flow made out of #lpfoot, which has display:table;. There are child containers with the class of .footbox that are displayed in table-cell. Again, I’m not sure of how this benefits the stability and versatility across web browsers.
Why do we switch back to block display? The second part means that for every .footbox that succeeds .footbox (if it’s a sibling element), we add 6px of top padding.
Just my thoughts on looking this over and examining the theory of it all.
Oh, well, let the image names be misleading. At least I understand the concept enough to re-create the same effect. It’s good practice on positioning.
Now, I’m off to copy the new HTML into the existing files. That’s going to take a minute.
Then, I am going to be writing new pages and editing down the current ones. A lot of the text content is fluffy & wastes too much time on ultimately useless points. It’s not exactly the best-written, but that’s what editing is for. When editing these, I’m going to be adding in tables on some. Some may even have little bar graphs. Tables make for good review content.
Might I suggest that you make a “template” of the new HTML, duplicate it, and copy the content from your other pages into the template. You can test as you go. That would be less likely to create problems than copying the new into the old; unless you are just copying something simple.
Compatibility: all of the code that I’ve suggested has been tested in IE8+ and the latest FF, Chrome, and Opera browsers. It breaks in IE7.
Conveniently, #bottomlink was already in your code and already set to {text-align:center}. So, I set #call2action to {display:inline-block} and it works in FF3.6 (who cares?). If the two divs were rolled into one, #call2action would be {display:table;margin:0 auto;} and break in FF3.6. No other reason.
There were several problems in #lpfoot. Therefore, the construction was changed to {display:table} so the two items could be put into individual containers with {display:table-cell} which fixed those problems: (1) #emailbox is no longer floated which had a couple of untoward side effects, and (2) that little undescribed “glitch” involving the links is less likely to appear because they have more width in which to move.
The media query in #lpfoot changes the table-cells to blocks so the 2 lpfoot containers, .footbox, center align their contents in two rows in narrow windows. The padding makes the second row 6px taller, thereby adding a little space between the GoBackTo links and #emailbox.
If you are not interested in changing the names of the images so they resemble their placement, at least copy the comments beside those images in post #51 into your code. Someday, you’ll be glad you did.
