search

pattern-lab / patternlab-php

The PHP version of Pattern Lab
http://patternlab.io
MIT License
3.06k stars 456 forks source link

Single Pattern View: Display Pattern Name #29

Closed bradfrost closed 10 years ago

bradfrost commented 10 years ago

pattern lab - atoms-colors

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.

dmolsen commented 10 years ago

Some questions...

  1. How does this work with Templates and Pages? They get the same header and footer as Atoms, Molecules and Organisms.
  2. How do annotations work in the context of Templates and Pages? They can't just be stacked below all the elements. That's why I implemented the "mobile first demo" style of pop-up.
  3. Does this add padding to a pattern thus negating some of the benefits of the iFrame resizing for testing or determining breakpoints? Or is that even a concern for Atoms, Molecules and Organisms?

Some clarification on what you mean by "so that we can use the same code" would be helpful. Not sure what the goal is. Need to make sure I'm not going too far afield with my implementation. I was sort of hoping on the pattern view we could use the "mobile first demo" style of pop-up for the code view too but if that's out I'll have to rethink some things.

bradfrost commented 10 years ago

Good questions.

  1. Is it possible to make a distinction between page-level (templates and pages) and non-page-level (organisms, molecules, and atoms) elements? I think including the header and pattern wrapper HTML makes sense for these non-page-level elements, but yeah it doesn't make sense for those to appear on page level stuff.
  2. Annotations will be handled the way it is in the mobile-first demo. The user will click on an annotated element and the annotation will pop up. A phase 2, nice-to-have version of annotations would allow users to view all annotations for all the elements on the page. That will require a bit more thought, but just keep it in mind.
  3. Good call. At first glance, including the padding for non-page-level elements seemed like a nice way to avoid things butting up against the viewport, but yeah that causes problems. That is a legit concern, especially for things like headers and footers, which I've always coded in isolation. The padding would throw things off. Maybe I can remove the padding across the board, and only apply it to the pattern wrapper on the list view.

Some clarification on what you mean by "so that we can use the same code" would be helpful.

Basically, code view and annotation view don't work because they're looking for the contents of sg-pattern-body. By including the wrapper markup, code view and annotation view code works.

I was sort of hoping on the pattern view we could use the "mobile first demo" style of pop-up for the code view too but if that's out I'll have to rethink some things.

We can totally do that instead.

dmolsen commented 10 years ago

k...

  1. It might be possible. Templates and Pages are rendered out of a different "level" (i.e. they don't have sub-types) so I might be able to use that as a hook. I've been wondering for a while if Templates should be allowed custom headers/footers so maybe this is a chance to try to implement that.
  2. Definitely doable. But, yeah, more thought needed. The core is there... just need to figure out UI.

On the code view/annotation stuff... I'm going to have to rewrite the code view stuff. The jQuery-based hop in styleguide.js from the "viewer" to the frame contents and then using sg-pattern-body is nice/fast but it will puke if someone tries to use Apache-less mode. Security policies can be a bitch. It's why I've done all of the communication between "viewer" and frame contents with postMessage. Hence, annotations-viewer.js and annotations-pattern.js. I know the annotation stuff I have going now doesn't require sg-pattern-body. It's checking for .pattern-list on <body> in the style guide and view all templates.

bradfrost commented 10 years ago

On the code view/annotation stuff... I'm going to have to rewrite the code view stuff. The jQuery-based hop in styleguide.js from the "viewer" to the frame contents and then using sg-pattern-body is nice/fast but it will puke if someone tries to use Apache-less mode. Security policies can be a bitch. It's why I've done all of the communication between "viewer" and frame contents with postMessage. Hence, annotations-viewer.js and annotations-pattern.js. I know the annotation stuff I have going now doesn't require sg-pattern-body. It's checking for .pattern-list on in the style guide and view all templates.

Do what you gotta do.