Design and plan for a way to insert status indicators for a concept into the guides.
This is a placeholder issue. I will unassign this ticket once I've updated it fully.

Create an es-sidebar-menu component. Could be named differently if we think of something more concise/elegant.

Requirements:

• should not be inside of the aside element (we may wish to put other things in the sidebar- this component should just be the menu portion.
• should use semantic HTML
• should be keyboard navigable for users with assistive technology
  • TAB should take the user to the menu
  • ARROW UP and DOWN keys should move them within the list
  • ENTER or SPACE should expand/collapse sections to reveal/hide subsections
• should look like the current sidebar in the guides (see screenshot below)

Screenshot:

In order for the addon's styles to be correctly rendered in the application, the styles need to be in the app/styles folder.

There are more complex ways of dealing with this, but this is a straightforward route.

Expected Behavior

Roboto font should render.

Actual Behavior

default sans-serif was displayed

• add ember-cli-google-fonts as a dependency.

This addon is now consumed via its git url in our other apps. git based dependency resolution is usually slow compared to packages from registries. Also ember install command has a weird bug where it removes git based dependencies post running it.

Besides these factors if this is published to npm & if we enable greenkeeper on our upstream repos, then it makes it trivial to propagate changes across apps. We'll have to setup ember-cli-release so that travis can run it on merges to master to publish to npm.

Thoughts?

For the next iteration of these components, we should be using angle-bracket components.

To Do

• Convert es-button to be a template-only/angle bracket component
• Update documentation (in dummy app)
• Submit PR to the feature branch for angle bracket components (feature/angle-bracket-components)

Supporting Resources

• Video: Angle Bracket Component Invocation in Ember.js
• Video: Template-only components in Ember.js

Create blueprints for the necessary layouts- we can use this issue to discuss the options.

At a minimum:

• responsive/ device-agnostic
• full-width content with header and footer
• header, footer, sidebar, main (sidebar on left or right?)

When an un-ordered list is required.

• support a heading whose element type can be defined (h2-h6, p or div)
• list should be linked to heading via aria-describedby attribute
• The <li> should block yield, but when implementing styling, think about what could go inside-
• a link
• a link with a small image or icon to the left or right
• regular text

Possible outcome:

Supporting resource: understand the difference between visible focus and screen-reader focus: https://codepen.io/melsumner/pen/ZJeYoP

For the next iteration of these components, we should be using angle-bracket components.

To Do

• Convert es-ulist to be a template-only/angle bracket component
• Update documentation (in dummy app)

Supporting Resources

• Video: Angle Bracket Component Invocation in Ember.js
• Video: Template-only components in Ember.js

Is there any intention to provide a sidebar component? I could not find any previous discussion on the topic.

I have reviewed some projects and it looks there is a common pattern on:

• Builds
• Deprecations
• Guides

I could work on it but it could be good if someone could spec the requirements.

I think, an initial start could be to create a sidebar component that can be reused in these 3 projects, so I wonder if the component should support two design types or use always the design used on the guides?

Context:
Help is needed to complete the work started on the es-navbar component in this addon. This is the navigation component that is intended to be used on the emberjs.com website, along with other "Ember Family" websites (ember-cli, fastboot, etc).

Criteria

• mobile-first responsive web design (RWD)
• use semantic HTML(5)
• should (also) be keyboard-only navigable
• should support sub-menus (at least one level deep)
• should work in Chrome, Firefox, Safari (current ver. -1), IE(11, and Edge

Expected Behavior

When reading or adding styles for a component, I would expect to see styling applied via classNames rather than raw tag references (i.e. li vs. a class attribute on that li).

Actual Behavior

Styles include references to raw tags

Proposed solution

I propose that all new components be written using classNames for styling hooks, rather than attaching styles to raw tag names. We could check this in new PRs to ensure this style is maintained for new code going forward and should work to update existing styles to maintain this style for components that already exist.

Add ember-fontawesome to be used for icons. https://github.com/FortAwesome/ember-fontawesome

As a result of the work on #108 @aklkv noticed that there are no tests for es-ulist currently and adding tests would not be part of the scope of that PR.

I am creating this issue and assigning it to @aklkv so that we can keep the progress moving and he might tackle it after this current work, along with some work to add ember-test-selectors 👍

Expected Behavior

There is usually only one lock file in projects.

Actual Behavior

This one has both a yarn lock and an npm lock.

How to fix

• remove package-lock.json
• commit the change
• add package-lock.json to the .gitgnore file
• run yarn install and commit the changes to yarn.lock
• commit and open a PR

If you are an experienced contributor to this project and you complete this issue, please help make another issue friendly to new contributors or open an issue to help guide someone through a small fix.

This component can be used in places where there is a short list of items that would be made more interesting if they were interactive graphics.

For example, this:

Can become this:

Which becomes this on hover/focus:

See https://codepen.io/melsumner/pen/0b6bb9796cdd8f8c70ab942a2ba6d5d7 for a live code sample.

Acceptance criteria:

• background should be $orange & $orange-darken on hover/focus
• text should be a customizable property
• text should be positioned at the bottom of the graphic
• three items should be equally spaced across the smallest viewport (using Flexbox)

Expected Behavior

Multiple lines of text should not overlap. To fix this, you could either tighten the padding in the code highlighting block (make sure it doesn't cut off the ends of long letters like y and g), or increase line height of h3 elements.

Actual Behavior

Steps to Reproduce

Here's an example from the Guides.

Here's the markdown:

<h3 id="toc_resetting-presentation-state-on-attribute-change-with-didupdateattrs" class="anchorable-toc">
    Resetting Presentation State on Attribute Change with 
   <a class="toc-anchor" href="#toc_resetting-presentation-state-on-attribute-change-with-didupdateattrs">
   </a>
   <code>didUpdateAttrs</code>
</h3>

In building to test, I saw this warn pop up from Bower:

npm WARN deprecated [email protected]: ...psst! Your project can stop working at any moment because its dependencies can change. Prevent this by migrating to Yarn: https://bower.io/blog/2017/how-to-migrate-away-from-bower/

Not sure if this is something with the ember-learn tools or ember-cli in general. Is this of concern?

• add base styling for layout
  -- should be responsive
  -- decide: Grid? Flexbox? Box model?
  -- ship something now and upgrade later?
• update Readme to include flexi information

when ember-bootstrap was added, the original bootstrap stuff wasn't removed, and that's causing issues.

Hunt these instances down and remove all traces.

This component should support adding notes to guides and other bits of documentation.

• It should support saying "Tomster says..." or "Zoey says..." (randomly)
• it should use either tomster or zoey's head image, depending on the title
• on small viewports, no image should be shown
• heading color is $orange-darkest

Screenshots:

Expected Behavior

Lowest possible specificity for CSS tag selectors in order to apply proper styles

Actual Behavior

some nested tags/styles that cause unnecessary specificity

Proposed Solution

Code like this:

.es-component {
  li { ...
    a { ...
      img { ...
      }
    }
  }
}

should be more like this:

.es-component
  li { 
    ... 
  }
  a { 
    ... 
  }
  img { 
    ... 
  }
}

With the changes in #53 to using classNames instead of tagNames, styles should not bleed between similar tags (i.e. separate images in the same component). And lower specificity will make overriding styles simpler if needed.

This is a suggestion that needs input from @MelSumner before anyone should work on it.

Currently

Proposed (8px padding below h1)

add the slack logo & link to the slackin url

Replace all links to Slackin to the new Discord server.

Related Issue(s)

Merged RFC to move to Discord

Expected

Changes to be made on https://github.com/ember-learn/ember-styleguide/blob/master/addon/templates/components/es-footer.hbs#L28

For the next iteration of these components, we should be using angle-bracket components.

To Do

• Convert es-accordion to be a template-only/angle bracket component
• Update documentation (in dummy app)

Supporting Resources

• Video: Angle Bracket Component Invocation in Ember.js
• Video: Template-only components in Ember.js

• review es-navbar component
• write tests that are accurate
• ensure code is written to pass the tests; update component if necessary
• ensure all tests pass

Context:
The call-to-action(CTA) component can be used in any place where a CTA is desired. The content and button will be stacked on small viewports, but side by side on large viewports. If the text is too long, it will wrap. On a small viewport it will take up 95% of the viewport. On larger viewports, it will be contained to 85%.

Acceptance Criteria:

• component name should also be the class name attached to the component (via classNames)
• ensure this works as intended on IE, Firefox and Chrome
• ensure CSS is scoped to component, and written in a mobile-first way
• ensure the text content and button is stacked on small viewports, but side by side on larger viewports.

Screenshots:

For the next iteration of these components, we should be using angle-bracket components.

To Do

• Convert es-buttonbar to be a template-only/angle bracket component
• Update documentation (in dummy app)
• Submit PR to the feature branch for angle bracket components (feature/angle-bracket-components)

Supporting Resources

• Video: Angle Bracket Component Invocation in Ember.js
• Video: Template-only components in Ember.js

Acceptance Criteria:

• responsive
• when one panel is open, the other ones collapse automatically
• add aria-expanded to the control element (if the collapsible element is closed by default, the attribute should be aria-expanded="false".) See: https://www.w3.org/TR/wai-aria-practices-1.1/#accordion

Keyboard Interactions:

• Enter or Space:
• When focus is on the accordion header for a collapsed panel, expands the associated panel. If the implementation allows only one panel to be expanded, and if another panel is expanded, collapses that panel.
• When focus is on the accordion header for an expanded panel, collapses the panel if the implementation supports collapsing. Some implementations require one panel to be expanded at all times and allow only one panel to be expanded; so, they do not support a collapse function.
• Down Arrow: If focus is on an accordion header, moves focus to the next accordion header. If focus is on the last accordion header, either does nothing or moves focus to the first accordion header.
• Up Arrow: If focus is on an accordion header, moves focus to the previous accordion header. If focus is on the first accordion header, either does nothing or moves focus to the last accordion header.
• Home (Optional): When focus is on an accordion header, moves focus to the first accordion header.
• End (Optional): When focus is on an accordion header, moves focus to the last accordion header.
• Control + Page Down (Optional): If focus is inside an accordion panel or on an accordion header, moves focus to the next accordion header. If focus is in the last accordion header or panel, either does nothing or moves focus to the first accordion header.
• Control + Page Up (Optional): If focus is inside an accordion panel, moves focus to the header for that panel. If focus is on an accordion header, moves focus to the previous accordion header. If focus is on the first accordion header, either does nothing or moves focus to the last accordion header.

Pieces of component:

• "header" (not header element)
• body (block yield)
• footer

Screenshots:

Closed:

Open:

https://gitlab.com/NullVoxPopuli/emberclear/blob/master/packages/frontend/src/ui/styles/utility/flex.scss#L38

In emberclear, I'm using bulma,
so I have some responsive helpers that end up being used like this:

@mixin flexUtils($modifier) {
  .flex-row#{$modifier} {
    display: flex !important;
    flex-direction: row;
  }

  .flex-column#{$modifier} {
    display: flex !important;
    flex-direction: column;
  }
  // ...
}



@include mobile {
  @include flexUtils('-mobile');
}

@include tablet {
  @include flexUtils('-tablet');
}

@include desktop {
  @include flexUtils('-desktop');
}

@include flexUtils('');

this allows me to have more functional-style css, similar to tailwind.

Does something like this already exist?

• would it be cool if I add some utils to this repo if not?

The Headers currently look like this:

and when you add the following rule:

h1 {
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale
}

they look like this:

It is quite subtle with the Font Roboto but when the headers were using the wrong font it was very obvious. I don't know if this is even needed now that it's using the right font 🤔

There are three types of blog posts:

• regular
• syndicated (written elsewhere but re-posted here)
• guest post

The CSS for this component can be taken from the current website, which reflects the desired styles.

On the summary page:

On the individual post page:

Be sure to follow the semantic markup- this can be achieved by examining the rendered markup on the current blog (emberjs.com/blog).

There are four possible items in this element:

• an image
• a heading
• some text content
• a button (if used, es-button component)

Other criteria:

• A border color should be able to be defined
• the border color should be transparent by default (a11y)
• the image should have a border-radius of 2px if square
• the image should be allowed to be a circle
• the heading should be an h3 by default, but other tagNames should be acceptable to support semantic HTML

The image:

The image may be positioned:

• to the left of the text
• centered on top of the text
• positioned to the right of the text

The heading:

The heading may be positioned

• above both the text and the image (if the element is horizontal)
• above the image and the text (if vertical)
• below the image but above the text (if vertical)
  The heading should never be placed below all of the elements at once.

the Text:

may be placed:

• next to the image (either to the left or to the right, depending on the placement of the media image). In this instance, the text should be automatically placed based on placement of the image, the user shouldn't have to place both.
• under the image

Sketch of possible iterations:

The existing ember orange #E04E39 fails minimum color contrast against the white foreground text (as is already indicated in the README).

Just wanted to make a suggestion for #D14632 which is visually extremely close, but passes WCAG 2.0 AA criteria 1.4.3 Contrast (Minimum) with a ratio of 4.53:1 against white text.

White on orange

Comparison of existing color vs new color

Just wanted to note that I think the color palette on the site might be a little bit off, or need some slight tweaking. For example at https://guides.emberjs.com/release/testing/testing-components/. I see the body has background-color: #FDFDFD;, the code example has background-color: #151515;, and the base font color of the code example has color: #f8f8f2. I find this white frame, black box, white text arrangement is a hard on the eyes, but if it’s for accessibility I can certainly live with it or install an extension to tweak it to my liking. Thanks very much to everyone who worked on the site, btw, it looks great 👍

Example screenshot attached:

In order to increase flexibility for multiple sites, add ability to define themes.

For the next iteration of these components, we should be using angle-bracket components.

To Do

• Convert es-blog-heading to be a template-only/angle bracket component
• Update documentation (in dummy app)
• Submit PR to the feature branch for angle bracket components (feature/angle-bracket-components)

Supporting Resources

• Video: Angle Bracket Component Invocation in Ember.js
• Video: Template-only components in Ember.js

Replace the current ember logo (for the navbar) with the one that has the trademark.

Expected Behavior

The data should be separate from the component. The data is an application concern. The footer component itself shouldn't care.

Actual Behavior

The current footer component is only the emberjs.com website footer.

There isn't much to this component because it is going to contain other things.

Requirements:

• header element
• 100% width of viewport
• should support background image
• should have a background color of ember-orange by default, but other colors should be able to be specified

Context:
Support is needed for h1-h6 heading elements.

Needs:

• should support adding h1 to h6 for the tagName
• should support uppercase styling
• should support page title and section title (classes?)
• ensure that appropriate default sizes exist
• support mobile-first responsive web design (RWD)

Need to write SCSS linter rules that will enforce specific CSS code standards.

• lowercase class names
• no IDs
• possible to enforce naming structure for color variables? if so, colors should be named like this if they exist:
  -- $color
  -- $color-darker
  -- $color-darkest
  -- $color-lighter
  -- $color-lightest
• properties should be in alphabetical order
• css should be mobile-first. I.E.

.my-button {
    width: 100%;
    padding: 0.1em;
    border: 1px solid $blue;
    @media screen and (min-width: 768px) {
      width: 50%;
    }
    @media screen and (min-width: 992px) {
      width: 25%;
    }
}

• color variables should only be in a _variables.scss file.
• headings should only be declared once.

Context:
The addon needs a consistent button element that covers the correct range of button needs. The button component already exists, but needs some more work.

Needs:

• should be an HTML button element
• should have a primary, secondary and tertiary version
• should have a solid design and outline design version
• should allow for an icon (font-awesome icon)
• should have hover, focus and click design
• should support aria-pressed but should not render the aria-* tag unless required
• should support sizes (small, medium, large)
• should support mobile-first responsive web design (RWD)

Screenshots:

The dummy app in the addon should be used to document and demonstrate the flexibility of the components in this addon, within the different website contexts.

• create a route for each site that we initially intend to support with this addon:
• emberjs.com
• ember-cli.com
• ember-engines.com
• ember-fastboot.com
• scope site-specific styles in the dummy app stylesheet
• add the navbar and footer to the application template
• add the data to the app data folder
• file issues for places where the components didn't separate concerns correctly

The image for Zoey wasn't ready when the es-note component was finished, so this story covers that gap. (+ @wifelette )

Add documentation to dummy app for the completed components.

• should look like the current footer, but should be an Ember component.

• padding should be 1em 22em (for larger viewports)
• h1 should be min-width: 100%
• fix the h2 according to the screenshots
  make sure to scale for smaller (mobile first please)