To give developers targeting older browsers and simple sites a path to using Material Design, we're going to implement an official light-weight version using just JavaScript and CSS.

These will strive to be simple enough that anyone can easily customise them. For evergreen browsers, we recommend just using Polymer directly where possible.

This is a preliminary list we hope to ship:

• Button (spec)
• Radio button
• Input (spec)
• Toolbar
• Card (spec)
• Progress bar
• Slider (spec)
• Icon button
• Fab
• Shadow
• Toggle
• Toolbar
• Menu button (spec)

Who is working on what?

| Element | Author | Prototype | | --- | --- | --- | | Button | @addyosmani | http://codepen.io/addyosmani/pen/Cjlaz | | Input fields | @mattcooper | http://codepen.io/mattcooper/pen/jmIua | | Radio button | @Itrulia | http://jsfiddle.net/itrulia/25pj2/ | | Icon button | Unassigned | | | Checkbox | @jasonmayes | http://codepen.io/jasonmayes/pen/wxtFr | | Shadow & Cards | @addyosmani | http://codepen.io/addyosmani/pen/zimes | | Toggle button | @mattcooper | http://codepen.io/mattcooper/pen/npEyu | | Progress | @marcacohen | | | Slider | @devnook | https://github.com/google/web-starter-kit/pull/334 | | FAB button | @wibblymat | http://codepen.io/wibblymat/pen/mnGsu | | Menu button | @nicolasgarnier | | | Theming | @devnook | In progress | | Toast | @wibblymat | http://codepen.io/wibblymat/pen/avAjq | | Layout (site) | @addyosmani | https://github.com/google/web-starter-kit/issues/295 | | Layout (app) | @addyosmani | unassigned |

Technical details:

• Components need to support all of the browsers listed in our matrix
• Components should be written using CSS and vanilla JS (no jQuery or additional libraries)
• If we're sticking with Sass, must be written with Sass or CSS and we'll tweak as necessary.
• Maintain fidelity with the Polymer paper elements as closely as possible.
• Attempt to style native HTML elements over wrapping where possible (to preserve accessibility)

Web Starter Kit extras

• Material layout
• Bring in the new Roboto
• Style guide > Icons
• Theming support
• Refresh style guide to Material Design

Notes

• All elements will go through a UX review from the Material Design team before getting shipped as part of Web Starter Kit to make sure we're not messing up :)
• The Polymer paper elements are going to be undergoing an accessibility review in the coming months. We'll keep a close eye on this and integrate any learnings that apply to our element set.

Inspiration:

I'll work with Google's MD team to try getting a review process in place for anything we create here.

I'm not a fan of this meta tag, it's only useful in a tiny minority of cases, slows rendering, and fails validation. In IE8+ the presence of a <!doctype switches the rendering engine to standards compliance -- the only time this tag is useful is if the user has decided to switch your site to compatibility mode in IE8, 9 or 10 (not present in 11), or if you're on an Intranet using IE8, 9 or 10.

Additionally, if you feel you need X-UA-Compatible then Microsoft's best standards are to place it in the header, not the HTML.

Given that Google pushes for latest browser compatibility, and only supports the last two versions of each browser, will this tag be removed on the release of Edge?

This PR adds support for Win 8.1 live tiles and streamlines the icons used across all add to home screen platforms. It implements all recommended meta tags across all platforms.

hello all, not sure if it's me missing something or what, but I have cloned the repo and run 'npm install' from the directory with no issues. However, once running 'gulp serve', when I go to change any scss files gulp seems to run the 'styles' job like it should and the page reloads, but none of the styles change. The gulp file seems to update the '.tmp/styles/*' files correctly, but the reload doesn't then use these files.

Simple example, deleting the entire contents of the 'app/styles/components/components.scss' file and saving seems to run all the gulp tasks and reloads the browser, but all styling stays the same.

Any help would be much appreciated, I'm sure it's something I am doing stupidly wrong.

Many thanks in advance. Mat

I am getting rangeerror in events.js when using gulp to build /dist. Any ideas. Thanks

Finished 'jshint' after 1.23 s

events.js:72 throw er; // Unhandled 'error' event ^ RangeError: Maximum call stack size exceeded

It's time to decide whether we want Google WSK to stick with a static style guide or opt for the style guide to be auto-generated.

There are an abundance of tools for the latter, but open questions around how well they're supported, how they work with BEM/SUIT/inuit and what the current recommendations from CSS thought leaders are.

Static

The current style guide is composed of a static HTML file that pulls in styles from a Sass-based directory of components. Our Material Design version is quite similar, but uses iFrames to pull in component demos. There are pros and cons to this approach:

Pros:

• Super simple for beginners to edit/update the file to change components, visual look and feel
• Supports LiveReload, working with a preprocessor / the other nice build process bits you get with WSK

Cons:

• As it has to be manually updated, it may either become a burden to project authors or be deprioritized as it isn't part of the main site
• It's a standalone representation of style and components without a direct link to the codebase.
• The current setup requires additional build step configuration in our Gulpfile, though, this would likely be similar for any alternative approach.

Auto-generation

The auto-generation route is advocated by projects like KSS - used by GitHub for their styleguide sample, StyleDocco and PatternLab. Team Sass has previously looked at using Yeoman generators like this one to aid in the automation process.

Pros:

• Autogenerate Style Guides when changes are made to the codebase so in theory they shouldn't be able to fall behind
• As the Style Guide is generated from source, beginners shouldn't need to manually update the end product - just adhere to the style of template necessary for auto-generation to work.

Cons:

• Gets tricky when you're working with components requiring JavaScript (where does the demo information live? Assume the generated content will be correct and include a script.js in your styleguide template?).
• Duplication of template information (you end up with demo templates in both your source comments and style guide for components that are non-trivial or a mix of multiple components)

Requirements

Here is to the best of my understanding what we may want:

• Automated style guide generation
• Little overhead of learning yet another architecture methodology that will scare off beginners and intermediate devs.
  • E.g if we recommend BEM, SUIT or inuit for the general CSS architecture, we want to avoid (if possible) introducing yet another methodology unless it brings value. For example, I love PatternLab, but have this concern with Atomic Design, but less so KSS. Is KSS as complex? Is there something better?
• Something that works well with components that may optionally require JavaScript.
  • e.g I have a button with a ripple effect powered by JS - the solution has a way for my auto-generated guide to demo it. Is this flawed thinking or does an existing solution support it?
• A solution with up to date tooling.
  • We have no problem writing new Node modules to work with a solution if needed, but ideally the solution should have existing Node tooling around it. We can write the Gulp tasks needed if they aren't done.
  • Solution can't require users to use say, PHP. We're trying to minimize our dependency tree as much as possible.

Open questions

• Do Team Sass have a preferred setup for style guide generation? @jina talked about this at CSSConf
• Is KSS actively maintained? The commit frequently seems to have slowed down in the last 6 months https://github.com/kneath/kss/commits/master
• Does SUIT or inuitcss have a preferred solution for style guide generation that works well with those architectures? (cc @necolas @csswizardry)
• How do existing techniques solutions with newer CSS architectures? e.g let's say I want to use SUIT as part of my architecture. Do I have to make the decision to use the architecture outlined by PatternLab / KSS/ StyleDocco over it. Does it generally not make sense to deviate from recommended structure?

Let's add the automated favicon generation support discussed in #442 :ice_cream:. We'll be using https://github.com/haydenbleasel/favicons to do the trick.

By default, let's use a single image, but also recommend providing three unique ones instead in comments. We can also describe what each asset is used for and optionally add recommendations around treatment.

C:\Users\Hans\web\starter\webstarterkit-1>gulp serve [09:35:45] Using gulpfile ~\web\starter\webstarterkit-1\gulpfile.js [09:35:45] Starting 'styles'... [09:36:01] 'styles' all files 92.75 kB [09:36:01] Finished 'styles' after 15 s [09:36:01] Starting 'serve'... [09:36:02] Finished 'serve' after 916 ms [WSK] Local URL: http://localhost:3000 [WSK] External URL: http://192.168.178.21:3000 [WSK] Serving files from: .tmp [WSK] Serving files from: app events.js:85 throw er; // Unhandled 'error' event ^ Error: spawn cmd ENOENT at exports._errnoException (util.js:746:11) at Process.ChildProcess._handle.onexit (child_process.js:1046:32) at child_process.js:1137:20 at process._tickCallback (node.js:355:11)

C:\Users\Hans\web\starter\webstarterkit-1>node -v v0.12.0

C:\Users\Hans\web\starter\webstarterkit-1>npm -v 2.5.1

We should host a version of the hello world so that people can play with it without downloading it.

Note: we probably can't do this on gh-pages under the google org.

Sushi is targeting a 60fps experience from the get-go, meaning that we have high performance requirements of any CSS library that we opt to suggest.

We also want to make sure that the solution we provide is small, focused and offers sufficient CSS UI components to be useful to developers that want a basic, clean UI for the apps they are building.

Libraries currently under consideration:

• TopCoat
• PureCSS
• Ionic
• Foundation

Note that this is a preliminary review and any benchmarks used are nuanced and should only be used as a rough guide.

Here's a start!

Changed:

• Moved app/styles/sass to app/styles/components
• Joined gulp watch and gulp serve into one task: gulp serve

I haven't thoroughly tested yet, but what I can confirm does work:

• Edit a app/styles/*.css file, page reloads
• Edit a app/styles/components/.scss file, a matching app/styles/components/.css file is created, and the page reloads

Bumps urijs from 1.18.4 to 1.19.11.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

PS C:\Users\maper\Downloads\AppSalon_inicio> gulp [21:29:58] Using gulpfile ~\Downloads\AppSalon_inicio\gulpfile.js [21:29:58] Starting 'default'... [21:29:58] Starting 'css'... [21:29:58] Starting 'javascript'... [21:29:58] Starting 'imagenes'... [21:29:58] Starting 'versionWebp'... [21:29:58] Starting 'watchArchivos'... [21:30:00] 'imagenes' errored after 1.41 s [21:30:00] Error: write callback called multiple times at DestroyableTransform.afterTransform (C:\Users\maper\Downloads\AppSalon_inicio\node_modules\readable-stream\lib_stream_transform.js:84:31) at EventEmitter. (C:\Users\maper\Downloads\AppSalon_inicio\node_modules\gulp-cache\lib\index.js:451:7) at EventEmitter.emit (node:events:394:28) at EventEmitter.emit (node:domain:470:12) at DestroyableTransform.onError (C:\Users\maper\Downloads\AppSalon_inicio\node_modules\gulp-cache\lib\index.js:288:15) at Object.onceWrapper (node:events:514:26) at DestroyableTransform.emit (node:events:394:28) at DestroyableTransform.emit (node:domain:470:12) at C:\Users\maper\Downloads\AppSalon_inicio\node_modules\through2-concurrent\through2-concurrent.js:41:14 at C:\Users\maper\Downloads\AppSalon_inicio\node_modules\gulp-imagemin\index.js:102:5 [21:30:00] 'default' errored after 1.42 s

Bumps tar from 2.2.1 to 2.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps is-my-json-valid from 2.15.0 to 2.20.5.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

Originally posted by @googlebot in https://github.com/google/.github/issues/31#issuecomment-619467429