Wordpress Themes - WP Forum at BFA

Wordpress Themes - WP Forum at BFA (http://forum.bytesforall.com/index.php)

- ThemeFrame Presales (http://forum.bytesforall.com/forumdisplay.php?f=30)

- - Built with tables? (http://forum.bytesforall.com/showthread.php?t=9192)

Quote:

Originally Posted by tattvajit (Post 80180)

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.

Code:

/* 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.

Quote:

Originally Posted by Flynn (Post 80187)

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.

Quote:

Originally Posted by Flynn (Post 80187)

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.

Quote:

Originally Posted by Flynn (Post 80187)

- 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

Quote:

Originally Posted by Jam (Post 80207)

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!]

Quote:

Originally Posted by studioelle (Post 82939)

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.

Quote:

Originally Posted by studioelle (Post 83002)

Themeframe currently does support fluid layouts to a point.

Responsive design is not currently available without manual edits, which defeats the purpose of wysiwyg.

Quote:

My knowledge of responsive designs suggests that the responsiveness may add bloat to the site and cause slower loading.

Larry, not sure where you would get this idea. Care to share a source?

I have not done extensive research but one article that points out some of the issues with responsive design is this one from WebDesignShock.com.

Quote:

Originally Posted by lmilesw (Post 83054)

I have not done extensive research but one article that points out some of the issues with responsive design is this one from WebDesignShock.com.

Ok, I've read a few similar rebuttals to Ethan Marcotte's Responsive Web Design Article.

They all bring up the same thing, which is a valid point, that mobile devices with less processing power, and generally less bandwidth than their desktop cousins, will download, and reprocess larger images even if they ultimately display smaller versions via media queries.

They (the rebuttals) also are generally unanimous in their conclusions that:

A responsive site served to a desktop/notebook platform will have no performance penalty.
A responsive site served to a mobile device will generally have no performance penalty when compared to a site optimized for desktop/notebooks only.
A responsive site served to a mobile device will have a much more satisfying UX (user experience) compared to a site optimized for desktop/notebooks only.

The only better thing than a responsive site served to a mobile device is a site optimized only for that device, and not desktop/notebooks.

So, if you design a different version of your sites for mobile devices, then, yes, that is superior to a single responsive design.

My point here is not to convince anyone one way or another, just to point out the facts (as I understand them. That is why I chimed in. ;) )

This is important stuff, as I've read the projection that within 5 years more sites will be visited by mobile devices than by desktop/notebooks; So if you target only the desktop, you are serving poor design to a continually growing share of your audience.

If you do not build different content to serve the mobile devices, then responsive is a valid tool for a designer's box!