🎉🎉🎉 This PR proposes merging Water.css 2.0.0 into master!

@kylejrp you said there were some comments you wanted to make, what are they?

Also, this introduces a lot of changes - how can we best summarize them for the changeset?

This closes #187.

EDIT: Here's the current checklist:

• [x] Update the old jsdelivr url to the new one everywhere
• [x] Remake the file structure and docs #191
• [x] Add redirects from the github pages site #158
• [x] Update the demo site url to watercss.kognise.dev everywhere
• [x] Add the bookmarklet #20
• [x] Create a changeset and merge into master
• [ ] Publish 2.0

As far as I can see, here's the current state of Water.css 2.0:

• There are several conflicting pull requests relating to the documentation site, and it's likely that merging the wrong ones will completely break the site.
• The css file that the site references is out of sync with the one that's currently in the readme, and the readme references some features that aren't yet in the site.
• We're currently included the built css files in the repository and managing versions with git tags, but this makes contributing more complex and pull requests significantly harder to merge.
• The plan is to use npm for version management in the future, but then existing sites won't receive updates unless we also continue pushing git tags.
• The development workflow, currently based on gulp, isn't ideal and has a few issues.
• We're currently using netlify to deploy the documentation site but there have been some concerns raised about their new policies.

I'd love feedback on what we should do about these things but here's what I've been thinking:

I think we should stop including the dist folder within the repository and instead rely on a continuous integration platform, potentially github actions, to build the code and deploy it to both a git tag and npm. This will make contributing easier and ensure that existing sites get updates.

I'm not entirely sure about this, but we might want to consider completely remaking the documentation site and build pipeline with something slightly less janky. We could also consider deploying the site to a different service, maybe vercel? This will give the added benefit of being able to gracefully switch over to the new documentation.

Furthermore, a lot of the issues are simply caused by multiple pull requests that have overlap and merge conflicts - I propose instead we create one monster pr that when merged will update everything.

Sorry for the huge block of text, please tell me if I was unclear in any way!

cc @kylejrp @kimulaco @jonaskuske @JackFly26

By darkening the background color by 40% we can get a nice background color for selections.

I propose adding something like this:

::selection {
  background-color: darken($background-color, 40%);
}

This PR changes the file structure to water.css, dark.css, and light.css. It also introduces a full rewrite of the version picker on the documentation site.

Todo:

• [x] Add fancy animations, @jonaskuske :)
• [x] Wire up the copy to clipboard button
• [x] Update the readme with the new files

Are there any other changes in scope of this pull request?

https://developer.apple.com/documentation/safari_release_notes/safari_12_1_release_notes

Be good if you can support Safari media queries so that if a user wants a dark scheme, they would get one. And if a user doesn't, they would get a light theme instead?

Both the ::selection color and --text-muted are a sort-of similar shade of gray, so selecting text that's muted, e.g. a <footer> / <cite> means the text becomes very hard to read.

We should pick a specific level of accessibility and make sure all of our components meet that level of accessibility.

Steps:

• Choose between AA and AAA accessibility
• Add an accessibility checker to our gulp build tools and/or pull requests
• Make sure each CSS component complies with our accessibility checks
• Make sure the demo page complies with our accessibility checks before merging
• Add accessibility to the project goals

I can take care of the build tools, but I think I'm looking for @kognise and the community's opinion on what level of accessibility we should be complying with.

I replaced the previous development server with a souped-up gulp build pipeline. Now you're playing with power! 😎

Gulp

Gulp replaces the previous compiling of the sass files and also handles the development tools. Gulp has lots of other extensions for things like html templating and minification that the demo page could take advantage of in the future.

Sourcemaps

Devtools will now show you the original sass file the rule came from instead of just the full .css file:

It will even show you the original Sass file in devtools:

Note: this makes the dark.css/light.css look really big in devtools, but that's because it's also downloading the sourcemap file. The actual .css file is still small when using in production.

Autoprefixing

You can forget about browser prefixes now - autoprefixer will handle them! I've put a recommended set of supported browsers in the package.json. You can see the coverage here. Feel free to modify! https://browserl.ist/?q=last+1+version%2C+not+dead%2C+%3E+0.2%25

CSS Minification

postcss/cssnano are handling css minification. I'm using their "safe" defaults, but they could be tuned even further to provide some even better minification.

Browser Sync

This does the live reloading / development environment that you had previously set up with dev.js. However, there's no more server code for you to maintain! This should automatically stream changes to your browser when you have it open. It automatically launches and watches index.html and the sass files when running yarn dev.

It might be nice to have water.css published to npm with every release. Then, users can install it using npm install water.css and include it in their projects without referencing a CDN.

This would mean we would have to update the package.json version semantically with every release as well.

Objetives:

• Making the blockquotes element similar to the other UI elements using border radius 6px and background.
• Making the _variables file for using elements like spacing, radius and borders to make a consistant UI when using those elements.

Improved the styling of the form section of the website both in desktop and mobile view.

Desktop View

| Before: | After: | :-------------------------:|:-------------------------: | | |

Mobile View

| Before: | After: | :-------------------------:|:-------------------------: | | |

Description

This uses a drop-shadow filter and clip path to create a round focus indicator on radio inputs. Issue #278

Method

• A box-shadow can only apply square shadows to an element, resulting in a mismatched focus indicator. Screenshot of the original focus state:

• Instead of box-shadow, I used a drop-shadow filter. Drop-shadow filter does not yet support the spread variable that box-shadow has, so we cannot create the unblurred solid 2px shadow that box-shadow allows. Instead, I used 4 layered shadow filters which cover a wide enough area to build the focus indicator. Screenshot of the four layered shadow filters:

• The shadow is then limited to closely match the original 2 pixel solid box shadow spread by creating a circular clip path which slightly overshoots the edge of the component to allow approximately 2 pixels of shadow to show through:

How and where has this been tested?

• Chrome 106 for macOS
• Firefox 106 for macOS
• Safari 16 for macOS

Screenshots

Browser Compatibility

Although this is compatible with Safari, it is worth noting that an existing issue with the display of radio inputs in Safari results in cropping of the input. This was a pre-existing issue due to the width, height, and font size on the input. I recommend that this be resolved in a separate issue.

Safari screenshot:

Please let me know if any changes are needed and I would be glad to take care of it.