Create 2 basic sample layouts: 1-col and 2-col

Just to jump in, and give some feedback and ideas.

#15 +1
#16 +1

#23

The problem of targeting "all layouts" or "just these layouts", and wanting to be able to do both without having to modify templates, is legit.

Well, what about something like this for the more complex layout in #3?

@webchick
Are you just looking for a fixed layout or is a dynamic layout allowed? The example below could solve some of the need for manually making different tpl.php files, as well as give front-end developers some layouts to choose from out of the box.

The code below would allow for multiple layouts with optional top (with multiple columns), middle (with multiple columns), bottom (with multiple columns). Basically what it will do is print 'containers' dynamically based on the panel content. It prints a wrapper div for top, middle, and bottom. Each top, middle, and bottom wrapper can have classes added through the panels admin (which is the case now in panels) or that could be fixed as well if that is the preferred way to go. For each container it prints a generic container class, a preset class, and a class specific for that container based on the id of the panel content container.

One could read/ write the layout from/ to the .yml and tpl.php for the panel. It could have save/ select/ import/ export functionality.

Please don't mind the variable naming, it's a mockup. I settled on panel for the panel, and containers for the inside. The variables could be changed to fit the Drupal Twig variables.

Working from the more complex layout example in #3:

<?php
/**
* @file
* Template for a column panel layout with optional top, middle, and bottom panels.
* This template provides a variable column panel display layout.
*/
?>
<div class="panel-wrapper <?php if (!empty($css_class)) { print $css_class; } ?>">

<?php if ($container_top) : ?>
     
       <div class="panel-top-wrapper">	
	
	<?php foreach($container_top as $container) :
     
	    $build_container  = '<div class="container' . $container->preset . 'top-' . $container->cid .'">';
  	  $build_container .= $container->content; 
   	 $build_container .= '</div>';
        print $build_container;
	
	    endif; ?> 
    
       </div>	

<?php endif; ?>
 

<?php if ($container_middle) : ?>

	<div class="panel-middle-wrapper">
	
		<?php foreach($container_middle as $container) :
      
	    $build_container  = '<div class="container' . $container->preset . 'middle-' . $container->cid .'">';
	    $build_container .= $container->content;
	    $build_container .= '</div>';
        print $build_container;

		endif; ?>

	</div>

<?php endif; ?>

	
<?php if ($container_bottom) : ?>

	<div class="panel-bottom-wrapper">
	
		<?php foreach($container_bottom as $container) :
      
	     $build_container  = '<div class="container' . $container->preset . 'bottom-' . $container->cid .'">';
	     $build_container .= $container->content;
	     $build_container .= '</div>';
         print $build_container;

		endif; ?>

	</div>

<?php endif; ?>

(p.s. The comment section seems to mess up the layout of the code don't know why and can't get it fixed.)

The preset functionality of the containers will allow for standard layouts e.g:
left right for a 2 column layout
left middle right for a 3 column layout

(#18) It may better to do the wrapper's in id's, with this mockup considered that there could be more than one panel layout on one page, that would possibly need some rewriting, because I don't the know the div layout that would come before that. If that has a (unique) id, then that could be used.

For example for multiple image galleries on one page:

<div id="page"> 
/// The first panel layout
<div class="panel-wrapper gallery flower-photos">
</div>
// The second panel layout
<div class="panel-wrapper gallery flower-paintings">
</div>

Can't think of a layout you couldn't do with this if you figure in blocks.

Let's get some productive activity going on this, and get this wrapped up. We have been moaning and complaining about this a long time, and now that we get the opportunity to get some input we shouldn't let that go to waste.

Here are some fixed layouts for the two examples given, in addition to the earlier dynamic one.

Working from the comments above.

I've opted for the top-wrapper, center-wrapper, bottom-wrapper naming convention instead row-1, row-2, as I felt this described the area a little better, also is already used in themes in Drupal. Also row-1, row-2, etc is something I relate more to tables than to divs. However, it isn't written in stone.

Use col 1, col 2, etc for the columns this to keep account for responsive layouts. Each column has a general column class to allow for styling all the columns the same (for a panel).

Besides a optional custom id, it would be nice to be be able to add a custom class. This in case there are multiple panels on a page and you can't use an id, and you want to apply custom styling to different panels. Should this be done (in part) from the layout admin, or should this be added in the layout itself? For example:

Option 1
All dynamic attributes

<div <?php if (!empty($css_id)) { print "id=\"$css_id\""; } ?>  <?php if (!empty($css_class)) { print "id=\"$css_class\""; } ?>">

Option 2
Dynamic id and class attributes, besides standard layout class attribute

<div <?php if (!empty($css_id)) { print "id=\"$css_id\""; } ?>  class="layout-two-col <?php if (!empty($css_class)) { print $css_class; } ?>">

Option 3
Manually added id and class attributes

<div id="custom_id"  class="custom_class layout-two-col">

Template Proposals

Template proposal for a 2 column layout:

<?php
/**
* @file
* Template for a 2 column layout.
*
* This template provides a two column display layout, with each column equal in
* width.
*
* Variables:
* - $content: An array of content, each item in the array is keyed to one
*   region of the layout. This layout supports the following sections:
*   - $content['left']: Content in the left column.
*   - $content['right']: Content in the right column.
*/
?>
<div <?php if (!empty($css_id)) { print "id=\"$css_id\""; } ?>  class="layout-two-col">
  <div class="column col-1">
    <?php print $content['left']; ?>
  </div>

  <div class="column col-2">
    <?php print $content['right']; ?>
  </div>
</div>

Template proposal for a 3 column panel layout:

<?php
/**
* @file
* Template for a 3 column panel layout.
*
* This template provides a three column 25%-50%-25% panel display layout, with
* additional areas for the top and the bottom.
*
* Variables:
* - $id: An optional CSS id to use for the layout.
* - $content: An array of content, each item in the array is keyed to one
*   panel of the layout. This layout supports the following sections:
*   - $content['top']: Content in the top row.
*   - $content['left']: Content in the left column.
*   - $content['middle']: Content in the middle column.
*   - $content['right']: Content in the right column.
*   - $content['bottom']: Content in the bottom row.
*/
?>
<div <?php if (!empty($css_id)) { print "id=\"$css_id\""; } ?> class="layout-3col-stacked" >
  <?php if ($content['top']): ?>
    <div class="top-wrapper">
      <?php print $content['top']; ?>
    </div>
  <?php endif ?>

  <div class="center-wrapper">
    <div class="column col-1">
      <?php print $content['left']; ?>
    </div>

    <div class="column col-2">
      <?php print $content['middle']; ?>
    </div>

    <div class="column col-3">
      <<?php print $content['right']; ?>
    </div>
  </div>

  <?php if ($content['bottom']): ?>
    <div class="bottom-wrapper">
      <?php print $content['bottom']; ?>
    </div>
  <?php endif ?>
</div>

.YML files can stay the same?

CSS needs to be done, but until a layout is decided upon it would be pretty much a waste of time to write those now, as things can still change.

The files are attached. For those that want to write a patch after review, it would be really helpful. :-)
(I don't have a clue on how to write a patch).

Patched files for #28 attached.

@cweagans,

Thanx :-) Last time I tried using the doc pages got stuck. Gave it another go and managed to figure it out using diffutils and a tutorial, but don't want to go to much off-topic.

O.k. I don't know why the patch is failing. Followed the instructions, apparently missed something. Maybe better for this topic if someone else with more experience patches. If someone wants to clue me through p.b. I'd appreciate it. :-)

@Stalski,

We posted at the same time.
As far as I know from op there wasn't a definition for which one:

The goal? Make one or two of these

In #3 there was a request for a more complex layout, or did I misunderstand something?

It's good that you mention it though.

In any case, to have all the bases covered for now, here is a proposal for a one column layout.
File for this is attached at the bottom.

<?php
/**
 * @file
 * Template for a 1 column panel layout.
 *
 * This template provides a very simple "one column" panel display layout.
 *
 * Variables:
 * - $id: An optional CSS id to use for the layout.
 * - $content: An array of content, each item in the array is keyed to one
 *   panel of the layout. This layout supports the following sections:
 *   $content['middle']: The only panel in the layout.
 */
?>
<div <?php if (!empty($css_id)) { print "id=\"$css_id\""; } ?> class="layout-one-col">
  <?php print $content['middle']; ?>
</div>

Maybe it is better to discuss somewhere which ones to put in before we continue? This so that we have a set parameter, and don't waste any time writing tpl's. Because I'm getting confused...

#34

Would you mind linking to some documentation on that, or explain in easy to understand language what you mean?

From what I understand from docs you mean something like this?

<?php

$options['attributes']['id']
$options['attributes']['class']

?>

Which would translate to something like {{ attributes }}?

So the one column layout would look something like this then?

<?php
/**
* @file
* Template for a 1 column panel layout.
*
* This template provides a very simple "one column" panel display layout.
*
* Variables:
* - {{ attributes }} the id or class of the wrapper div
* - $content: An array of content, each item in the array is keyed to one
*   panel of the layout. This layout supports the following sections:
*   $content['middle']: The only panel in the layout.
*/
?>
<div {{ attributes }} >
    <?php // Needs to be translated to Twig 
          print $content['middle']; 
     ?>
</div>

As long as the attributes are easy to set I think that is a good idea, and could be a good solution. With emphasis on the easy to set part for people with a low level of coding knowledge. You shouldn't need a PHP degree to set the attributes for a div. Don't want to make it anymore complicated than it needs to be. Also be a good idea to let people know in the top of the file where they can set this then, or include this in the Theming documentation. (Not sure if this is the best place to discuss that in depth?)

It would solve that point, and we could check that off, and move on.

Edit:

#35 +1 Sounds like a good idea.

Oops, sorry @webchick, we posted at the same time, and it changed the title back by accident.
Changed it back for you.

Edit:
#37
Wouldn't know where to start with a new issue, and I'm also limited in my time unfortunately.

So attributes objects are just an improvement over the oldschool attributes array we've had in previous versions of Drupal. You can continue to treat it like an array (don't worry about it, you just can). So any html supported key value pair will just render out of it by doing the {{ attributes }} thing. That would support id, class, rel, whatever.

That would just change the theme hook so that it takes an attributes variable in addition to the content one.

o.k., good that you wrote it down like that, because that is the part where you lose me, and other people as well that don't know PHP (that well). If it is documented how to do what you suggest step by step, and 'it just works', then I'm fine with it. Otherwise I foresee some people ripping out the {{ attributes }} part, and just adding hard coded attributes instead. Which some people may do anyway, because they want to style only that section, and don't feel like learning the whole thing behind it, or feel it's too complicated. Using the {{ attributes }} if there is no dynamic part behind it (e.g. gui to fill those values) may just be an unnecessary complication where hard coded attributes would suffice. I may judge that wrong, and other front-end developers may have another opinion though.

Looking at #39 and #40. You know what, let's focus on the mission at hand. Let's do the HTML the hard coded way first. We can add 'optional_custom_id' and 'optional_custom_class' where the need is to be able to add a custom id or class, and then in a follow up issues translate this to Twig, and how to add those attributes dynamically. We can sign off on these then, and do the CSS for these two templates. Then we have two templates which are ready for dynamizing. :-)

Template proposal for a 1 column layout

<?php
/**
 * @file
 * Template for a 1 column panel layout.
 *
 * This template provides a very simple "one column" panel display layout.
 *
 * Variables:
 * - $id: An optional CSS id to use for the layout.
 * - $content: An array of content, each item in the array is keyed to one
 *   panel of the layout. This layout supports the following sections:
 *   $content['middle']: The only panel in the layout.
 */
?>
<div id="optional_custom_id" class="layout-one-col optional_custom_classes">
  <?php print $content['middle']; ?>
</div>

Template proposal for a 2 column layout

<?php
/**
* @file
* Template for a 2 column layout.
*
* This template provides a two column display layout, with each column equal in
* width.
*
* Variables:
* - $content: An array of content, each item in the array is keyed to one
*   region of the layout. This layout supports the following sections:
*   - $content['left']: Content in the left column.
*   - $content['right']: Content in the right column.
*/
?>
<div id="optional_custom_id" class="layout-two-col optional_custom_classes">
  <div class="column col-1">
    <?php print $content['left']; ?>
  </div>

  <div class="column col-2">
    <?php print $content['right']; ?>
  </div>
</div>

The files for #41.

(forgot to add)

Lorem Ipsum HTML files and first draft CSS for the 1 and 2 column layout.

Please find attached below Lorem Ipsum HTML files, and a first draft for the CSS for code port, browser design and testing. I've added the original panel CSS as well. I've added them in a ZIP file so that everybody regardless of operating system should be able to have access to it, also I can't attach HTML and CSS files without renaming them to a .txt extension, so this should save people some work. This way everybody will be able to work with the files, which the dynamic stuff can then be added too.

The HTML files are really simple files meant to work on the div's, don't worry about p tags at this point.
The new CSS code is just a first draft, to start porting some stuff such as attribute names. It needs to be checked, and further worked on. This is dependent on how the HTML layout will look, so until that is done don't spend too much time on layouting the CSS. Otherwise you may have to do the work again if the HTML layout changes.

There is some stuff in the old CSS code that may need special attention (which may need the input from someone with more Drupal experience):

In the one column layout CSS:

/* What is this stuff for, and does it need to be renamed? */

#panels-edit-display .panel-pane,
#panels-edit-display .helperclass {
  margin: .5em;
}

/*
Why is there panel-2col in the 1 col CSS ? 
What is this stuff for, and does it need to be renamed? */

.panel-2col .panel-separator {
  margin: 0 0 1em 0;
}

In the two column layout CSS:

/* What is this stuff for, and does it need to be renamed? */

#panels-edit-display .panel-pane,
#panels-edit-display .helperclass {
  margin: .5em;
}

/* What is this stuff for, and does it need to be renamed? */

.panel-2col .panel-separator {
  margin: 0 0 1em 0;
}

For the two column layout which way should we do the CSS for the columns?:

Option 1:

.layout-two-col .column { 
  float: left; 
  width: 49%;
  margin: 0 .5em 1em 0; 
}

Option 2:

.layout-two-col .col-1, .layout-two-col .col-2 { 
  float: left; 
  width: 49%;
  margin: 0 .5em 1em 0; 
}

Option 3:

.layout-two-col .col-1 { 
  float: left; 
  width: 49%;
  margin: 0 .5em 1em 0; 
}

.layout-two-col .col-2 { 
  float: left; 
  width: 49%;
  margin: 0 .5em 1em 0; 
}

Do we want the margin there (or use padding instead)? Are these the margin sizes we should use?

Last, but not least. There is this in the old two column CSS, one for each column:

.panel-2col .panel-col-first { 
  float: left; 
  width: 50%; 
}

* html .panel-2col .panel-col-first {
  width: 49.9%;
}

Which I'm not sure why it is there. To tell you the truth I've never seen it done like this, and I'm not sure both are needed. If I may ask, what is the reason for adding this? Cross-browser issues?

#43

+1
I agree that div's should not be showing if they are empty.

#47,

iirc, * html is a CSS hack for IE6 and below, so I'm pretty sure we can do without that.

From what I understand Drupal 8 won't support IE6 (or IE7), but this needs confirmation. If IE6 is the reason it is being used, than I agree that it can be scrapped if IE6 is no longer supported with Drupal.

Reviewing the patch in #48:

1. If using block instead of float is 'clearfix' still needed?
2. Should clearfix, like margin and padding, be something that is left up to the individual theme. Providing a clear slate with two columns. It would remove (some of the) the necessity to do CSS overrides, adding clean CSS instead. (In the end though if everything is cleaned up, like it is now, then I could live with clearfix, if it provides an overall solution for a problem, and makes life easier.)
3. What's the reasoning for using a - negative margin in the two-col.css in layout-two-col .layout-region?
4. What is the reasoning behind using 'vertical-align: top' in the two-col.css layout-two-col .layout-region?
5. With the whitespace issue which the patch also suffers from, and float being generally accepted, would the use of floats be preferred in this case?

For example:

.layout-two-col .layout-region   {
    float:left
    width: 50%;
}

With a standard padding of 20px:

.layout-two-col .layout-region {
    float:left;
    width: 47.917%;
    padding: 20px;
}

(Please note: examples above need complete cross-browser testing for this use case before use).

6. I haven't tested or used this broadly. Another way to go may be to use max-width and pixels. Which in Firefox in any case gets rid of the need for a special style for mobile (would need cross browser testing), is lean code, makes for easier calculation of the padding and margin in px, gets away from using percentages (which can be tricky). There may be other issues with this, though, but as we don't have to account for IE6 (max-width was introduced in IE7) this may be a solution... Throwing it into the mix so we have all bases covered on this, but not sure what to do with it.

For example:

.layout-two-col {
    max-width: 600px;
}

.layout-two-col .layout-region {
    float:left;
    max-width: 260px;
    padding: 20px;
}

7. As we're using 'one-col' and 'two-col' naming convention in all the other parts of the layout. Instead of naming the divs 'layout-col-first' and 'layout-col-second' naming the divs 'layout-col-one' and 'layout-col-two', may be more consistent. (While first and second has a case for being easier to read, on the next level, and may avoid some confusion.)
8. There was no one-col.css included as far as I can see. Does this mean there won't be one?

That's all I could think off, but please do doublecheck as I may have missed something accidentally.

Reviewing #55

- negative margin are needed since the two boxes of 50% width are too wide to fit in 100% width. That's how it works with inline-blocks (see code of seutje in #20)
- vertical align: See http://www.impressivewebs.com/css-vertical-align/

O.k., using the code from the patch at least in Firefox this layout using inline:block gives problems for me when testing. Please see attached screenshots.

With a sidebar on the left, the inline:block div moves over the sidebar div. The layout-regions show below each other and not next to each other. With no sidebar, the content moves off of the screen on the left and creates a gap on the right, while the layout-regions are shown next to each other. Can anyone duplicate this result, or am I overlooking something/ patched something incorrect?

HTML Code used for sidebar:

<div id="sidebar">
   ...
</div>

<div class="layout-display layout-two-col">
   
    <div class="layout-region layout-col-first">
	...			
    </div>
    
    <div class="layout-region layout-col-second">
	...
    </div>

</div>

CSS code used for sidebar:

#sidebar { 
    width:200px;
    float:left;
    background: #ccc
}

.layout-two-col {
    width:100%;
}

.layout-two-col .layout-region {
     vertical-align: top;
     margin-left: -.25em;
     display: inline-block;
     width: 50%;
     background: yellow
}

You did not mention why you specifically want one, so I don't understand why it should be changed.

It was there in the original file. Just to make sure we are not missing any steps during the process: the container div in one-col needs to be set to 100%, doesn't it though? Won't otherwise the change exist that the div doesn't fill to the div around it?

Please disregard inline-block-100%.png in previous post.
See inline-block-full-width.png instead atttached to this post.

(Renaming of attached image inline-block-100%.png to inline-block-full-width.png, as
Drupal has problems reading the file.)

@Stalski

I don't waste time writing irrelevant comments... ;-) (well in my perception anyway ;p)

You're not the only one getting confused....

I agree with finding a solution together. :-)

Which part don't you understand?

Short and sweet summary: the inline:block code is giving layout problems in Firefox. Needs further cross-browser testing to see if problem occurs in other browsers. Propose to use float instead, unless inline:block issues can be resolved.

In Dutch/ Belgium speak:
De inline:block code veroorzaakt problemen met de layout (in Firefox). Dit ga nie werken zo.

#61

Interesting. Definitely worth considering. The example is using pixels. Do you have a working example using percentages for the two-col layout? It would help with testing. The method you propose has some clear advantages.

Some point of concerns with the proposed solution:

1. As mentioned in the article:

Of course, we should also take care not to use display: table; on a bunch of div elements when what we really have is tabular data!

2. When different parts of the layout are using CSS tables can they conflict with each other? For example can a CSS table be placed in a CSS table-cell? That would be good information to have when considering this.

3. 'Anonymous Table Elements'. Need to find out if these are rendered empty in source code, or not shown at all (but interpreted by browser). Also if we are getting a lot of invisible code, and whether that balances out.

I read your comment when I was going to post the code below. I'm going to look at the table thing because it is interesting and looks promising, in the meantime posting this as well, as it may work.

This is another option using position: absolute and position: relative that may work. It is proving to be quite flexible in Firefox so far e.g. no issues with padding, adding a sidebar, resizes on browser within what I've tested. Needs (cross-browser) testing.

.layout-two-col {
	position:relative;
	width: 100%
}

.layout-two-col .layout-region { 
	position:absolute;	
	width: 50%
}

.layout-two-col .layout-col-first {
 	left: 0
}

.layout-two-col .layout-col-second {
	left: 50%
}

Good to see so much brainstorming going with this. It's great to see such involvement!

Some additional things to consider when naming the divs regions 'first' and 'second' or 'one' and 'two'. Think '1' and '2' could be a better way to go here. Getting into higher numbers could add to the length of the name. Also not everybody's English might be good enough, and it will mean extra translating. 1,2,3, 24, etc is short, sweet, and clear.

For the two col:

for the two-col CSS we have 4 options for the layout-region div displaying next to each other:

1. Float
2. Inline block
3. CSS table
4. Position absolute and relative

One thing we haven't looked at yet is the height of the divs. If not set properly browsers can respond differently to this leading to different ways of displaying the layout. Do we want the height of the layout-regions to be the same as the container, or based on the height of the content within the layout regions?

For the HTML for the two-col from what I can tell, aside from some minor naming issues, we're all pretty much agreed upon. The naming issue shouldn't hold back the rest of the development of this though.

For the one-col:

A layout-region div within the container is superflous for some, while others feel it's needed. Next we have to decide on how we want the width and height of the content set? e.g. 100% width/ height to the div around it or fill to content.

We should decide which way to go on this, assign some roles, and start testing. Normal use cases that would be encountered within a Drupal install, what it should do out of the box, and what is up to the front-end developer should be handy (if not critical), and will help to stay within scope. The clearer the scope and the lower the threshold the more designers, that aren't fluent with Drupal, will be able to help (quickly) e.g. cross-browser testing. For example Seutje is using Dabblet, something like this or setting up a couple of HTML pages, could help for everybody to have access to the layout, and test it on different platforms and browsers without all having to set up dev boxes and patching untill we have a finalised layout. That could save a lot of time.

Hmmm, working on the mobile CSS something became apparent:

Namely, what is the overhead of adding one or more seperate @media per CSS file when you have say 10 different layout--*.tpl.php files. This from a maintenance, performance, and code bloat point of view.

With that I mean imagine having to change the pixel size of one or more viewport for every layout, block, module CSS file one at a time for a theme This could add up to having to do the same change for say 50 times. Not wanting to go to far offtopic, but a single responsive.css or a responsive.css per viewport size, for the layout module, drupal install, or theme may be a better way to go.

Multiple stylesheets can be combined with PHP code, but having to change a single variable across multiple files could prove a time inefficient process. If font-size is part of determining the size, as well as the number of different viewport sizes, and content that may not look right depending on what it is. I'm not sure doing it this way is the way forward. Also not sure if it is part of the scope for this issue? Maybe do mobile/ responsive in a follow-up (in a broader perspective)? For now we could consider to document in the notes which parts should be responsive, and work on the mobile/ responsive part to the degree possible.

@Stalski

I disagree with you. I find your comment way of the mark. I have spent a lot of effort getting this patch to where it needs to be. I have tested many things in this topic. I have stayed on topic in this entire issue, worked on getting this done, as well as getting focus for this issue. That I don't always agree with what you're proposing is a different story.

Accuse me of not being constructive in this issue. Are you on drugs or something? Seriously, go take a couple of weeks off or something.

Thanx for making my last issue with Drupal a sucky experience. The code you wrote sucked. Others and I improved it. Deal with it.

For example you're the one that added the mobile code in the patch. I noticed a problem with it and mentioned it. Now, your giving me comments about me doing wrong. That's rich. I warned you not to add the inline:block, but you added it anyway (insulting me in your comments while doing so btw), and having to face the fact that you were wrong. Like I said, DEAL WITH IT. Don't go insulting your fellow colleagues.

I find your comment non constructive, way off the mark, your behavior is totally out of line, as well as I think you owe me an apology.

If you have any further comments you wish to make I suggest you contact me through my contact form.
Where your off the wall comments should have been made in the first place.

#90

My comment was not intended to be inflammatory. My apologies if it came across this way.
I was defending myself against libel and slander.

Please unpublish Stalski's comment at #75 then as well.
I distance myself from the comment in #75, and do not recognize myself in this comment.

Also consider this as filing a formal complaint. It is unheard of in this community that such comments are allowed. In the least it is poor judgement.

Feel free to remove this comment after this matter is resolved. Otherwise I will see this as slander. I'm sick of this nonsense. Over 4 years of dedicated volunteer service with Drupal, and this is how you get treated.

I followed the rules with this issue.

You bust your butt, and this is the thanks you get. Thanks, but no thanks.

Updated issue summary.