Skip to content

Commit

Permalink
feat: move to individually versioned packages with Lerna (#265)
Browse files Browse the repository at this point in the history
Update Textarea line-height and min-height, closes #231
Fix spinner buttons appearing on Steppers in Firefox, closes #214
Fix search field on iOS, closes #229
Fix Menu chevron vertical alignment, fixes #240
Fix horizontal alignment of labels in anchor buttons, fixes #239
Remove button outline when focused in Firefox, fixes #161
Fix bar loader label in IE 11, fixes #242
Fix Radio label margins when labels are below, fixes #246
Fix Checkbox icon color when checkbox imported before icons, fixes #219 (#235)
Add Adobe Clean UX support, closes #189 (#248)
Fix fallback fonts for ar, he, ja, zh-Hans, zh-Hant, and ko, closes #232 (#248)
Removed float from tags, fixes #218 (#237)
Make Slider grab handle look right in docs, closes #255
Add missing Asset docs, closes #256
Add Menu .is-highlighted so we can indicate highlight without mis-using .is-open, closes #258
Support using links as menu items, closes #257
Fix incorrect height for small BarLoader, fixes #259
  • Loading branch information
lazd authored and jianliao committed Sep 19, 2019
1 parent 1865fb1 commit cb7fd4b
Show file tree
Hide file tree
Showing 1,012 changed files with 74,742 additions and 48,323 deletions.
64 changes: 20 additions & 44 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,31 +4,31 @@ We love pull requests from everyone.

The following are a set of guidelines to follow when contributing to this project.

## Code Of Conduct
## Code of conduct

This project adheres to the Adobe [code of conduct](CODE_OF_CONDUCT.md). By participating,
you are expected to uphold this code. Please report unacceptable behavior to
[Grp-opensourceoffice@adobe.com](mailto:Grp-opensourceoffice@adobe.com).

## Have A Question?
## Have a question?

Start by filing an issue. The existing committers on this project work to reach
consensus around project direction and issue solutions within issue threads
(when appropriate).

### Security Issues
### Security issues

Security issues shouldn't be reported on this issue tracker. Instead, [file an issue to our security experts](https://helpx.adobe.com/security/alertus.html).

## Contributor License Agreement
## Contributor license agreement

All third-party contributions to this project must be accompanied by a signed contributor
license agreement. This gives Adobe permission to redistribute your contributions
as part of the project. [Sign our CLA](http://opensource.adobe.com/cla.html). You
only need to submit an Adobe CLA one time, so if you have submitted one previously,
you are good to go!

## Code Reviews
## Submitting a contribution

All submissions should come in the form of pull requests and need to be reviewed
by project committers.
Expand All @@ -47,16 +47,22 @@ git push -u origin my-awesome-new-feature
git remote add upstream git@github.com:adobe/spectrum-css.git
```

Install dependencies:
Install [yarn](https://yarnpkg.com/en/docs/install):

```
npm install
brew install yarn || curl -o- -L https://yarnpkg.com/install.sh | bash
```

Make sure the [gulp-cli](https://github.com/gulpjs/gulp-cli) is installed globally:

```
npm install -g gulp-cli
yarn global add gulp-cli
```

Install dependencies:

```
yarn install
```

Build the project, open a livereloading browser window, and watch for changes:
Expand All @@ -65,41 +71,11 @@ Build the project, open a livereloading browser window, and watch for changes:
gulp dev
```

Commit changes, referencing the relevant issue number (if any):

```
git commit -m "Cool stuff, closes #250, fixes #252"
```

Consider starting the commit message with an applicable emoji:

* :art: `:art:` when improving the format/structure of the code
* :zap: `:zap:` when improving performance
* :non-potable_water: `:non-potable_water:` when plugging memory leaks
* :memo: `:memo:` when writing docs
* :ambulance: `:ambulance:` a critical hotfix.
* :sparkles: `:sparkles:` when introducing new features
* :bookmark: `:bookmark:` when releasing / version tags
* :rocket: `:rocket:` when deploying stuff
* :penguin: `:penguin:` when fixing something on Android
* :apple: `:apple:` when fixing something on iOS
* :checkered_flag: `:checkered_flag:` when fixing something on Windows
* :bug: `:bug:` when fixing a bug
* :fire: `:fire:` when removing code or files
* :green_heart: `:green_heart:` when fixing the CI build
* :white_check_mark: `:white_check_mark:` when adding tests
* :lock: `:lock:` when dealing with security
* :arrow_up: `:arrow_up:` when upgrading dependencies
* :arrow_down: `:arrow_down:` when downgrading dependencies
* :shirt: `:shirt:` when removing linter warnings
* :hammer: `:hammer:` when doing heavy refactoring
* :heavy_minus_sign: `:heavy_minus_sign:` when removing a dependency.
* :heavy_plus_sign: `:heavy_plus_sign:` when adding a dependency.
* :wrench: `:wrench:` when changing configuration files.
* :globe_with_meridians: `:globe_with_meridians:` when dealing with internationalization and localization.
* :pencil2: `:pencil2:` when fixing typos.
* :hankey: `:hankey:` when writing bad code that needs to be improved.
* :package: `:package:` when updating compiled files or packages.
Commit changes with a [conventional commit message](https://www.conventionalcommits.org), making sure to correctly use `feat:`, `fix:`, and `BREAKING CHANGE` accordingly, and referencing the relevant issue number (if any):

```
git commit -m "fix: calendar rendering issue in Safari, fixes #252"
```

Make sure your branch is up to date with the original repo:

Expand All @@ -120,6 +96,6 @@ At this point you're waiting on us. We do our best to keep on top of all the pul

Some things that will increase the chance that your pull request is accepted:

- Write a [good commit message](http://chris.beams.io/posts/git-commit/).
- Write a good pull request description, include screenshots, and test your changes across all evergreen browsers (and IE 11, sadly)
- Make sure the PR merges cleanly with the latest master.
- Describe your feature/bugfix and why it's needed/important in the pull request description.
44 changes: 19 additions & 25 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -1,33 +1,27 @@
<!--- Provide a general summary of your changes in the Title above -->
<!-- Summarize your changes in the Title field -->

## Description
<!--- Describe your changes in detail -->
<!--
Note: Before sending a pull request, make sure there's an issue for what you're changing
- Search for issues: https://github.com/adobe/spectrum-css/issues
- If there's no issue, file it: https://github.com/adobe/spectrum-css/issues/new/choose
-->
<!-- Describe what you changed and link to the relevant issue(s) (e.g., #000) -->

## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- Please link to the issue here: -->

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
## How and where has this been tested?

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
- How this was tested: <!-- Using steps in issue #000 -->
- Browser(s) and OS(s) this was tested with: <!-- Chrome 75.0.3770.142 on Win 10 -->

## Screenshots (if appropriate):
## Screenshots
<!-- If applicable, add screenshots to show what you changed -->

## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have read the **CONTRIBUTING** document.
## To-do list
<!-- Put an "x" to indicate you've done each of the following -->
- [ ] If my change impacts other components, I have tested to make sure they don't break.
- [ ] If my change impacts documentation, I have updated the documentation accordingly.
- [ ] I have read the [CONTRIBUTING document](/.github/CONTRIBUTING.md).
<!-- If this pull request isn't ready, add any remaning tasks here -->
- [ ] This pull request is ready to merge.
11 changes: 7 additions & 4 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
/dist
/node_modules
/temp
dist
node_modules
temp
.npmrc*
.tmp
npm-debug.log*
Expand All @@ -9,4 +9,7 @@ npm-debug.log*
/backstop_data/bitmaps_test/
/backstop_data/build_data/
/backstop_data/html_report/
/.idea
/backstop_data/json_report/
/backstop_data/ci_report/
.idea
lerna-debug.log
4 changes: 4 additions & 0 deletions .npmignore
Original file line number Diff line number Diff line change
Expand Up @@ -9,3 +9,7 @@
/gulpfile.js
npm-debug.log
/.github
/dist/docs/
/components
/tools
/bundles
1 change: 1 addition & 0 deletions .nvmrc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
12.*
6 changes: 0 additions & 6 deletions .topdocrc

This file was deleted.

15 changes: 12 additions & 3 deletions .travis.yml
Original file line number Diff line number Diff line change
@@ -1,10 +1,19 @@
language: node_js
node_js:
- "lts/*"
- "node"
services:
- docker
before_install:
- npm install -g yarn
install:
- yarn
before_script:
- npm install -g gulp-cli
- yarn global add gulp-cli
script:
# This script should be the first that runs to reduce the risk of
# executing a script from a compromised NPM package.
- audit-ci --moderate
- gulp travis-build
- gulp build
- gulp dev &
- sleep 5
- yarn run backstop:ci:test themes=light scales=medium
1 change: 1 addition & 0 deletions .yarnrc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
ignore-optional true
126 changes: 126 additions & 0 deletions README-legacy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,126 @@
# Spectrum CSS legacy usage

In order to enable graceful change to individual components, and to let you consume only the changes you want to consume on the timeline you want to consume it, Spectrum CSS has moved to individually versioned components. In addition, we've moved to a CSS custom properties approach as our default usage method.

Though these were necessary moves, we didn't want to leave existing users stranded while making them. As such, we still support the following legacy usage and distribution methods detailed below.

## Bundle packages

Bundle packages with all of the Spectrum CSS components are available for existing consumers that aren't yet ready to move to individually versioned components. All of the same files included in the individually versioned releases are present, albeit within `dist/components/`.

**Avoid the bundle packages if you're starting fresh with Spectrum CSS, and instead [install only the components you need](README.md#using-spectrum-css).**

### Backwards-compatible bundle

This package WILL NOT get updates to components that have had breaking changes, so it should be used only as a stand-in until your team has time to move to individually versioned components.

To install the backwards-compatible bundle:

```
npm install @adobe/spectrum-css
```

### Latest bundle

To install the bundle with the latest components:

```
npm install @spectrum-css/spectrum-css
```

## Legacy usage

The following are legacy methods for using Spectrum CSS. The [CSS custom properties method](README.md#using-spectrum-css) is preferred.

Spectrum CSS also builds 'multi-stop' and 'single-stop' versions of the CSS for older browsers (IE 11). This enables a consumer to either allow for multiple Spectrum colorstops in a single CSS file, or can limit the number of selectors to only those needed for a single colorstop.

**Do not use these methods if you are starting fresh with Spectrum CSS and do not need to support IE 11.**

### Multi-stop Strategy

The first method of applying colorstops, *multistop*, makes it possible to have any number of colorstops on the same page. This method results in slightly larger CSS files with more selectors, but is the method most products will use as dark and light colorstops are commonly mixed in Spectrum designs.

1. To get all Spectrum components, include `dist/spectrum-core.css` then `dist/spectrum-COLORSTOP.css` for each colorstop you need (where `COLORSTOP` is light, dark, etc).

2. To get only the CSS for components and colorstops you need, include the following to start:

* `node_modules/@spectrum-css/page/dist/index.css`
* `node_modules/@spectrum-css/page/dist/multiStops/COLORSTOP.css` for each colorstop
* `node_modules/@spectrum-css/typography/dist/index.css`
* `node_modules/@spectrum-css/typography/dist/multiStops/COLORSTOP.css` for each colorstop

Then, for each component you need:

* `node_modules/@spectrum-css/COMPONENT/dist/index.css` for each component
* `node_modules/@spectrum-css/COMPONENT/dist/multiStops/COLORSTOP.css` for each colorstop

Set `<body class="spectrum spectrum--light">` to skin the page with light colors, and add `<div class="spectrum--dark">` wherever you need dark styles, or any combination of the above.

Note that, due to CSS selector specificity, whatever colorstop you import last will win if you nest colorstops 3 levels deep. That is, if you first import the `light` colorstop, the the `dark` colorstop, and you have the following HTML, the 3rd button ends up dark.

```html
<body class="spectrum spectrum--light">
<button class="spectrum-Button">I'm light!</button>

<div class="spectrum--dark">
<button class="spectrum-Button">I'm dark!</button>

<div class="spectrum--light">
<button class="spectrum-Button">I'm still dark!</button>
</div>
</div>
</body>
```

### Single-stop Strategy

The second method of applying colorstops, *singlestops*, makes it so it's only possible to have a single colorstop on the page at once. This method results in less selectors and smaller CSS files.

1. To get all Spectrum components for a specific colorstop, include only `dist/standalone/spectrum-COLORSTOP.css`.

2. To get only the CSS for components you need and a single colorstop, include the following to start:

* `node_modules/@spectrum-css/page/dist/index.css`
* `node_modules/@spectrum-css/page/dist/colorStops/COLORSTOP.css` for the single colorstop
* `node_modules/@spectrum-css/typography/dist/index.css`
* `node_modules/@spectrum-css/typography/dist/colorStops/COLORSTOP.css` for the single colorstop

Then, for each component you need:

* `node_modules/@spectrum-css/COMPONENT/dist/index.css` for each component
* `node_modules/@spectrum-css/COMPONENT/dist/colorStops/COLORSTOP.css` for the single colorstop

As there is CSS for only one color stop present, simply set `<body class="spectrum">`. If mixing with individual components using the *multistop* strategy, you can add `class="spectrum--dark"` on `<body>` or anywhere else, but it only affects components whose colorstops were imported using the individual component multistop strategy.

### Import Order and Components

With Spectrum CSS, dependency management between components is the responsibility of the consumer, you. The framework you're building likely has dependencies itself, such as `dropdown` depends on `button`, and each of the components includes its CSS. If this is the case, you'll get the CSS in the right order automatically, since `dropdown` is going to depend on `button`, and `button` will import the necessary CSS.

However, if you're doing a more manual inclusion of CSS files, the easiest thing to do is to use the fully built `dist/spectrum-core.css` + `dist/spectrum-light.css` or `dist/standalone/spectrum-light.css` files described above. If you need only specific components, be sure to follow the order in `src/components.css` so components can override styles of their dependencies.

### Import Order and Colorstops

If your pages are light by default, with some dark elements embedded within (shell, etc), you should import the light colorstop first, adding `.spectrum--light` to an outer container (affecting the whole page), and adding `.spectrum--dark` to an inner container when you need dark elements (affecting only elements inside of it). That is, the import order of colorstops should match the nesting on your page.

### Scale support

Spectrum CSS supports two scale sizes:

* Medium - Desktop
* Large - Mobile

#### Medium only

By default, when you import `index.css` for each component or `spectrum-core.css`, you'll get the Medium scale.

#### Large only

If your site is always mobile, you can get large by default by importing `index-lg.css` for individual components, or `spectrum-core-lg.css` for all components.

#### Medium and Large

If you need to display both Medium and Large, you can import `index.css` and `index-diff.css` for individual components, or `spectrum-core.css` and `spectrum-core-diff.css` for all components.

You can then switch scales by adding the `.spectrum--large` or `.spectrum--medium` class on the `<html>` element.

Note that the Spectrum CSS UI icons must change as well, see below for a full example.
Loading

0 comments on commit cb7fd4b

Please sign in to comment.