OS: MacOS Sierra & Windows 7
Repo: hs-deals on Master branch

Steps to reproduce: Load a page that uses Thorium and use a <sup> HTML tag with a numeral, such as 1, 2, 3, etc., inside the tag.

The problem cannot be reproduced in our environment, unless you choose to load a commit on the master branch before Tuesday February, 21st, as we have patched the problem temporarily.

If you do load the repo on your local environment, please load this page to view the problem: http://localhost:3000/en/bc/deals/switch-to-4k

GTM's Request:

Please size legals according to designer's standards in REM sizing for H1, H2, H3 P tags, etc.

Hey guys,

Just wanted to raise an issue that we just encountered in regards to compatibility with the commonly used node-sass module.

We were previously running node-sass v4.3.0 in our project, but you'll notice that node-sass has received 2 new releases in the past 8 days, namely v4.4.0 and v4.5.0:
https://github.com/sass/node-sass/releases

Compatibility has broken now w/ node-sass v4.4.0 onwards. Using node-sass >= 4.4.0 results in the following Webpack build error:

Child extract-text-webpack-plugin:
       [0] ./~/css-loader/lib/css-base.js 1.51 kB {0} [built]
        + 1 hidden modules
Child extract-text-webpack-plugin:
       [0] ./~/css-loader!./~/postcss-loader!./~/sass-loader?sourceMap!./src/app/scss/main.scss 363 bytes {0} [built] [failed] [1 error]

    ERROR in ./~/css-loader!./~/postcss-loader!./~/sass-loader?sourceMap!./src/app/scss/main.scss
    Module build failed:
    &:-ms-input-placeholder {
    ^
          Base-level rules cannot contain the parent-selector-referencing character '&'.

    Backtrace:
    	node_modules/telus-thorium-core/scss/elements/_forms.scss:79
          in /Users/paulsaumets/dev/clones/pdp-react/node_modules/telus-thorium-core/scss/elements/_forms.scss (line 79, column 1)

npm ERR! Darwin 16.4.0
npm ERR! argv "/Users/paulsaumets/.nvm/versions/node/v6.9.4/bin/node" "/Users/paulsaumets/.nvm/versions/node/v6.9.4/bin/npm" "run" "build"
npm ERR! node v6.9.4
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! [email protected] build: `npm run clean && NODE_ENV=production webpack -p --progress --colors`
npm ERR! Exit status 2

The backtrace points to a rules violation in telus-thorium-core?

For the time being on our project we have downgraded and are now forcing node-sass v4.3.0.

Currently, in order to be able to showcase updates to either qa or staging we have to do a release, which is preventing us from properly use the qa and staging urls for what they are for.

As a developer working on fixes I need to be able to showcase fixes/new features in qa and staging so the updates can get reviewed by all stakeholders without having to generate a release.

Right now there aren't too many functions/mixins/variables to keep track of, but we do have some, and odds are we'll add more as the need arises. Example: that function I added a while ago for getting a breakpoint's pixel values. We should create a page in the docs that lists these kind of helpers - if new devs see that these kinds of helpers are already present, they're less likely to waste time rewriting them.

Other things that I usually try to 'automate' in css as much as possible include px/em conversion functions, mixins/functions for retrieving icons (especially handy for icon fonts), etc. Any of these should be part of that documentation, if we add them.

(The same goes for utility classes like the accessibly-hidden-text one, although I think those are already mostly documented on the example pages.)

#Description
a badge draws attention to new or important content.

Questions / requirements:

• What is the right name for this component, e.g. badge, label?
• Do we need different sizes?
• Different colour?
• max content length?

Design Acceptance Criteria:

• Updated Sketch file
• Design specifications
• Creative Mockups
• Dev can access Sketch file -> Zepelin/Repo
• Design validated by dev
• 1st draft of design documentation is created
• Final sign-off by TDS team

Prototypes:
Avatar - http://xr4j5o.axshare.com/home.html
Icon - http://ij9qpp.axshare.com/home.html

Requirements

• ?

The examples on the icons page of using an .accessible-hide class for text values are great - one change I would suggest, for the other examples, is to include (and document) the aria-hidden="true" attribute on icons which don't have some kind of text equivalent. Otherwise, screenreaders treat them as content, but don't actually read them out as anything (ie, you can move the VoiceOver cursor to an icon, but it won't be announced). This is a small issue, but seems like it could be frustrating or confusing for AT users, especially if they're on a page that uses a lot of icons this way.

<i class="icon icon-core-plus"><span class="accessible-hide">More Options</span></i> with text
<i class="icon icon-core-caret-down" aria-hidden="true"></i> without

It's a little counterintuitive that .link-chevron doesn't actually put a chevron on a link and that you have to manually add the icon as its own element. What if the chevron was part of that class, as a pseudo-element? (This would also solve - for this case, anyway - the issue that an empty <i> without aria-hidden gets parsed by screenreaders.)

(On a side note - should .link-chevron be set to display: block? Would it ever need to occur inline? I've only seen it used as a block element in designs so far.)

Issue:
Vertical grid - harder to count by 4 - can we go by 8’s or 12’s?

Inspo:

• Google using 8
• Stefan - kept 4 but introduce squares
• Potential to be overwhelming at first but adjust after the fact
• Sonia - finds it to be straining

@gfroome what do we need to do to validate if 4px is the best solution?

Description
GB selectors on the product detail page

Questions

• Text size?
• Diff. sizing for primary and secondary text (price vs. descriptive text)?
• Styling for descriptive text?
• Sizes (small & big)?

States

• Hover
• Selected

Inspiration

• Apple

Design
Creative Mockups: https://telusdigital.slack.com/files/jameschiu/F3X6KP41L/screen_shot_2017-01-25_at_3.46.48_pm.png Please add more designs @damian

Spinners are CSS loading indicators that should be shown when retrieving data or performing slow computations. In some cases, the first time a parent component loads, a stencil is preferred to indicate network activity.

Questions:

• Do we need different colors?
• Do we need different sizes?

Inspiration:

• https://www.lightningdesignsystem.com/components/spinners/

Thorium currently has no way to reset offset, push or pull in the grid system. This could be accomplished using push/pull/offset-size-0 and setting left or right property to "auto" (e.g offset-medium-0). Bootstrap 4 does it this way (only offset is documented) see: https://v4-alpha.getbootstrap.com/layout/grid/#column-resets

I can open a PR if needed

Description
Received some valuable feedback from some of our users about the documentation on the TDS website. Perhaps we need to humanize some of the copy.

Feedback
The Thorium site is rife with jargon. It is rather intimidating and I admit I don’t actually understand a lot of what is written there.

Example

Plan for technical debt to contribute site elements and incorporate feedback from the Design Guild/Thorium System.
— I really don’t know what half of that means!

Questions
Is the copy on the Thorium site going to be lifted verbatim onto the new TDS website?
Do we need to engage a copy writer to humanize?

Right now, Thorium's scss uses /* */ style block comments for its inline documentation. These can be stripped out by a build process/minification, but they're all present while working in a pre-minification environment (ie, while doing dev work - this is an issue I encountered while importing parts of thorium-core for our current project.) What ends up happening is files like _variables.scss and _mixins.scss, when compiled but not minified, come out as just long blocks of comments (which are not particularly useful since the variables are compiled out!)

If we're not locked to the block comment syntax, we can solve this by converting comments to sass-style //, which won't show up once compiled. If there are some comments we do want to preserve even when compiled, those can be left alone, but I'd definitely remove them from files that don't output any actual css. (I'll volunteer for this task, if needed.)

We need some sort of visual regression tool to do some sanity check while developing and generating a new release in order to do a sanity check and confidently communicate with the thorium consumers what to expect on an upcoming release.

As a developer I need a visual regression tool to mitigate risk of releasing breaking changes that could potentially impact the design and aesthetic of multiple telus properties using this library.

Ideally this should be integrated into a our CD pipeline but we can start off by manually running it in our local environment to begin with.

I was thinking of http://bbc-news.github.io/wraith/ but the tester that will join the team might have other suggestions.

We need to bring the frogger icons over to Thorium. The Thorium/React footer is ready, except for the icons that are in the products and services tiles portion of the footer (see screenshot for more information on what icons I am referring to).

Issue #105 discusses the use of SVG icons versus font-icons. I would like to move forward with SVG, as it gives our branding the further potential of using CSS to style the SVG graphics, which you cannot do with font-icons.

Is there a particular date that we could bring over these icons by? Are there any design/architectural objections to this idea?

Thank you kindly.

Our team is looking at pulling in Thorium's css to replace frogger (at the moment just the grid).
Have you considered name-spacing Thorium classes to better protect against potential naming collisions? I'm thinking about something similar to PureCSS. This way we can just pull it in via CDN and get to work :) Happy to submit a PR.

Example using the Thorium's element symbol 'th'.

<div class="th-grid-row">
      <div class="th-small-6">Hello</div>
      <div class="th-small-6">World</div>
</div>

<div class="th-grid-row">
      <div class="th-small-6">Hello</div>
      <div class="th-small-6">World</div>
</div>

Can we change the name of col classes from xs, small, medium, large and xl to be:
xs-col-*
sm-col-*
md-col-*
lg-col-*
xl-col-*
This is more consistant. We can add these as alias to be backward compatiable.

Knowing where exactly the styles on the documentation's examples come from can be helpful. This could be done as simply as adding links back to the relevant source files (ie, having a link to _forms.scss on the Forms page).

Alternately, you could include the related scss directly in the page as a snippet, similar to the html snippets, but I'd recommend only doing this if you set up some kind of automated css documentation. (Which could be another enhancement - not sure how much Thorium is expected to grow, but if it's going to get big, automated docs are worth looking into.)

Make it work like Selector Counters in other media apps too - where you can finger (or mouse) swipe and hold up or down to make the counter continue to increment or decrement.

This one's for the design team, at least initially.

More styled elements! Not urgently needed, but would be nice to include as part of our typography foundations.

For code and pre (and I guess kbd/var/samp if you're feeling thorough), might be enough just to set the font-stack to whatever monospace font the designers feel fits the Telus look the best.

<abbr> is an underappreciated element, but I'd argue it's still worth designing - could see it being really appropriate in a lot of places on a site like Telus. The typical styling paradigm for the <abbr> tag is a dashed or dotted underline (something subtler than a proper link would have) plus cursor: help in the css (meaning you get a ? cursor when you mouseover, clueing you in to hover till the title appears).
<abbr title="Backends for Frontends">BFF</abbr>

blockquote is another one that seems like it's bound to be needed here. Client testimonials or press/writing pieces come to mind. Design could go in any number of directions with that one.

There might be other tags I'm missing, but I'd start with these.

Description:
Footer with links and region selector

Questions:

• Distribution?
• Part of TDS or separate repo?

Mockups:

• https://zpl.io/EUA67

Design Acceptance Criteria:

• Updated Sketch file
• Design specifications
• Creative Mockups
• Dev can access Sketch file -> Zepelin/Repo
• Design validated by dev
• 1st draft of design documentation is created
• Final sign-off by TDS team

Move list item from symbol to style instead

The technique used to replace the Radio Buttons and Checkboxes (using the .accessible-hide class) prevents the browser from highlighting the currently focused element, causing users to loose context when navigating the form using the keyboard. Additionally, HTML5 built-in form validation will fail to display warning messages.

Suggested fix for this issue will be to use an overlapping technique instead, placing the radio/checkboxes directly underneath the graphical pseudo-elements so that the focus outline would be visually correct, see screenshot:

Description:
Header and top nav with search and region selector

Mockups:

• https://zpl.io/1xiCha

Design Acceptance Criteria:

• Updated Sketch file
• Design specifications
• Creative Mockups
• Dev can access Sketch file -> Zepelin/Repo
• Design validated by dev
• 1st draft of design documentation is created
• Final sign-off by TDS team

the body color is set to #f8f8f8. The support team tells me this is why the page telus.com/deals page has been grey in IE

I mentioned this in the demo call the other day, filing an issue just so it can be tracked. Right now the selector counter component looks and partially behaves like an input type="number", but doesn't allow certain native behaviors like manually inputting a number via keyboard or incrementing with the arrow keys. (This especially impacts mobile users.)

The best way to make this fully usable, I think, would be to change the input element in the React template from a span to an input type="number". The native styles can be overridden (including the up/down buttons some browsers display), and the up/down buttons currently in the component can probably stay mostly unchanged (though some event bindings should probably be tweaked once the native ones are available).

When using the grid classes, if the items in a row are uneven in height, it can affect the floating/clearing of other items and throw off the layout. Putting a .grid-row around each row in the layout forces the floats after it to clear, but this doesn't work if you have, say, a 3-column layout on large screens that drops to a 2-column on small ones.

There are a few ways to work around this - in our current project it's solved with careful application of :nth-child to clear, as in .large-4:nth-child(3n+1) { clear: both; } - which is sort of feasible but can get messy as more breakpoints get involved.

Another option seriously worth considering is flexbox - global browser support is around 97% at this point, so it's safe to use, and it was made for these situations.

Here's a demo - note what happens to Sisko's box due to how tall Picard's is. The first row is the behavior described in this issue; the second is what happens if you try to use grid-row to force clearing; and the third is a very rough sketch of how this could be approached with flexbox. (If that ends up being something you guys want to pursue, maybe I can help work on it?)

Gavin has designed TELUS-branded UI messages with various states (neutral, branded, success, error, alert). Designs are in a sketch file but require development.

First off - bravo to Thorium for using browser-default focus styles. Keep doing that!
You can add a nice extra touch if the hover styles for buttons, links, etc, also happen on focus. IE,

.button-primary:hover,
.button-primary:focus {
    background-color: #7841b0;
    color: #fff;
}

(If you find yourself writing a lot of hover styles or just want to make this convention more automatic, you can write a simple mixin to output both pseudoclasses at once. I used this on a past project:

@mixin alt-state() {
   &:hover, &:focus {
     @content;
   }
}

.link {
  // default styles
   @include alt-state() {
      // hover/focus styles
    }
}

There's an svg file linked here that isn't loading. Wrong file path?

Another, unrelated suggestion: add the link to the docs site to the repo's main README. I found it in contributing.md, but people who just want to use the library or see how it works might not think to check there.

On the 'consumption' page, it says you can do npm install telus-thorium-core, but that package either doesn't exist or is private.

Vertical space between modules and elements is often one of the trickier things to nail down (remember our last project together, Tom?) - and one of those details that's often left out of frameworks like this. Just wanted to raise the issue in case the designers aren't already working on this.

The solution might be a class like the exmodule one I'm seeing on the grid examples page of the docs - something that just applies a standardized amount of vertical margins or padding and is treated as an expected container in the markup.

Or, if it fits the design specs, there are more 'programatic' approaches like the "lobotomized owl" (share that link with your designers!). If you want, we can talk about it when we meet to discuss flexbox - I have some strategies from past projects we could look at.

Noticed there is no maximum width set to the grid container. This makes it difficult to build for large screens, such as TVs. In theory we could have a browser width of 4000px, which without a max-width we end up with content that stretches in weird ways and lots of strange gaps and empty space.

Noticed the homepage implementation got around this by using the suzy .grid selector to set a max width. Would be nice to have our own. Thanks

Description:
A table contains a header row at the top that lists column names, followed by rows for data.

Data tables may include:

• Three or more columns of data
• A corresponding visualization
• The ability for users to query and manipulate data

Interaction

• Row hover (Desktop). Display a background in a table row if a user hovers over any part of that row. If there are separate hover states on individual table cells, display both the hover state of the cell and row at the same time. Hover background = ?
• Row selection: When a row is selected, display a background color on the row. Selected row background = ?

Specs

• Vertical spacing
• Header padding
• Column padding
• Etc?

Inspiration

• Table documentation: https://material.io/guidelines/components/data-tables.html#data-tables-interaction
• Table component: http://www.material-ui.com/#/components/table
• http://zurb.com/playground/responsive-tables

Design Acceptance Criteria:

• Updated Sketch file
• Design specifications
• Creative Mockups
• Dev can access Sketch file -> Zepelin/Repo
• Design validated by dev
• 1st draft of design documentation is created
• Final sign-off by TDS team

Not all the colours from the sketch file is on the website

Need to align on text on photos. Two options in play, which do we choose?

Issues and questions

• Would be nice to have some heading size(s) that are in-between H2 and H3.

• Marketing headings are quite long, reduced size of headings to make it fit more correctly

• Look into using mobile font-sizes for the tablet size

  • Proposed solution: Use mobile H2 as desktop H3. Bump down existing desktop H3 to H4

• The line-heights for some of the different types of headings?

carets seem too small - especially for mobile experiences. Right now they are 12 x 7 px... minimum touch target size for mobile is 44px (although debatable for 26 - 44px)

Using SVGs for icons, rather than font files, is the new hotness as far as front-end best practices go.
There are a number of tools we could use to automate switching over, and to make maintaining the icon set easy - I can share lots of resources.

Here's some background reading:

https://css-tricks.com/icon-fonts-vs-svg/
http://ianfeather.co.uk/ten-reasons-we-switched-from-an-icon-font-to-svg/

I noticed developers and designers who are using the button from thorium override the size of the button all the time. Can we create a smaller version of the button?

Description
Call attention to a special feature, price point, etc.

Design Acceptance Criteria:

• Updated Sketch file
• Design specifications
• Creative Mockups
• Dev can access Sketch file -> Zepelin/Repo
• Design validated by dev
• 1st draft of design documentation is created
• Final sign-off by TDS team

Questions

• Are there too many types?
• Is it clear when to use a specific button style?
• Do we need to change the hover state?
• Is the text too small?
• Is the button too tall?

Sometimes you just need the pixel numbers for the breakpoints, outside of their media-query mixins. This takes a few steps in sass, which can be condensed into a helper function; I'll open a PR shortly with my solution.

Description
Pills are used for filtering

Proposed Design
Creative Mockups: ______________ @tds

Functionality

Steps to reproduce:

1. Mark up a link with .link.link--descent
2. Use your cursor to highlight the link text
3. Notice there is a white halo visible around the lettering

The halo is what makes the underline appear to not intersect with descenders. Change the halo color to the same hex code as the browser's "selection" color to hide it in this scenario.

I've been going over our sketch files with Gary Chow... found a couple of issues that need to be addressed :)

X-small: Artboard 320

• There is no grid? But we do in fact have a grid for XS - why is this not present?

Small: Artboard 576

• grid is 576px - fine but why this width and not 545?

Medium: Artboard 768

• need to change artboard to 769
• grid is 720px - is there a reason for this width and not 769?

Large: Artboard 992

• grid is 940px - this is incorrect should be 992+?

X-Large: Artboard 1200

• need to change artboard to 1201
• grid is 1140 - this is incorrect should be 1201+

Correct value is:

Athens Gray

F7F7F8

247, 247, 248

• Also, can we add the RGB values similar to:
  https://app.frontify.com/d/8aeCvDkmolHZ/v2#/foundations/colour

In a coming sprint, the migration team will build features such as BCM-168. We'll use the Collapsible component from TDS.

I see minor differences in design (Invision comp):

• TDS icons are gray. Invision comp's icons are green.
• TDS title text is bold. Invision comp's icons are normal weight.

@gfroome @mrkrumhausen should we...

• Use the TDS design as-is (gray icons, bold weight)?
• Submit a PR to update the icons to green and title font weight to normal?

@xingbo828 are there projects currently using the component which have a specific need for the gray icons/bold weight? If so can they consume the update I'm proposing?

cc @bojanabokan