pattern-lab/patternlab-php

The PHP version of Pattern Lab

patternlab-php's Issues

JS Error after switching annotations on.

Uncaught ReferenceError: codeViewer is not defined annotations-viewer.js:24
(anonymous function) annotations-viewer.js:24
x.event.dispatch jquery.js:4676
y.handle

Single Pattern View: Display Pattern Name

We're now wrapping each pattern in the same HTML as PL's list view so that we can use the same code for annotations, code view, and more.

Right now the pattern name isn't being displayed. For the sake of consistency, it would be great to show the pattern name, similar to the list view. If it's not possible, we can simply remove the label.

Viewing HTML code on a page view (demo).

On the demo when you view HTML code while viewing a "page" the html extends beyond the field of vision. There is no way to scroll to see the code.

Might consider adding in a max-height of 50% to the #sg-code-container, and control the pre.language-markup max-height and applying a overflow-y scroll.

Trouble Installing

Unfortunately, I'm having trouble installing Pattern-lab. I understand that the code is intended to be uploaded to a web-server. I also understand that what's viewed by users is what's included in the public folder. But then I'm confused.

WHAT DO I DO!?!?!

_ I'm using Mac OS X Mavericks.
_ I host my own site, http://www.allenjcochran.com/, on GoDaddy
_ GoDaddy, and my hosting plan, have all the required install requirements
_ I've downloaded all the Github files
_ Then I uploaded all the Github files to allenjcochran.com/patternlab01

Its at that point I don't know where to go.

_ How do I set up the page?
_ Do I add to the page like a CMS (Wordpress for example)?
_ How do I regenerate the site after I make new patterns?

Generally confused,

Allen Cochran

Should public/listeners and public/patterns be moved for better portability?

Putting the case out that for better portability, that the listeners and patterns folders should be moved into the styleguide folder as they aren't likely to be used in a final production environment the same way as css/fonts/images/js would be.

Additionally feel that there could be a copy of index.html under styleguide folder for future portability

Thoughts?

Pattern suggestion : navigation

The navigation pattern is an "atomic" level UI element. In its atomic form, it's an (ordened or unordened) list with a horizontal list elements intended for positioning at the top of related content.

In its "atomic" form, there's no styling beyond positioning and orientation. For adjusting positioning and orientation, there are three modifiers :

• left : vertical list, positioned to the left of related content
• right : vertical list, positioned to the right of related content
• bottom : horizontal list, positioned at the bottom of related content

At the "molecular" level, a semi-semantic class defines the type of navigation. At this level you may add colors and typography.

Consider these examples :

• menu : a typical menu that can be used for right-click as well as on an actual page
• tree : hierarchical navigation
• tabs : tab-like navigation
• gallery : image gallery
• tags : a list of keywords
• pagination : intended for paging
• pipes : horizonal list, separated by a vertical line
• stats : key-value pairs

At the "organism" level, you have refinements of the "molecular" level or combinations of different "molecular" types.

Consider these examples :

• cloud tags : a tag navigation layout very popular a couple of years ago
• block tags : a tag navigation layout that consistw of button-like elements
• menu tree : tree navigation with a menu layout
• folder tree : tree navigation that looks like an OS-style folder tree
• links menu : a simplified menu style, consisting of a series of links
• pipe stats : pipes navigation for key-value pairs
• menu stats : menu navigation for key-value pairs

See also #47 and #49 for more advanced "organism" level behavior.

See http://www.cascade-framework.com/components-navigation.html for demos of this pattern.

See also ( #50 )

How to compile scss files

Loving the pattern lab you've created!

How are the scss files meant to be compiling?
I'm used to using a config.rb file in the root of my projects.

I'm running pattern lab locally on my macbook, using the following command to watch the project for changes:
php builder/builder.php -w

Please let me know if I'm missing something - I've read through the docs and couldn't see anything about compiling.

Snapshots

The Web design process requires us to be able to step back through earlier versions of Pattern Lab to view progress, resolve debates, etc, etc.

A snapshot function would be tremendously valuable. The idea would be to have the latest and greatest version always accessible at the root level:

/

But, if needing to step back through time, we could append to the url:

/v1/
/v2/
/v3/
/etc

That way teams can view progress much easier.

Perhaps there can be a spot for that in the UI (under Settings perhaps)?

Pattern Style Modifiers & KSS

This would be a December project if it's of any interest...

TL;DR

Could use KSS to comment and relate CSS to patterns. A single pattern could be modified so it shows different styles. Combined it might provide an interesting styleguide solution where descriptions for a pattern come from CSS. Could be extended to provide CSS driven states in pattern examples.

MORE

After looking at KSS I think I'm starting to get what you meant by associating a pattern with CSS. KSS is an agnostic method for creating machine-readable comments in CSS. This allows for the creation of "living styleguides". GitHub uses it for their styleguide. Here's an example:

/*
A button suitable for giving stars to someone.

:hover                  - Subtle hover highlight.
.stars-given          - A highlight indicating you've already given a star.
.stars-given:hover - Subtle hover highlight on top of stars-given styling.
.disabled              - Dims the button to indicate it cannot be used.

Styleguide 2.1.3.
*/
a.button.star{
  ...
}
a.button.star.stars-given{
  ...
}
a.button.star.disabled{
  ...
}

The thing that has me really interested is that it seems like we could extend KSS to include a pattern as the reference mark-up for a particular style. Right now, KSS is just about describing CSS. In order to get a styleguide going it seems like someone has to hardcode the mark-up/CSS link in real code. It seems like what we could do is tack on a pattern reference at the end to make that connection:

/*
A button suitable for giving stars to someone.

:hover                  - Subtle hover highlight.
.stars-given          - A highlight indicating you've already given a star.
.stars-given:hover - Subtle hover highlight on top of stars-given styling.
.disabled              - Dims the button to indicate it cannot be used.

Styleguide 2.1.3.

Reference atoms-button.

*/
a.button.star{
  ...
}
a.button.star.stars-given{
  ...
}
a.button.star.disabled{
  ...
}

So we could parse the CSS/KSS before generating anything. When a particular pattern is shown we could see if it's been referenced for a group of styles via KSS. We can also check if it has more than one style of implementation (e.g. plain, stars-given, and disabled). We'd iterate over the pattern multiple times and apply each different style of implementation. We'd also show the comments and other info from the KSS. The patterns would be shown in a similar way to GitHub (the right column, not nav) but organized/nested based on pattern and not based on the stylesheet.

In order to allow a single pattern to be modifiable we'd have to include a little mustache when we create the pattern. For example we could create a pattern called atoms-button-star:

<a href="#" class="button star {{ modifyStyle }} ">Button (a.button)</a>

As we iterate through the associated styles for a pattern we can swap out {{ modifyStyle }} with the chosen style. The cool thing is that it opens up the possibility of modifying styles from other templates. We might be able to do this in a pattern that includes our star button:

Have you starred this repo? {{ atoms-button-star:stars-given }}

Which would generate:

Have you starred this repo?
<a href="#" class="button star stars-given ">Button (a.button)</a>

Rather than hardcoding patterns that have states we might be able to simply modify them with CSS. It might also be interesting to see if we could do something with the Page-specific JSON. For example:

{
    "modifyStyle": {
        "atoms-button-star": "stars-given"
   }
}

There are problems that I'll have to tackle:

• the : mod on a pattern name will only work for that pattern. It won't affect nested patterns If you have an organism that includes a molecule that includes the star button you couldn't affect the star buttons state. Maybe the JSON is the way around that.
• We'd only be modifying one style. Not to say we couldn't find a way to chain or provide a more "tag-like" experience.
• atoms that are more complicated in the interest of developing a proper styleguide might not be re-usable in this way. For example, my button example could/should be both an a and button tag. That obviously wouldn't be embeddable in an Organism, Molecule, or Template. This is the tension we're already experiencing with Atoms though.

No rush on this. Just wanted to throw it out there while I was thinking of it. Figured it fell into doing things the way designers would think of it, being agnostic, and helping create a fuller deliverable.

Support for Mustache non-empty list sections?

Does the PHP version of Pattern Lab support Mustache non-empty list sections? I can't seem to get this to work.
Hash:

{
  "repo": [
    { "name": "resque" },
    { "name": "hub" },
    { "name": "rip" }
  ]
}

Template:

{{#repo}}
  <b>{{name}}</b>
{{/repo}}

Output should be:

<b>resque</b>
<b>hub</b>
<b>rip</b>

But is blank.

My guess is the square bracket array syntax breaks the parser or something like that.

Here are my errors:

PHP Warning:  htmlspecialchars() expects parameter 1 to be string, object given in /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/Mustache/Engine.php(583) : eval()'d code on line 16
PHP Stack trace:
PHP   1. {main}() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/builder.php:0
PHP   2. Watchr->watch() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/builder.php:55
PHP   3. Watchr->updateSite() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/watcher.lib.php:71
PHP   4. Buildr->generateMainPages() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/watcher.lib.php:219
PHP   5. Buildr->generateViewAllPages() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/builder.lib.php:133
PHP   6. Buildr->gatherPartialsByMatch() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/builder.lib.php:216
PHP   7. Buildr->renderPattern() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/builder.lib.php:582
PHP   8. Mustache_Engine->render() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/builder.lib.php:108
PHP   9. Mustache_Template->render() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/Mustache/Engine.php:170
PHP  10. __Mustache_74680c57562a62b72f39ddf610cf4777->renderInternal() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/Mustache/Template.php:67
PHP  11. htmlspecialchars() /Users/fgertz/Sites/pattern-lab/patternlab-php/builder/lib/Mustache/Engine.php(583) : eval()'d code:16

Move the postMessage JS out of the templates and into JS files

Just clean-up or organize the JS so it's found in one place rather than all over the templates.

Clean `public/` folder before build

When you you change patterns name and rebuild the public/ folder, the old files and folders still present.

Is it possible to clean public/ folder before build ?

Now I do that with Grunt.

...

    // Clean folder
    clean: {
      // Clean patternlab public/ folder
      pl: [
      'patternlab-php/public/assets',
      'patternlab-php/public/css',
      'patternlab-php/public/fonts',
      'patternlab-php/public/images',
      'patternlab-php/public/js'
      ],
      // Clean main build
      dist: {
        options: {
          force: true
        },
        src:['<%= dest %>/**/*']
      }
    },




    recess: {
      pl: {
        options: {
          compile: true,
          compress: true,
        },
        files: {
          'patternlab-php/source/css/style.css': ['patternlab-php/source/less/style.less']
        }
      }
    },





    // Compile pattern-lab files
    shell: {                                // Task
      // Run patternlab build
      pl: {                      // Target
          options: {                      // Options
            stdout: true
          },
          command: 'php patternlab-php/builder/builder.php -g'
        }
      },

...

Multi-source Support and Custom Starter Kits

This issues builds off of #45.

If we move the core PL view files out of source/ that might give us the flexibility to add multi-site support to one install of PL. This way a group could handle multiple clients with just one version of PL rather than having to have multiple copies of PL to update when a new feature comes out. The directory structure might look like this:

- builder
- config
- core (where the core view files are)
- listeners
- public
    -- wvnano
    -- english
    -- admissions
- source
    -- wvnano
    -- english
    -- admissions

We could have a flag in config.ini that enables it and then allows the user to set which folder to build from. For example, maybe they're working on english and want to build out of source/english/ into public/english/. Then on viewing it'd be patternlab.localhost/english/.

On top of this we might be able to allow for a custom starter kit if someone has a common base of images, css, and patterns to start a project. Rather than blowing out core/ and worrying about us overwriting it maybe we could add an additional custom/ folder. Again, the feature is enabled in config.ini. Then when they add a folder to source/ and try to generate for the first time it can copy the starter kit from custom/, build the site, and they're ready to go.

Thoughts?

Installation error

Hey guys,
The Pattern Lab tools looks really interesting, but I just can't get the thing to install on my Windows / WAMP box. It's throwing undefined error PHP errors.

...Any thoughts..?

Cheers,
Dan

Planning a .NET version

I'm going to try and create a .NET version of pattern lab. Any guidance on what PHP functionality I'd be replacing would be appreciated to complement my own digging into the source. Plus any thoughts on the best way we could extract the static, language independent parts from PHP/.NET?

Cheers

QR code for Easy Linking on Mobile Devices

Idea stolen from Mixture but it's brilliant. No typing a long URL on phone. Can use a simple service like mini-QR code.

http://miniqr.com/api/create.php?api=http&content=http://www.wvu.edu&rtype=json&callback=foo

getHostByName(getHostName());

Make updating easier?

As it stands right now, to update to the latest version of Pattern Lab, you have to go fishing through quite a few directories. Is it possible to streamline this process in any way?

Add Request Var Parameters for Annotation and Code Views

Allow for links to start annotation or code view automatically. For example:

http://patternlab.localhost/?a=true or
http://patternlab.localhost/?w=30em&p=templates-homepage&a=true

Scripts don't work if run from a location that has spaces in the path

For example, running the generateSite.command when it is stored at the following location:

~/Documents/Folder With Spaces In The Name/patternlab/scripts/generateSite.command

will fail with the error:

Could not open input file: /Users/mattsims/Documents/Folder

Easily fixed by editing the scripts and wrapping the $DIR variable in the php command in quotes, eg:

DIR="$( cd "$( dirname "$0" )" && pwd )"
php "$DIR/../builder/builder.php" -g

Escaping Mustache tags in Jekyll

Right now, mustache code is being wiped out in the documentation when Jekyll compiles the site.

More information: http://stackoverflow.com/questions/3426182/how-to-escape-liquid-template-tags

Apparently, there's a Jekyll plugin that allows you to skip "raw" code: https://gist.github.com/phaer/1020852

I have no idea how to implement this, so any help would be appreciated.

Prepping for the Next Release

Just wanted to jot down things I should keep in mind as we prep for the next release:

• finish updating the CHANGELOG
• document the new features on the new pattern lab site
• update the README to point at the new pattern lab site
• update the wiki pages to point at the new pattern lab site
• create release-0.6.0 branch
• tag version 0.6.0 and merge into master
• publish those changes to github
• push v0.6.0 to the demo site

Can The WebSocket Stuff Auto-Connect When a Service is Started?

I keep forgetting to reload my browser window after I turn on the websocket servers. Should see if there's a way to keep polling the websocket ports so that the page "auto-connects."

Lineage

It would be great to know if pattern contains other atoms, molecules, or organisms.

Lineage could be a property of the Code View. For example, header.mustache may contain {{atom-logo}}, {{molecule-primary-nav}}, {{molecule-search-form}}. We could include that alongside the HTML and CSS of the pattern.

Selecting MQs Should Update Address Bar and History

This is going to be a pain but probably worthwhile in the end.

Custom Header & Footer for Templates

Find a way to provide custom headers and footers for Templates. Probably based on the depth (or lack thereof) of the mustache templates.

/styleguide/html/styleguide.html 404 for some files

Getting the above 404 errors on a fresh install after running builder for the first time

Link to RAW page

It would be nice to have a link to the generated page without the menu and all the patternlab stuff. Just what is in the iframe.

linking does not work

hi there,

if you want to link different templates and use:
{{ link.templates-templatename }}
it will be rendered to something like this:
/patterns/03-templates-10-subfolder-02-templatename/03-templates-10-subfolder-02-templatename.html
and this results in a 404.

so i put myself in sherlock mode and found this little buddy in builder.lip.php on line 304:
$this->d->link->$patternName = "/patterns/".$path."/".$path.".html";
a brief edit later
$this->d->link->$patternName = "../../patterns/".$path."/".$path.".html";
everything worked.

maybe there is a reason for the first linking pattern? would be nice to know

Errors on body click when running from file system

Anytime I click on the body of the style guide or pattern lab site, I get an error when attempting to post.

Anytime I click on a pattern header, I get an error when attempting to navigate there.

Performing the same on http://demo.pattern-lab.info/ does set the url with a query string, but it does not execute.

I will look at this later too if I have time.

Cannot redeclare class Generator in /builder/lib/generator.lib.php on line 74

When either running "php builder/builder.php -g" from the terminal or double clicking on "/scripts/generateSite.command", I get:

PHP Fatal error:  Cannot redeclare class Generator in /Users/fgertz/Sites/pattern-lab/patternlab-php-master/builder/lib/generator.lib.php on line 74
PHP Stack trace:
PHP   1. {main}() /Users/fgertz/Sites/pattern-lab/patternlab-php-master/builder/builder.php:0

sw_vers

ProductName:    Mac OS X
ProductVersion: 10.6.8
BuildVersion:   10K549

php -v

PHP 5.5.3 (cli) (built: Aug 30 2013 09:29:37) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

Does the Generator class need to be renamed? Do I need to upgrade my version of PHP?

Should the Watcher Auto-Start the Page Reload WebSocket Server?

If I'm watching the project for changes I tend to want the page to be automatically reloaded when the change happens. Is this a given? Should we combine them? Not sure about the technical hurdles of starting two separate processes (Watcher & reload server)

Styling Annotations

The dev branch now has a working annotations solution based upon the original work from your mobile first demo. From a styling perspective I think the following needs to happen:

1. Create the annotations styles for the styleguide and view-all templates. The elements that need to be styled on these views are: div.annotations which holds all of the annotations for a pattern, div.annotation which holds an individual annotation within div.annotations, div.annotation h3 and div.annotation p which should be self-explanatory.
2. Create the annotations style for the slider pop-ups. This is the #comment-container stuff in styleguide.css.
3. Decide if we want to offer something that's not so mystery meat on the pattern-only view. Mousing over elements to find out if they have annotations is sort of annoying. Maybe something more like the top graphic here? The tray element won't work for us but maybe the numbering would.

All of the annotation-related JS is now in public/styleguide/js/annotations-viewer.js and public/styleguide/js/annotations-pattern.js. The data is in source/_data/annotations.js. It's moved when the site is generated.

Note that CSS cannot be injected via JS. That breaks on the Apache-less version of PL because of security policies. I ripped out the styleguide.css injection in styleguide.js. For now I've hard coded the annotation pointer style in the head of the pattern header. It shouldn't matter that patterns are dirty since we 1) will be offering a code view and 2) we need to keep them dirty for all the JS stuff to work in Apache-less mode. We'll have to swing back and fix the colors pattern which is now broken without styleguide.css.

PHP E_STRICT warning

I fixed this PHP warning

PHP Warning:  Creating default object from empty value in /patternlab-php-master/builder/lib/builder.lib.php on line 330

The problem was line 310 of builder.lib.php file. The 'i' missed.
Only change this

$this->d->patternSpecifc = new stdClass();

for this

$this->d->patternSpecific = new stdClass();

:)

Add Version Numbers to Asset Requests to Blow Out Cache

Add a version number to the build tool so that we can better handle cache issues as we develop and push out releases.

Web address and email address form fields have the id "password"

Nice tool guys! I'm having fun playing with it.

In 00-text-fields.mustache:

    <div class="field-container">
        <label for="password">Web Address</label>
        <input id="password" type="url" placeholder="http://yoursite.com">
    </div>
    <div class="field-container">
        <label for="password">Email Address</label>
        <input id="password" type="email" placeholder="[email protected]">
    </div>

Pattern suggestion : tab blocks

The tab block pattern is an "organism" level UI element. It combines a "molecular" level tab element ( #48 ) with a series of content blocks.

Following criteria apply :

• only one content block can be visible
• there's a 1:1 relation between the visible block and the selected tab
• tabs can be positioned left, right, above or below the content block.
• content blocks can infinitely nest other tab blocks
• tab blocks can be integrated into panels ( #47 ) or combined with other navigation elements ( #48 )

See http://www.cascade-framework.com/components-tabblocks.html for demos of this pattern.

See also ( #50 )

generateSite.command - PHP Fatal error - Debian Linux

Hello, I tried to test patternlab-php on my computer (Debian Linux) and I get the following error:

Problem

when I run ./generateSite.command I get the following output:

PHP Fatal error:  Class 'Mustache_Engine' not found in /patternlab-php-master/builder/lib/builder.lib.php on line 75

builder.lib.php

    protected function loadMustachePatternLoaderInstance() {
        $this->mpl = new Mustache_Engine(array(
                        "loader" => new Mustache_Loader_PatternLoader(__DIR__.$this->sp,array("patternPaths" => $this->patternPaths)),
                        "partials_loader" => new Mustache_Loader_PatternLoader(__DIR__.$this->sp,array("patternPaths" => $this->patternPaths))
        ));
    }

This error is caused by not being able to instantiate the class Mustache_Engine. The 'autoload' function (Autoloader.php) find not the correct path to Engine.php file where Mustache_Engine class is defined.

Autoloader.php

    public function autoload($class)
    {
        if ($class[0] === '\\') {
            $class = substr($class, 1);
        }

        if (strpos($class, 'Mustache') !== 0) {
            return;
        }

        $file = sprintf('%s/%s.php', $this->baseDir, str_replace('_', '/', $class));

        if (is_file($file)) {
            require $file;
        }
    }

Solution

After reviewing the code, this error can be fixed by changing the folder's name containing the library 'mustache' to 'Mustache', as it is distributed, and changing the line 29 of builder.php file as sample.

require __DIR__."/lib/Mustache/Autoloader.php";

After these changes the application generates the pattern without errors in Debian Linux.

Code View on Pattern Detail Page

Code view is currently available on the view all page, but isn't functional on pattern detail pages.

Code view will include the markup, and will present all CSS affecting the module.

Top level "All" page does not show changes

The Top level "All" page ?p=all shows default content for all modules, even after changes to source files are made and the site is regenerated.

I edited /00-atoms/00-global/00-colors.mustache, rebuilt the site, and changes show up fine at /?p=atoms-colors, and /?p=viewall-atoms-global but /?p=all still shows the default content for Atoms > Global > Colors.

This happened with after making small test changes to other modules as well.

Cleaning Up the Mobile View of Pattern Lab

After looking at the Pattern Lab demo on my iPhone I was thinking how we could clean up the view some. Or at least investigate things more. Things to address/investigate:

1. Making sure the iframe is full width. Right now it looks like it's the viewport + pull bar so it's not an accurate width. How to decide when to drop the pull bar? Touch event support?
2. Remove annotation & code view options. Both functions have a set minimum width of 650px before they're enabled. This is a hold over from the mobile first demo. Do we want to continue with that minimum? If so then those options should be removed on smaller screens.
3. Menu closing bug. The nav menu doesn't close all the way on smaller screens. Just have to figure out what's going on there.
4. Remove overlap of toolbar with pattern. The toolbar overlaps the top of a pattern. If possible, should the toolbar be hidden by default? For example, I don't know how well scrollTo is supported anymore but on load we could scroll down the height of the tool bar. It would be findable but off-screen at the top.

I didn't dig too much into it on my iPhone. I'll try testing more on other devices during the week.

Pages Should Build From Template templates

Pages shouldn't require their own mustache templates. Instead they should be defined simply by the custom data in JSON. Also, a Template should be able to have multiple Pages so that custom regions can be defined/previewed without creating a lot of duplicate mark-up. Custom Page JSON files should build upon one another to reduce duplicate content. For example, the file layout should look like this:

templates/
    homepage.mustache
pages/
    homepage.json
    homepage-emergency.json

homepage-emergency.json will use the templates/homepage.mustache as the base template. When rendering homepage-emergency the homepage.json file should be loaded and then homepage-emergency.json appended to/overwriting that data.

Refactor $patternPaths, $navItems, & $viewallPaths into one object

Try to see if I can refactor and create one object that handles the needs of the various nav and path objects. Keep forgetting what's in where and what's clean where.

Pattern suggestion : panels

Panels are a "molecule" level UI element that can contain the following "atomic" elements :

• headers (at least 0)
• bodies (at least 0)
• footers (at least 0)

Further, following conditions apply :

• a panel must contain at least one header, body or footer
• panels are infinitely nestable
• if a panel collapses (using JS), the header is used as a trigger. A header never collapses
• if a panel collapses, a body always collapses. A footer optionally collapses
• panels are content agnostic. They should be able to integrate other "molecule" or "atomic" level UI elements such as : tables, menus ( #48 ), tab blocks ( #49 ), datasheets (editable tables), forms, graphs, figures, ...

See http://www.cascade-framework.com/components.html for demos of this pattern.

See also ( #50 )

Resource suggestion : Cascade Framework

Cascade Framework is a framework with a highly modular OOCSS inspired architecture optimised for both performance and flexibility.

Consider the following features :

• Cascade Framework contains advanced components like “panels” ( #47 ), “navigation” ( #48 ) and “tab blocks” ( #49 ) components that can be combined in various ways.
• Cascade Framework is design agnostic. You can choose the default theme, create one of your own or just work with your own project specific custom design and leave out the default theme entirely. Both typography and color scheme are separated in separate modules to suit that purpose.
• Cascade Framework allows you to choose between a Semantic Grid technique and a presentational grid technique.
• With Cascade Framework, you can use any number of columns you want (1,2,3,4,5,6,7,8,9,10,12,16 and 24 columns are supported) throughout your project and nest them freely.
• Cascade Framework’s grid uses a special padding element for its gutter, which combined with the media object integration makes the grid both more powerful and easier to use than any other grid system.
• The total CSS code of Cascade Framework is only about 10kb minified and gzipped and can be further reduced if you don't need all modules. For many projects, you’ll do fine with a build of Cascade Framework with that’s only about 4kb bytes.
• Cascade Framework has a “light” version that’s no more than 2010 bytes in total. While it doesn’t contain components like panels or tabs, it still offers you a clean design for a whole bunch of elements, support for IE6, responsive behavior, etc. If you need just its grid features, you can go as lightweight as 323 bytes.
• Cascade Framework offers support up to IE6 and there are no plans to drop support for older browsers in the near future.

More info :

Cascade Framework docs : http://www.cascade-framework.com/index.html
Cascade Framework Light : http://jslegers.github.io/cascadeframeworklight/
Cascade Framework FAQ : http://www.cascade-framework.com/faq.html
Demo Application built with Cascade Framework : http://www.johnslegers.com/lead-dashboard/

Hay mode needs a "it's shit!" / pause button

Possibly report current window dimensions in terms of px, ems, and furlongs. All the cool kids size their CSS in furlongs now.

Native Controls

The command line can be hard/intimidating for a lot of people, so it would be great to have a GUI for the command line controls. The controls would include:

• Build
• Watch Pattern Lab for changes
• Auto-update (refreshes the browser on save)
• Page follow (refreshes the page on all connected devices)

Suggested naming scheme

This is not a top priority nor is it a "request", but rather an enhancement-to-be-considered.

Instead of making a new "naming scheme" for CSS components and modules.
I have a suggestion to make regarding the naming scheme of the Atoms, Molecules and Organisms.

While these terms relate better to Labs etc. hence the name Patternlab.
I would rather use a "standardized" naming scheme for this type of product.

Atoms => Components
Molecules => Modules
Organisms => Patterns

This is not to bash on the work you have done, but it can be confusing the first time you open and edit the files.

Take it into consideration, maybe the naming scheme can just be a flag you can turn off/on as you see fit.

Best Regards
Lucas Dechow

Comment on pattern

The original patternlab by @bradfrost had a commenting system for the patterns.

Is it possible to have it again ? It would be nice ... and helpfull

Features for v0.8.0 Release

For tracking progress on v0.8.0. Should be released at some point >.< The issues I'd like to cover:

• add support for KSS as a plugin. include breakpoint & pattern reference support. (#34)
• add support for Faker as a plugin. (#174)
• custom header and footers for top-level patterns (#30)
• add multi-site support (#55)
• leave comments on annotations (#91)
• refactor styleguide.js (#92)
• browserstack integration (#90)
• listItem customization (#167)
• add lineages to "list view" (#160)
• make sure cmd+a for selecting text only fires when code view is up (#162)
• add keyboard shortcuts for nav (#150)
• allow for chunking of _data.json (#141)
• add support for _docs (#130)
• multiple classes for style modifier (#172)
• annotation/code buttons on style guide view (#173)
• support the ability to extend to other pattern engines other than Mustache
• support data being defined in YAML in addition to JSON
• can use link.[pattern-name] within data to link to other patterns
• pattern parameters can support simple lists (#179)
• pattern parameters run a find & replace more like mustache (#178)
• only override cmd+a when code view is up (#162)
• json linter to provide better error messaging when there's a data load problem (#175)
• yaml linting for better error handling (catch symfony error)
• listItem loop number can be overridden via pattern parameters (#167)
• smarter sorting of MQs (#182)
• smarter selection of MQs (#253)
• search all of the project for MQs (#197)
• move shared header/footer out of _patterns/atoms and into `
• expand console options
• deprecate core/builder.php in favor of core/console
• add support for "snapshots"
• smarter lineage support (#191)
• view all pages for sections with pattern sub-types (e.g. atoms) (#203)
• ability to define custom mustache helpers (#209)
• event notification support for PLs back-end
• plugin system that attaches to various events in PL (#93)
• push plugin mark-up to the front-end viewer (code panel and nav bar)
• break out the "viewer" from PL proper. load nav via a JSON file.
• break out the "demo" mustache files from PL proper into a separate "starter kit"
• ability to organize patterns in nav via JSON in addition to file system
• annotations can be defined using Markdown
• multiple annotations can be defined in one Markdown file
• annotations can be defined along-side patterns
• pattern documentation via Markdown and YAML front-matter
• properly vendor pattern lab external libs using composer
• add composer to the distribution directly to limit a dependency but allow plug-ins to easily include dependencies add an install/update method for composer
• fetch util to grab starter kits, plug-ins, and mustache helpers
• switch to defining pattern attributes as JSON instead of explicit javascript vars
• global pattern data class to better handle import and sharing data
• colorful console
• switch the console to use long commands as keys to make it easy to modify that for plug-ins
• allow for patterns and static assets to be exported minus any PL cruft (#40, #67, #141)
• allow the font size used for displaying the ems to be overridden via the config
• can hide individual patterns from "view all" view but make them available via the nav (#257)
• switch to YAML as the default config format

For launch:

• update PL documentation
• update README
• update CHANGELOG
• cut a v0.8.0 branch
• merge with master
• tag master with v0.8.0
• update Releases

Pages vs. Templates

Should Pages have mustache-based mark-up? It seems like they really should just be Templates (the base mark-up) with custom data (to make the Pages more "real"). If that's the case then the only files that should be in 04-pages/ should be the .json files. This would make PL a little DRYer and make it easier to update Templates and Pages at the same time.

For example, the changes made when updating 03-templates/homepage.mustache should be seen when viewing templates > homepage or pages > homepage on the PL site.