You should have three new widget areas. You put one widget in each area.

Originally Posted by lmilesw

You should have three new widget areas. You put one widget in each area.

Imilesw,

Red-faced ... I realized soon after posting ... don't I just like to make life difficult!

Thank you, truly, very much appreciated.

(donation on it's way, grateful - to have someone to discuss this with - for the help provided).

Berean.

Originally Posted by lmilesw

If you look at ATO>Add New Widget Areas you will see the following example code.

<?php bfa_widget_area('name=My widget area&cells=4&align=1&align_2=9&align_3=7&width_4=700&before_widget=<div id="%1$s" class="header-widget %2$s">&after_widget=</div>'); ?>

One configuration to get a three celled area with a text alignment of left top and auto width of the cells would be.

<?php bfa_widget_area('name=My widget area&cells=3&align=9&before_widget=<div id="%1$s" class="header-widget %2$s">&after_widget=</div>'); ?>

You can change the name to something more useful to you and put widths and alignments as explained in the text.

<?php bfa_widget_area('name=My widget area&cells=4&align=9&before_widget=<div id="%1$s" class="header-widget %2$s">&after_widget=</div>'); ?>


I've just checked my W3C Validation and the Code for Add New Widget Area creates an Error

<div id="my_new_widget_area" class="bfa_widget_area"></div>

Error Line xxx, Column xx: document type does not allow element "div" here; missing one of "object", "applet", "map", "iframe", "button", "ins", "del" start-tag

What code did you use for creating the new widget area? You could also try the following although in my experience some of the W3C validation errors don't mean that much.

<?php bfa_widget_area('name=My widget area&cells=3&align=9'); ?>

Hi Imilesw,

I applied the Code(s)...as per ATO > Add New Widget Area and tried, and tested, the Code(s) as suggested above, here, in this thread i.e......

<?php bfa_widget_area('name=My widget area&cells=4&align=1&align_2=9&align_3=7&width_4=700&before_widget=<div id="%1$s" class="header-widget %2$s">&after_widget=</div>'); ?>

<?php bfa_widget_area('name=My widget area&cells=3&align=9&before_widget=<div id="%1$s" class="header-widget %2$s">&after_widget=</div>'); ?>

<?php bfa_widget_area('name=My widget area&cells=4&align=9&before_widget=<div id="%1$s" class="header-widget %2$s">&after_widget=</div>'); ?>

<?php bfa_widget_area('name=My widget area&cells=3&align=9'); ?>

PREVIOUSLY....

W3C Validation XHTML PASSED successfully checked as XHTML 1.0 Transitional!

THEN....

Add New Widget Area in Footer = FAILED with 1 Error as described above in previous Post #28.

And so...

If I remove My New Widget Area from Footer .......... than all is restored as previously PASSED.

Consequently...

There is something amiss with regard to Add New Widget Area in Footer.

With all due respect, I consider it important that, at the very least, one is able to display ones site as XHTML PASSED XHTML 1.0 Transitional - as recommended by W3Schools.com

Could this be looked at, please.

Many thanks.

I am checking into this.

I have looked into this and still don't put a lot of weight on validation. As an example I ran one of my sites through and it passed. I then set the theme options to not compress the CSS and it didn't validate as the validator sees comments in CSS as errors. This tells me the validators has errors.

This is why I gave up running sites through a validator years ago. Too many variables and it takes to long to figure out fixes. I open my sites in various browsers and if all looks good I am happey.

Hi Imilesw,

Ah, but, I was not referring to CSS Validation (which has never passed, plug-in variables being one reason as to why CSS validation fails).

I consider it important that, at the very least, one is able to display ones site as XHTML PASSED XHTML 1.0 Transitional - as recommended by W3Schools.com

I have always, up till this point, had XHTML Passed of which is after all a standard - as is recommended by the much mentioned here at BFA W3Schools.com

As I said, there is something amiss with the ADD NEW WIDGET Area to the Footer resulting in one Error and FAIL XHTML.

ATO > Add New Widget Area.

Have you tested Add New Widget Area - Footer

if you want to get rid of the 'error', edit footer.php and remove line 99 and line 101 (version 3.6.4)

Originally Posted by lmilesw

You would create a 3 cell widget area. This will put the areas side by side. As you found when you put several widgets in one area they go under on another.

This is helpful, Larry. My next question is this: do all the pages on the site have to have this layout then? Or can just the homepage be divided up into the 'horizontal' widgets and the sub pages not?

This is where various methods can be used. You can wrap the New Widget Area code in a conditional that will only show (or not show) on certain pages. The easier way for most people is to use the Display Widgets plugin which lets you chose which page they will show. If they are set to not show you won't see the widget areas.

That's good to know. I presume, then, that I can't have horizontal sidebars (aka widgets?) on the front page, but then have a vertical sidebar on the left side of all other pages? I'm wondering if you're always limited to four sidebars (two on each side), and if so, then if I use three horizontals on the front page, then I'd one to use elsewhere? And if I used four horizontals on the front page, none to use elsewhere?

You can do any and all of what you mentioned. It's a matter of understanding the new widget areas and Atahualpa enough to pull it off. It's kind of hard even to describe as some of these ideas require the use of code, plugins, and special CSS.

For example you can put a widget area inside a widget area so if you put a single cell widget area in a php aware widget you could then put a 2 cell widget area right below it. Or you could put a 4 celled widget area in a php aware widget to give you four sidebars.

It can get a little nuts.

Originally Posted by juggledad

if you want to get rid of the 'error', edit footer.php and remove line 99 and line 101 (version 3.6.4)

Thank you.

Is there an update on when the grid system may make its way into Atahualpa or ThemeFrame? In Atahualpa 4.0 perhaps? Flynn mentions here that he is working on a "completely new backend for Atahualpa 4.0".

Originally Posted by tattvajit

Is there an update on when the grid system may make its way into Atahualpa or ThemeFrame? In Atahualpa 4.0 perhaps? Flynn mentions here that he is working on a "completely new backend for Atahualpa 4.0".

I am at it right now - to be released within Feb 2012 for both ThemeFrame and Atahualpa

Atahualpa 4 and ThemeFrame-created themes will be using the same layout techniques among other things. I am putting Atahualpa 4 things into ThemeFrame and vice versa

I examined existing techniques such as Twitter Bootstrap, Zurb Foundation, Skeleton, 960.gs and a couple others very closely and made my own tests with floated DIV's, equal height columns, source ordering, auto resizing of images and videos and responsiveness. I wasn't fully satisfied with any of those even though I wanted to leverage an existing one "as is" so I wouldn't have to document the technique.

The aforementioned were still helpful for testing.


The new layout for both Atahualpa 4 and ThemeFrame will have:

- Floated DIV's only - no tables, not even display:table-cell. This includes dropping IE6 support for the most part, at least where it differs from IE7

- Source ordering, including vertically (Content even before header)

- Responsiveness, at least in stages (layout "jumps" into 3-4 different widths) as done in Skeleton, perhaps fully fluid as in Foundation. The Skeleton approach allows for pixel perfect styling across browsers but isn't fluid and has no source ordering built in. The Foundation approach is both responsive and fluid but this requires %-width for columns which causes slight differences (1-pixel gap) across browsers due to different rounding of %-values between i.e. Webkit, Firefox and IE.

- Optionally border-box box model instead of the awkward, apparently print-oriented W3C box model. "box-sizing:border-box" makes column width calculation much more intuitive and removes the need for all those "inner DIV's for border and padding" - making the source code cleaner, easier to maintain and probably better for SEO, too. Unfortunately both the existing (.htc, IE8.js...) as well as my own JS attempts cannot remove a visible re-arrangement of the layout at page load, for 0.5-1 seconds, in IE7.

On a good note, once IE7 can be ignored (I plan to make it an option to ignore it right now) things are looking quite good in terms of floated DIV layouts.

Except for equal height columns. The hack I am going to apply won't let you have a padding-bottom on the column's parent, the "row". This could be simulated with a border though. or you just don't use equal height columns. None of the above mentioned CSS layouts has that feature.

/* Equal height columns with floated DIV's 
Note: This requires JS fix, i.e. "IE8.js" for "first-child" support in IE7.
Alternatively give first column an individual class such as "first-col" and use
.first-col { margin-left: 0 } */

.row {
  position: relative;
  width: 960px;
  margin: 0 auto;       /* centered */
}
.col {
  float: left;
  position: relative;
  margin-left: 20px;    /* Use margin-left. IE8 know first-child but not last-child */
}
.col:first-child {
  margin-left: 0; 
}
.ehc {
  position: relative;    /* for IE6/7 */
  overflow: hidden;
}
.ehc .col {
 padding-bottom: 10000px;
 margin-bottom: -10000px;
}
.col1,
.col3 {
  width: 200px;
}
.col2 {
  width: 520px;     /* 960 - (2 x 200) - (2 x 20) = 520 */
}



HTML:

<div class="row ehc">
  <div class="col col1">...col 1 ...</div>
  <div class="col col2">...col 2 ...</div>
  <div class="col col3">...col 3 ...</div>
</div>

Thank you Flynn for the update.

Originally Posted by Flynn

I am at it right now - to be released within Feb 2012 for both ThemeFrame and Atahualpa

Cool Stuff Flynn; been playing with a couple of the responsive frameworks myself; albeit with a lower skill-set than yours.

Originally Posted by Flynn

Optionally border-box box model instead of the awkward, apparently print-oriented W3C box model. "box-sizing:border-box" makes column width calculation much more intuitive and removes the need for all those "inner DIV's for border and padding" - making the source code cleaner, easier to maintain and probably better for SEO, too.

This is without a doubt the most intuitive. However, I must confess that I haven't had 100% reliable success specifying that a div use "box-sizing:border-box". I could easily have been doing something incorrectly.

You do realize that you could market TF for building static html sites in addition to WordPress Themes, especially with the framework you are working toward.

And, while I, and many others, don't have too many problems operating out of a local-server environment, I think that when you are able to make the jump to an OS based platform, you would reach a much greater audience. But, that is just conjecture on my part.

Anyway, sounds very interesting; Looking forward to it.

Originally Posted by Flynn

- Responsiveness, at least in stages (layout "jumps" into 3-4 different widths) as done in Skeleton, perhaps fully fluid as in Foundation. The Skeleton approach allows for pixel perfect styling across browsers but isn't fluid and has no source ordering built in. The Foundation approach is both responsive and fluid but this requires %-width for columns which causes slight differences (1-pixel gap) across browsers due to different rounding of %-values between i.e. Webkit, Firefox and IE.

Pixel perfect is EXTREMELY important to me, I hope we wont be losing this? A lot of my sites rely heavily on pixel perfect graphics. If pixel perfect across browsers goes

Not at all, it will be possible to do pixel perfect layouts, even easier

Originally Posted by Jam

Pixel perfect is EXTREMELY important to me, I hope we wont be losing this? A lot of my sites rely heavily on pixel perfect graphics. If pixel perfect across browsers goes

Thanks so much, Flynn, for being up to date with recent changes in design!

Any update on the move to html5/responsive layout version of ATA (and/or Themeframe?) I am ready to make my next donation once it's ready! I have many clients that won't let me use this theme because of the tables. That crushes me because I've done amazing things with ATA and just can't get other themes to do what I want (like Roots) without involving a "real" programmer. (I'm designer that self-taught programming to stay on the up and up.) [edit: I just donated some and will donate lots more when available!]

Originally Posted by studioelle

Any update on the move to html5/responsive layout version of ATA (and/or Themeframe?) I am ready to make my next donation once it's ready! I have many clients that won't let me use this theme because of the tables. That crushes me because I've done amazing things with ATA and just can't get other themes to do what I want (like Roots) without involving a "real" programmer. (I'm designer that self-taught programming to stay on the up and up.) [edit: I just donated some and will donate lots more when available!]

Themeframe.

I'm not positive what you want to achieve, but do it with Themeframe and never look back. I'm also a designer, spent several years hacking ATA's, Themeframe is just brilliant in my opinion, and definitely your way forward.

I'm mainly concerned about no tables (which I see TF does) and for sure responsiveness (which I didn't see anything about on TF site). I definitely want to try TF for my next site, but I need responsiveness.

My knowledge of responsive designs suggests that the responsiveness may add bloat to the site and cause slower loading. The other option of using a plugin that delivers another theme for the mobile device MAY be a better solution. At least at this time. Just my 2 cents.