imarc / boilerplate-archived Goto Github PK

Responsive CSS, HTML and JavaScript front-end starting point.

JavaScript 46.04% Twig 30.81% SCSS 23.14%

hacktoberfest boilerplate sass atomic-design abem

boilerplate-archived's Introduction

This probably isn't the repository you're looking for anymore. This repository is no longer being kept up to date, with all development happening on imarc/boilerplate-components, the full version of our framework.

Imarc Boilerplate

This is a framework for frontend development. It includes

Support for Sass,
A Pattern Library (powered by Fractal), and
A Front End Build (powered by Laravel Mix.)

This is the slimmed down version of imarc/boilerplate-components as it starts with only the utilities and base files from that repository.

If you want to slim down what's provided even more, you can change $use-boilerplate-classes to false in variables.scss to disable all the classes and only get mixins. (You will still get classes from Slick and FontAwesome.)

While we encourage you to read the builtin documentation, some highlights are

Uses Atomic Design
Uses ABEM
Uses Twig

Notes

Some components were carried over from version 3, but were not updated to the latest practices and syntax. These are flagged as DEPRECATED within the pattern library, and may be removed entirely in a future release.

Getting Started

Within a new project, make sure you first have an existing package.json. If you don't have one, you can create one by running

npm init -y

After that, run

npx imarc/boilerplate

NPX should automatically copy the resource folder to your project, add dependencies to your package.json, and even add scripts to your package.json file.

Usage

After running npx above, your project will be automatically setup so you can run

npm run dev to run the development build (make sourcemaps, don't minify, etc.)
npm run prod to run the production build.
npm run watch to watches files for changes and automatically re-run the development build.

To locally serve the pattern library:

npm run fractal start -w to run a local server and watch for changes

And lastly, to build the pattern library:

npm run fractal build

You can customize this behavior further by editing either the webpack.mix.js or fractal.js files per the Laravel Mix or Fractal documentation respectively.

boilerplate-archived's People

Contributors

Stargazers

Watchers

Forkers

jeffturcotte muminoff paulkelley hwm18 maffen receptor struto jeffzaccagnini terminocity universallythinking dmontesi awesomeboilerplate

boilerplate-archived's Issues

Add copyright, info

Should we add a copyright, version, license to stylesheet?

Twitter Bootstrap uses something like this:

/*!

Bootstrap v3.0.0
*
Copyright 2013 Twitter, Inc
Licensed under the Apache License v2.0
http://www.apache.org/licenses/LICENSE-2.0
*
Designed and built with all the love in the world by @mdo and @fat.
*/

Margin consistency

Do we want to be more consistent with margins? Some styles have margin top & bottom, others just margin bottom. I thought that we generally used just margin-bottom.

@marcelmoreau - thoughts?

In the current boilerplate:

headings (h1-6): margin bottom (1.5em)
p: margin top & bottom (1.5em each)
blockquote, pre: margin top & bottom (2em each)
lists: margin top & bottom (1em each)
div messaging (errors, success): margin top & bottom (1em each)

p tags inside messaging blocks have no margins:

<div class="info">
<p>We couldn't complete your request...</p>
<p>Go to the homepage and do something</p>
</div>

Update Headers

These should be updated to reflect the header in index.php

Tags included in the Boilerplate

I'm stripping out things we don't use after a conversation with Marcel, Jeff, and Dave yesterday, so that the boilerplate won't bother to add styles for tags we never intend or plan to use. If we are going to use those tags on a specific site, we can add specific rules for those tags – we'd all rather be adding things than removing things from the boilerplate on new projects.

I've left support for b and i, as these are used by Redactor by default.

We should discuss div.callout, div.highlight, versus <aside>.

I've left <section> and <article> in as I think we should use those going forward, but we can talk about that too.

Sticky element plugin - another option to unstick

Can we create an option to unstick the sticky element when another element comes INTO view (not just when it's even with the sticky element)? Thank you!!

mobile nav overlay scroll issue

I made a new branch for more work on this. The attached video shows an issue with the body scrolling behind the menu. The overlay does not fill. I was able to resolve this by toggling overflow and position on the body. Can you look at the video of the issue and refactor what I did provided you like the fix?
mobile-menu.mov.zip

Full width header/footer

Shouldn't the header be full width? I think this is a pattern we use much more often than what is currently implemented.

You can see the rough proof of concept on my fork:
http://jeffturcotte.github.com/boilerplate/markup.html

Here is the commit:
jeffturcotte@7ac09ab

If we agree, we can work to figure out the best implementation.

Table of contents' order

I feel both links, lists, headings and web fonts could fall under typography
layout seems like something that should appear higher in the CSS
print could be last
layout could have things like header, torso, footer within it

Pick Icons

After Issue #31, we talked some about the icons we have. Here's a selection of 24 icons from FontAwesome.

I'm showing the icons at 12px and 14px, as small sizes is what brought up the issue the first time. Please tell me what icons you would want to add or drop from what's available in FontAwesome.

The FontAwesome font itself, as is, ranges from 37K (.eot) and 194K (.svg).

I say we just use the default FontAwesome font. We can come up with our own CSS for Boilerplate, so please ignore all the markup/CSS for FontAwesome.

Still, it'd be worth picking a small set of icons to 'showcase' on Boilerplate, use as defaults to be consistent, and so we can integrate them into things like Boilerplate messaging, etc.

If we're worried about the size of the FontAwesome font, then we can always make a stripped down version that only includes the subset of icons we like.

Are primary/secondary scoped per document or per layout element?

For example, should the first nav element inside of aside.primary always be nav.primary because it is the primary nav element for the aside regardless of whether it is the site's secondary navigation, or should nav.primary always mean the site's primary nav, nav.secondary always the site's secondary nav, etc.

Leftover styling and component placement

There are styles for footer.primary here:
https://github.com/imarc/boilerplate/blob/gh-pages/css/styles.scss#L448

That are overwritten by the inclusion of the footer component here:
https://github.com/imarc/boilerplate/blob/gh-pages/css/styles.scss#L874

Is the earlier selection an accidental carry over? Should we be putting components as late in the sass file as we are? Seems to me you'd want to lead with base stuff so you can build on top of it.

(This is based on the assumption that the _components.scss file shouldn't be edited)

Add a default list view to Components

Components should have a default list view for things like search results, lists of news items, events etc.

missing closing bracket

https://github.com/imarc/boilerplate/blob/gh-pages/js/bp.js#L6

no closing bracket here caused issues on WSI. Is this on purpose?

@jeffturcotte @khamer

From text inputs on iOS

On the iPhone 4 the text and textarea inputs are invisible.

Pagination mixin is missing documentation

Boilerplate 1.2 Tasks

Just making a list of tasks to get done before merging 1.2 back:

update FontAwesome files
restructure sections to 1. webfonts 2. variables 3. mixins 4. base ...
most likely remove query-label
check whether the doubling of media queries is necessary anymore
fontstack variables?
update/verify gradient syntax

Web fonts –– why use two implementations?

I see the @import in the CSS file and a standard <link> in the HTML.

Closing mobile menu

On the mobile view, I click the icon to open the navigation menu. I expect clicking the icon again will close the menu but it doesn't

Comment style needs to change

We really just need a better css comment standard across the board. Right now sections are something like this:

/* == section ====================================== */

But this is cleaner and more manageable:

/* section */

I never want to have to copy a comment from elsewhere, or count a certain number of characters to make a new comment.

We need a license

This should be licensed accordingly before we put it out there: MIT or BSD would be my preference.

LESS or SASS?

http://lesscss.org/
http://sass-lang.com/

This could be a good project to try one or the other out. If we don't like it, we compile it at the end and leave it at that.

I'm currently leaning towards LESS for the only reason that it can be compiled client-side in JS. Not that we would ever put it into production like that, but it drops the technical barrier for testing it out (and UX/Creative contributing) to zero.

As for server side, Assetic supports both: https://github.com/kriswallsmith/assetic

Search Drawer doesn't work properly with stickyHeader

Our default setup with both stickyHeader and searchDrawer in use makes it immediately obvious that if you scroll down a bit and pull up the stickyHeader, the searchDrawer opens off screen.

Javascript file structure

Default position of header.primary should be relative.

The megamenu breaks if you use it without the sticky header component. It was fixed by adding
position: relative; to header.primary.

Tabs should have better mobile experience

On small screen, tabs could turn into accordions or have a general better experience

Standards vs. Good Practice

This came up in chat the other day, and I wanted to bring up here as an issue for discussion and possible action.

IMO the use of <meta charset="UTF-8" /> is a hack that we should avoid. Although this is now in the HTML5 spec, it was brought into HTML5 based on the fact that browsers didn't bother to properly parse the meta tags within the first 512 bytes of HTML which are used to determine document characteristics.

The traditional way to set the character type was as part of the content-type which would normally be a meta tag with an http-equiv attribute:

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

Assuming HTML is being served to a user, the content-type header should contain the equivalent of the string in the content attribute above, in which case, the shortened meta tag we are using is redundant. In the case of HTML which is loaded directly in a browser from a file, the browser is left to determine the content mime type in a document which does not provide the full meta tag as above.

In 99.9999% of cases this tag only needs to be written once, and realistically is not written by our developers at all, but is instead included in default templates. I see no actual value of using the shortened tag which promotes the use of an isolated attribute born out of hacky browsers instead of the more complete http-equiv type which is content-type complete in the event the file accessed over HTTP.

I do, however, feel that there is much value in ascertaining and supporting best practices. There are lots of things which are possible to do in HTML5, as there are in any language, but we define and follow best practices to ensure the most robust, explanatory, and flexible methods are chosen and promoted for us, but also for the larger developer community -- if this is not the case, then I propose we remove the self-closing / at the end , cause that's 100% valid too, and obviously at that point we're just trying to save characters.

No hover states in dropdowns or on navigation in header

Both the primary and secondary navigation as well as the items in the drop downs don't have hover states anymore. This includes no hover states in the mobile view.

Messaging markup

I have always preferred using an outside div and a paragraph inside for messaging. It's often required to have two levels of tags to achieve site designs. RIght now, we only have a div and then text. The code below reflects what I'd like to see.

<div class="success">
    <p>
        <strong>Success</strong> – Message with a <a href="http://imarc.net">link</a>.
    </p>
</div>

Switch markup placement of aside.primary and div.main

Semantically should div.main appear before aside.primary in the markup?

And if there were a left and right column, I'd think that div.main would still appear first in the markup.

Register Boilerplate as an NPM package

It would be great if I could

$ npm install imarc-boilerplate

or something

Tabs mixin is missing documentation

At tablet widths, aside.primary spills into icons

Something's just missing a clear, probably the icon stuff.

stickyelement per breakpoint

With many anchored navs, there will be desire to NOT stick these on mobile, but still have it statically on the page. Right now, we put in inline css to assign the fixed positioning. Should we use a class instead so we can keep elements static at certain breakpoints?

Mobile Menu overflow-y

I should have kept the branch...

If a navigation has many links, there is currently no way to swipe down to see them all as mmenu has.

The attached image shows dev.bidneedham.org's mmenu with may links. I was able to swipe down to see them all.

mobile navigation tabindex="-1"

On our sites that use mobile navigation, the tabbing gets screwy. The ideal behavior is

a user can tab through relevant elements based on focus styles visually guiding them
there are no redundant repeats of source code in the markup that require blind users to hear things twice

Our mobile nav component clones elements from the primary and utility nav. This is fine. We just need to ensure that all buttons and anchors in our .mobile and .subMenuClass elements have a tabindex="-1".

Broken links

https://github.com/imarc/boilerplate/blob/gh-pages/README.md

In README.md, the link to See the CSS is broken.

Inconsistent sections

We have three main sections: header.primary, .torso, footer.primary

header.primary,
.torso,
footer.primary {
    position: relative;
    margin: 0 0 2.5em;
}

We also have .mold to act as a container.

.mold {
    margin: 0 auto;
    max-width: 1024px;
    padding: 0 16px;
    position: relative;
}

For torso to be contained we do:
< div class="torso mold" >

But we can't do < header class="primary mold" > or < footer class="primary mold" > because of specificity issues.

Should .mold's margin be !important ?

Branding

Should this project be branded at all?

Obviously, we want it branded for our own use, but as an open project, wouldn't we want to default to be generic? Currently anybody using the project out of the box would be repurposing our palette for their own use. Just a discussion topic, no action necessary yet.

stickyElement.js clean up

Include documentation in the component's HTML page as well
Methods of FixedElement should use 'this' instead of 'that'
Variables set to jQuery objects should be prefixed with $
Clean up conditionals

accordion should be structured differently

making a note of this here...

accordion should be structured differently to allow for more robust styling...see EduBoston landing page as an example.

Structure still up to date?

http://imarc.github.io/boilerplate/structure

Is this page still accurate? (Structure, linked from the README)

HTML Difference?

From Dave:

What's the difference between the markup_test.html and html5_test.html? Do we want to be maintaining css that works with two sets of markup? If there is a difference, should we set the meta description to describe what each file is for instead of just "iMarc, LLC"

sticky element

Add a class or data attribute to the item being stickied

Glyphs are messed up

Typing in an element causes other glyphs to show up. For example:

<a href="" class="icon_cancel">Hello World</div>

nav.primary vs nav.secondary... and beyond

Currently for the active, secondary nav we repeat the DOM information three times. In the nav.primary drop down, in the nav.secondary ul, and in aside.primary. This is really unacceptable. I am willing to accept that it will always exist in two places (the header and the aside,) but twice in the header is not right. @mattsah and I had a good solution for this on the Moto Enterprise site: the drop down secondary nav (ul > li > ul) DOM structure doubled as the active secondary nav bar. This did require a significant number of selector additions for targeting ul > li.active > ul and all its child elements, but I believe it is 100% worth it.

Practically speaking... I ran into an actual issue with this when attempting to implement a sticky navigation bar. It was impossible to do without adding an extra element as a container.

That all said... does this make sense for the UX and creative teams? I will solicit their input.

Change navigation to ULs and add support for .active

After reviewing more markup per @mattsah 's comments, I'm going to revisit the markup here some. While a tags can be directly inside of nav elements and that's probably best for utility or 'in content' navigation, since the primary/secondary navigation is usually hierarchical it really still needs to be in lists. I'm opening the ticket so I don't forget.