Comments (4)
Hi team! FYI, I'm in the process of looking at these styleguides:
To-read next: http://engineering.lonelyplanet.com/2014/05/18/a-maintainable-styleguide.html
For the record: http://styleguides.io/ (all the things)
from frontend.
Thoughts after reading A Maintainable Styleguide from Lonely Planet:
This article talks about Lonely Planet's development of what sounds like a pattern API. Its developers can call different bits of website and pass certain variables. The code is then able to be maintained in one place and propagate across parts of the site.
Reflections:
- At first I liked this idea, but then started thinking about how one would maintain something like that across multiple sites. We are building many things with many partners that will rely on many flavors of frameworks, so perhaps not so much. Updating the API would risk breaking too many things.
- HOWEVER...we do need a solution for keep styles in line across 18F repos (the work that the dashboard and hub teams started [using one github repo to power the data for several others] needs to be expanded somehow to styles). So, maybe there is a grain of a way forward to be pulled from that article.
- A great final note from the article:
I believe that the difference between Rizzo [their component api system] and our previous two Style Guides, in terms of their successfulness, is that with Rizzo we didn't focus on the Style Guide as the deliverable. Instead we focused on reducing complexity and increasing reusability.
Thinking about that final note -- I wonder what would do that for us? Perhaps some sort of atomic components based in Jekyll/Sass, since so many of our sites live there (...but then again, some don't so is it worth our time?).
After (lightly) reviewing the guidelines in my previous comment, perhaps something like Mailchimp's pattern library is the closest to what we were talking about on our call today. The structure is clear, there are notes on all the usage and decisions. I could imagine those being components that are copy-and-pasteable from a website as well as available in a grab-and-go entire simple site website template (like we talked about).
HOWEVER...this does not get at the list of 'things to keep in mind' at the top of this issue. Out of the more nuts-and-bolts CSS grammar styleguides I looked at, I did not agree with many of the choices in http://cssguidelin.es/ and so stopped reading part-way through (tl;dr syndrome). I liked bits of ThinkUp, Github and Mapbox, but wouldn't want to go with any of them whole-cloth. You may not be surprised since I already started doing this in Google docs, but I still say we'll need to stitch a CSS/Sass styleguide together from others to meet our preferences. I am happy to revise this opinion if y'all find something we like and want to recommend :)
That's all for now!
from frontend.
Latest draft available here. It will follow guild process described in our README for becoming a final (although always living) document.
from frontend.
Closed with #15
from frontend.
Related Issues (20)
- Add output encoding section to security guide HOT 2
- Add same origin policy to security guide
- Add defensive programming section to security guide
- Include content security policy section on security guide HOT 3
- Truncated text in Vanilla JS subsection of Web Components chapter
- Remove Hound recommendation - replace with Code Climate? HOT 2
- Standardize on writing "JavaScript" or "Javascript"
- Footer links to old Federalist link
- Add React section HOT 1
- Audit guide content HOT 2
- Discuss whether the Libraries section in the guide is useful HOT 1
- Set up the glossary module to be continuously published to NPM
- Set up the accordion module to be continuously updated on NPM
- Should we move the Web Components section to a wiki page? HOT 1
- Crawl or survey 18F's GitHub projects to create a snapshot of front end tech in use HOT 1
- Link to other guides where applicable
- Link to wiki on guide HOT 2
- Revisit the distinction of Front End Design and Engineering roles
- Google Analytics not working HOT 1
- Rewrite Sass guidance to reflect deprecation of Ruby Sass
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from frontend.