The development server doesn't live reload on changes and doesn't automatically build on CSS changes.

The dist folder should be removed in favor of publishing these build artifacts through npm. We would want to remove these files, add dist to .gitignore and create a new .npmignore that excludes the same files as .gitignore except for the dist folder.

This will make pull requests easier to review and prevent contributors from having to build beforehand.

This is probably a breaking change and should be done with the release of 2.0.0.

Here is the code:

<input class="hidden">

.hidden {
  display: none;
}

with the above code the input display will get computed as block cuz this rule have more specificity than single class name.

• Discord server would maybe be nice for questions etc.

Hey there, I noticed in your demo page the checkbox focus state is skewed. Just a heads up :)

I'm on Chrome Canary Version 75.0.3764.0 (Official Build) canary (64-bit)

@kognise @kylejrp @jonaskuske
I think using CSS variables is a great idea!!(#70)
However, I found a problem on the demo page, though.

By use "prefers-color-scheme", it does not switch with "switch theme" on the demo page.
This is because the device's theme setting is prioritized.

So, in order to preview both "switch theme" and "prefers-color-scheme" on the demo page, I think it is necessary to take measures such as creating a dedicated demo page.(Page for loading "* .standalone.css".)

I am sorry if it has already been discussed somewhere or the correspondence is in progress.

So, turning this into a separate issue instead of just a comment in #25:

I'd like to see a "modern" version of water.css, using actual CSS variables (aka Custom Properties) for theming. They're supported in all modern browsers for a little more than two years now, here's the full browser support sheet.

This would allow us to ship builds including both the light and the dark theme (without having to load two separate files) for devs who want to add both themes to their site, to make theming depend on users' system-wide theme preference. (see #25)

We could still transpile the variables to static CSS where appropriate so we wouldn't lose any browser support, just add additional smaller builds for those who don't have to support IE any longer.

This would give us the following builds:
(you can also explore the options here: https://codepen.io/21stCenturyJonas/full/JqjPgL)

light.standalone.css

Includes light variables and core, compiled to "normal" static CSS – same as current light.css:

@import 'parts/_variables-light.scss';
@import 'parts/_core.scss';

dark.standalone.css

Includes dark variables and core, compiled to "normal" static CSS – same as current dark.css:

@import 'parts/_variables-dark.scss';
@import 'parts/_core.scss';

dark.css

Includes both dark and light variables, left as CSS custom properties so they can be changed dynamically. Dark is the default, light variables are only applied if (prefers-color-scheme: light) matches.

@import 'parts/_variables-dark.scss';
@media (prefers-color-scheme: light) {
  @import 'parts/_variables-light.scss';
}
@import 'parts/_core.scss';

light.css

Includes both light and dark variables, left as CSS custom properties so they can be changed dynamically. Light is the default, dark variables are only applied if (prefers-color-scheme: dark) matches.

@import 'parts/_variables-light.scss';
@media (prefers-color-scheme: dark) {
  @import 'parts/_variables-dark.scss';
}
@import 'parts/_core.scss';

dark-legacy.css

URL-imports (→ at runtime in the browser) the compiled, static dark theme and, in case (prefers-color-scheme: light) matches, the compiled, static light theme, too. Requires multiple network requests and a larger download size overall but enables user-preference dependent theming in legacy browsers.

@import url('dark.standalone.css');
@import url('light.standalone.css') (prefers-color-scheme: light);

light-legacy.css

URL-imports (→ at runtime in the browser) the compiled, static light theme and, in case (prefers-color-scheme: dark) matches, the compiled, static dark theme, too. Requires multiple network requests and a larger download size overall but enables user-preference dependent theming in legacy browsers.

@import url('light.standalone.css');
@import url('dark.standalone.css') (prefers-color-scheme: dark);

Happy to work on this once mission is a go 😀

been waiting for new version for weeks now.
considering the popularity of the project I hoped for things to move a bit faster here.

I haven't nailed down the source of this problem, but the "Switch Theme" button on the demo page has been broken on IE11 for a while.

This change was not introduced by #85. However, #85 may have added more compatibility issues on top of it.

We could try tracing down the original source of the problem, or we could just update the build tools to automatically support IE11 and other browsers.

It's pretty hypocritical saying:

Water.css is a css framework that doesn't require any classes. You just include it in your and forget about it, while it silently makes everything nicer.

But then for using the light theme I need to add a .light.

I think for clarity, size and ease of use it would be wise to split light and dark theme to their own files. When I want a light theme, why do I have to load all of the dark theme stylings? That's wasteful.

Splitting in respective files lends itself to creating more themes, for example a more red one, a blue one, a green one, grey, orange, etc.

I'm considering switching to Netlify for our website. Here are some benefits of doing this:

• Faster deployments of updates to the demo site
• Ultra fast loading (does this matter that much?)
• And, the most important thing at least to me: deployments of the demo for every pull request

This way anyone can view someone's new styles without downloading or installing anything. The main con of switching is that Netlify is a separate addon and might complicate things for a project in an early-ish stage.

I'd love to hear the community's feedback on this - what are your thoughts?

HTML supports built-in progress bars:

<meter value="4" min="0" max="5">Section 4 of 5</meter><br>
<progress value="69" max="420"></progress>
<meter value="0.69">69%</meter>

Support for this stuff too would be cool :)

Radio buttons don't appear correctly and seem unselectable:

Due to these lines:

Hi!

I really like the idea of a simple, plug-to-play theme, so I created a simple piece of JavaScript that removes all style sheets and replaces them with water.css (light by default), to be used as a bookmarklet on sites with terrible, unreadable style sheets. It also makes sure that the viewport is setup properly for mobile devices.

Here's the code for the bookmarklet that you can copy:

javascript:document.querySelectorAll('link[rel="stylesheet"]').forEach(e=>e.parentElement.removeChild(e));var x=document.createElement("link");if(x.rel="stylesheet",x.href="https://cdn.jsdelivr.net/gh/kognise/water.css@latest/dist/light.css",document.head.appendChild(x),0==document.querySelectorAll('meta[name="viewport"]').length){var y=document.createElement("meta");y.name="viewport",y.content="width=device-width, initial-scale=1.0",document.head.appendChild(y)}

Here's the formatted code:

document.querySelectorAll('link[rel="stylesheet"]').forEach(x => x.parentElement.removeChild(x));
var x = document.createElement('link');
x.rel = 'stylesheet';
x.href = 'https://cdn.jsdelivr.net/gh/kognise/water.css@latest/dist/light.css';
document.head.appendChild(x);
if (document.querySelectorAll('meta[name="viewport"]').length == 0) {
    var y = document.createElement('meta');
    y.name = 'viewport';
    y.content = 'width=device-width, initial-scale=1.0';
    document.head.appendChild(y);
}

<details>
<summary>Sample Text</summary>
<p>Read this sample text.</p>
</details>

This is some neat HTML code which allows for collapsible/toggle-able content, but it'd be neat if the content within <p>...</p> was in a dotted border or something to make it easily distinguishable from the previously already displayed stuff.

We need styles for inline code, inline keyboard shortcuts, and code blocks. This includes the following tags:

• <code>
• <kbd>
• <pre>

Possibly also the following:

• <samp>
• <output>

Any help would be appreciated!

@jonaskuske had a great suggestion in #71 to move all the docs files to their own folder. I think this will help clean up the project directory.

However, this change will break the Netlify configuration, as it's looking for index.html and not docs\index.html. @kognise will have to update the Netlify configuration as we make this change.

let's say we have this:

<a href="#" data-toggle="tooltip" title="Hooray!">Hover over me</a>

would be nice to implement something as this:

https://kazzkiq.github.io/balloon.css/

or something similar on your end

Because the layout is centered - a scroll bar coming in and out causes a slight shift. This is mostly visible in single page apps where the header should be static but it clicks to the side when moving between long and short pages.

min-height: 101% causes the scroll bar to always show up which is what this kind of layout needs.

Hey @kognise! I just wanted to open up a friendly discussion on the filesize goal. I think it's holding water.css from being the best it can be.

One of the water.css goals is:

• Small size (< 2kb)

However, it's come up that adding some new features would increase the file size:
#32 (comment)
#22 (comment)
#14 (comment)
#19 (comment)

I think this conflicts with some of the other goals:

• Good code quality

Having a file size constraint encourages writing less-legible but smaller sized CSS rules.

• Good browser support

Autoprefixing is taking up some of the file size.

• Beautiful

A small file size is preventing new features from being added.

Proposition:

• Remove the specific file size from the goal, but still keep the goal about a small file size.
• Advertise the gzip'd file size from the CDN somewhere on the demo page. (It looks like jsdeliver serves dark.css in 856 B, which is much smaller than the 2 KB! Maybe gulp could calculate this at build time? Or javascript could calculate the real response size on the demo page?)

This would allow water.css to encourage readable code, add support for any browser, and add any kind of features. I think keeping a small file size as a goal will still discourage adding things like background images to the .css file and bloating it.

Add multiple to the select tag in the demo page to see. Perhaps it would be helpful to have a multiple select element in the demo page also.

I love everything about this framework except for the fact that it forces max-width on my body.
I am proud to wear my body fat.

The switch theme button on the demo page doesn't work in IE11. I'm not seeing any bugs in the console, but this is definitely coming from the code in script.js.

It looks like it could just be the arrow function used on the first line.

Caniuse mentions that it isn't supported in IE11:
https://caniuse.com/#feat=arrow-functions

To close this issue, we'd want to rewrite this function to be compatible with IE11 and test that the "switch theme" button works in IE11.

1. <kbd and <code> should not have the same visual styles
2. Support for <samp>
3. Support for <mark>
4. Support for <var>
5. Support for <time>
6. Support for <small>
7. Support for <data> (?? -- rarely used -- not in w3c spec, but in WHATWG)
8. Support for <q>
9. Support for <cite>

I'm not sure if the following require custom styling: <abbr>, <dfn>, <ruby>, <rp>, <rt>, <bdi>

Blockquote styles are probably the next step! These would probably involve a thick left border of sorts which might need it's own Sass variable.

And let's think about whether or not a footer inside a blockquote should be styled differently for citing a source.

If you decide to take this upon yourself, thanks!

Propose a Jekyll theme based on this for quick repo docs on GitHub Pages

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.

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?

Right now, <button disabled> displays like any other button, same opacity, same cursor, same hover styles – no way to see that it's disabled other than clicking on it and wondering why nothing happens.
Some additional styles are necessary here in my opinion. 👀

I saw this PR(#23).
I think it is a good idea to add Linter.
Currently, gulpfile.js does not standardize the presence of semicolons and the style of indent.

However, it is inefficient to create all linter settings manually.
So I suggest creating a config based on JavaScript Standard Style(eslint-config-standard).

In addition, I think that it is also effective to set up the next.

• stylelint
• EditorConfig

If you have an opinion please!
If you are considering adding, I can give PR. (It will take a little while.)

Styling for <h1> headings is currently broken, as all <h1> headings are forced to have the same font size.

HTML allows you to have multiple <h1> elements on a page¹, with one being the main site title and the others being nested e.g. inside <article> elements and acting as the main title for the respective article.

Browsers respect this and display nested <h1> elements smaller than the main one, but water.css breaks this because it forces all <h1> elements to have the same font-size.

<html>
  <body>
    <h1>Main title</h1>
    <article>
      <h1>Sub title</h1> <!-- Should have same size as <h2> -->
    </article>
  </body>
</html>

¹ The Document Outline as intended by HTML5 – but while browsers visually adhere to it by scaling down <h1> elements, they don't implement the Outline algorithm on a semantic level, unfortunately.

I think it would be a good idea for the demo to have a link to the cdn of the current theme that the page is on. Like when it's on light, the link to the light cdn, and the same for dark.

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.

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%);
}

How about creating a favicon for use on demo pages etc?
As favicon is displayed on Google Search, setting a cool favicon will attract more users.
https://support.google.com/webmasters/answer/9290858?hl=en

I think range inputs are in need of some better styles – the missing axis of the slider makes it unnecessarily hard to identify them imo:

If I add size attributes for the image on the demo page, as shown below, the kitten gets squeezed when its container width is smaller than the image width. The width is changed, but the height remains the same, so the image changes aspect ratios.

<img src="https://placekitten.com/408/287" alt="Example kitten" width="408" height="287">

But if I add height: auto to the img rule set in the _base.scss file, the image keeps its aspect ratio when resized.

img {
  max-width: 100%;
  height: auto;
}

I like to specify both width and height on any image, when known, so that the text on the page doesn't jump around as the images load. Can that line be added to the img rule set without causing other problems? Thank you.

We can style the <address> element, or more specifically, the links inside!

MDN has good documentation:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/address

They've put icons before each type of link by using the following selectors:

a[href^="mailto"]::before {
    content: "📧 ";
}

a[href^="tel"]::before {
    content: "📞 ";
}

We could probably do something more interesting here, but I'm not a great designer and nothing's coming to mind. Any ideas?

This is an issue even if this library is used for dead simple html demos.

It has contrast ratio of only 1.61.

do you accept color scheme PR's?

When I visit https://kognise.github.io/water.css/, I get a 404 for the CSS file and no styles are applied.

When <code> is adjacent to <code> in a different line, the background color will overlap.
This is also true for <code> in <li>.
I looking at Google Chrome.

If you consider this markup, I think it is better to adjust line-height, padding, margin, etc...

#76 brought up the point that it's difficult for new HTML users to understand how to use some of the more complicated HTML elements.

I'd love to see index.html (or maybe a separate page) have some sections on how to use each of the elements water.css supports. For example, documentation for the blockquote element could be:

Blockquote

Documentation

Example usage:

<blockquote cite="https://www.huxley.net/bnw/four.html">
    <p>Words can be like X-rays, if you use them properly – they'll go through anything. You read and you're pierced.</p>
    <footer>
        <cite>– Aldous Huxley, Brave New World</cite>
    </footer>
</blockquote>

Demo:

Words can be like X-rays, if you use them properly – they'll go through anything. You read and you're pierced.

– Aldous Huxley, Brave New World

There would be a few parts to this issue:

1. Discussion on what the content documentation should contain?
2. Discussion on what the documentation should look like visually?
3. Writing of the html for this documentation

This is a lot of work to do, so any help on this issue is very appreciated!

Expected behavior

I was expecting it to switch the theme after clicking on the button the very first time.

Actual behavior

The switch button doesn't work at first click. But works fine afterward.

How to reproduce

• Go to https://watercss.netlify.com/
• click on Switch theme
• Watch it not switch at first click.

Browser

Version 73.0.3683.103 (Official Build) (64-bit)

Operating system: Tecno Camon X pro ( Android 0)

Recording Of The Bug

Tables could probably use some default styles.

Here's a list of potential elements to style:

• table (The full table)
• thead (The header row of a table)
• tbody (The body rows of a table)
• tfoot (The footer row of a table)
• tr (A row of the table)
• td (Single cell)
• th (Single cell corresponding to a row or column header)

Here's some other uncommon elements that are valid inside of a table:

• caption
• colgroup / col

The website shows "not secure" warning:

And condsole points to the placekitten.com fixed http request:

Loading mixed (insecure) display content “http://placekitten.com/408/287” on a secure page```

I really love the library ❤️ but I think the <select> tag needs some adjustment.
It is hard to see a difference to a simple button.

Maybe an inline svg can be added to show that it is a <select>.

select {
  background: #949494
    url("data:image/svg+xml;utf8,<svg viewBox='0 0 140 140' width='24' height='24' xmlns='http://www.w3.org/2000/svg'><g><path d='m121.3,34.6c-1.6-1.6-4.2-1.6-5.8,0l-51,51.1-51.1-51.1c-1.6-1.6-4.2-1.6-5.8,0-1.6,1.6-1.6,4.2 0,5.8l53.9,53.9c0.8,0.8 1.8,1.2 2.9,1.2 1,0 2.1-0.4 2.9-1.2l53.9-53.9c1.7-1.6 1.7-4.2 0.1-5.8z'/></g></svg>")
    no-repeat;
  background-size: 12px;
  background-position: calc(100% - 15px) 57%;
  background-color: #efefef;
  padding-right: 35px;
}

Something like this looks good.

Thank you for this cool lib :)

This is a must, imo. Since you want to be able to switch some stuff easily for different clients.

CSS vars aren't supported by all browsers but question is if it's even worth talking about supporting older browsers since this helper lib is just for small PoC stuff.

If support for older stuff is needed one could use Sass but then again comes the question if this is overkill for such a small helper lib. I do believe however, that being able to quickly switch color themes is necessary - at least for me personally.

What do you think?

The source files for water.css were changed from SASS to just plain CSS using CSS variables. See the full details on #71.

This made the theming guide in README.md out of date. It needs these minor updates:

• The references to SASS should be removed.
• The variables should no longer be SASS variables. Instead of listing all our variables, we can just link to src/variables-dark.css or src/variables-light.css
• How to edit CSS variables in browser to test theming
• Basic Theming: How to override these CSS variables with your own stylesheet
• Advanced Theming: Information about setting up a custom build file in src/builds/ should be added. There's a few types of builds that we should have descriptions for (see #71):
  • Normal (Like dark.css)
  • Standalone (Like dark.standalone.css)
  • Legacy (Like dark-legacy.css)
  • Legacy Standalone (Like dark-legacy.standalone.css)
• Policy around support for community themes from #26/#42

Hi all,

So I noticed a weird issue. When I have a simple form going, without water.css it looks like this:

With water.css it looks like this

If the image failed to load: for some reason, after including water.css it moves input fields to the left of the form. If the import is commented out - fields are centered.

Not sure what's causing it all, though it looks like a thing to def fix.