I make a bunch of tiny static websites for API demos and such, and always run against the same problem: I hate the browser's default styles but don't want to spend time writing my own stylesheet for such a tiny app.
Now I can just include Water.css in my `<head>` and forget about it. The demo app will still work, it'll look good, and I won't have spent any time making a stylesheet.
Who?
Let me quote the GitHub repository:
> You might want to use Water.css if you're making a simple static or demo website that you don't want to spend time styling.
> You probably don't want to use it for a production app or something that has more than a simple document. Rule of thumb: if your site has a navbar, don't use Water.css. It's just not meant for that kind of content.
Water.css has a dark theme by default, but some users wanted a light theme so I added one. Think it's ugly? Feel free to create a pull request :D
It sounds backwards, but this is why you should use this feature. It sends a message to browser vendors (via Chrome Status eg https://www.chromestatus.com/features/5109758977638400) that developers want to use those features, which helps the Chrome team (and other vendors) prioritize what to work on.
Build sites to be standards compliant and accessible first, and then progressively enhance them using new browser features to give the user a better experience. It's absolutely the best way to build for the web.
It's a pain on the CPU though if you have a lot of non-transform/opacity changes though. It's much better to just animate the elements that you want animated and leave the rest alone.
I hadn't considered that, although it shouldn't create waste, right? Presumably, unchanging properties with transitions enabled don't add any work to be done. If it's only the ones that change, and if I really do want all of those to transition, there's no problem.
Right, but a lot of properties you probably don't want animated, and modern frameworks also reuse dom elements sometimes, so it might create a lot of lag and weird transitions between elements that you didn't foresee.
Cool. Reminds me of the original W3C Core Styles [0]. Created long before Boostrap, YUI or Eric Meyer's CSS [1], the stylesheets providing the web with free stylesheets and looked great back in the day. Simpler times when you could understand most web dev by reading a spec or two.
Thank you for this. There's a bunch of us who, once in a while, think of finally putting up that simple website or blog, with a minimalist touch. But then we have to think of how it'll actually look and we go into analysis paralysis. That's where the weekend project usually goes back to snooze. This kind of initiatives helps to at least get to the next hurdle.
You only have to set the margins/width of your document and maybe some sort of header & footer and you're done with the CSS your very basic but also very readable website.
I am not in a position to doubt your stated preference, but certainly "it looks rather good to me" does not block you from understanding why others would would want some basic styles applied to the sites they create and visit.
The OP demo looks better only because the css adds a linebreak after the widgets. But I actually prefer the cleaner look of the default style. A matter of being used to it, probably.
On wide screens, and with different pixel densities, defaults start to manifestly suck rapidly.
Fonts which are too small or large, or text lines which are too long, are objectively harder to read. Other design choices similarly have measurable impacts.
Jakob Nielsen's methodology of timing task completion and measuring completion accuracy is a UI/UX testing methodology which removes subjectivity.
> Fonts which are too small or large, or text lines which are too long, are objectively harder to read.
I compulsively CTRL+wheel-up and CTRL+wheel-down all the websites that I read until the "right" size appears, so I do not really care about the font size setup by the author of the site. But probably my behavior is not very representative.
This is nice and useful. You have inspired me to start a list of classless themes: https://github.com/dbohdan/classless-css. I used part of your demo page as the basis for the comparison screenshots.
The table layout is ugly, though. As this is a pretty basic HTML table, you can't do much but you can certainly do better than a table with all borders.
"As a starting point, avoid any border or frame surrounding the table. This is a Victorian embellishment which is entirely unnecessary as text alignment will shape the table just fine."
"Tables should not be set to look like nets with every number enclosed. Try to do without rules altogether. They should be used only when they are absolutely necessary. Vertical rules are needed only when the space between columns is so narrow that mistakes will occur in reading without rules. Tables without vertical rules look better. Thin rules are better than thick ones."
I didn't do any color striping, this would also be an improvement to distinguish the table head from the table rows but I didn't find quickly any coloring I liked.
I happen to end up creating a lot of static web pages when building simple websites or documentation (for internal and external use) - is there a collection of lightweight CSS resources like this?
For example, some things I would want to be able to select/tweak:
* Colour scheme/theme
* Responsiveness to mobile devices (i.e. changing fonts/layout, etc)
* Navigation bar
* Transition effects
* Support for older browsers (but still look okay (yes this is still a requirement in 2019))
* Support for IE (which seems to be hilariously harder than it should be)
* Toggle/select use of fonts
If not then it might be useful to build out a tool to dynamically create such a thing.
Sweet. I really liked the idea of ccs zen garden. But the designs where mostly absolute positioned images and css hacks. a lot have happened to css since ...
I've heard of this before and it's a nice idea - yet something still feels better about keeping the docs version controlled and with the project itself.
Also, some of these projects have restrictions about publicly releasing documentation (even hosted privately on third party servers).
If your aim is to help people snazz up quick HTML pages, it would be helpful to have as simple URL to include the CSS. Something like watercss.com/light.css. This way, we don't even have to visit your GitHub to get the CDN URL. It'd save some time and make water.css the go-to for quick styling.
The author already provides a CDN url. If they are so inclined, creating a memorable url (perhaps even a shortlink) would help with styling quick and dirty projects. I don't think people are doing to be running massive websites using this library.
Business being the key term here - this kid is 13, and from what I can tell, doesn't make any money from this. How would it make sense for him to pay to have this available via CDN?
Add the code as a snippet or associate it with a keyboard shortcut in your text editor. Then it's literally trivial to add it to an html page regardless of the URL.
Looks really good! Definitely would use something like this for some quick pages alright.
Two minor pieces of feedback — when I click "Switch theme", it seems to take you to non-styled rather than the light theme, not sure if that's what was intended or not? Could be good to have buttons for both.
Also, you seem to be getting an SSL mixed content warning, purely because of the Kitten pic. Know that it's not a big deal for a demo page, but if you wanted to get rid of it, you could use something like LoremPixel.com — they support switching URLs to HTTPS and have a 'cat' category!
Cool! Previously when I hit "Switch theme" it was loading unstyled, but double-checking it now & it's working for me correctly — might have been some plugin on the browser I was looking at it with causing interference with loading the 2nd stylesheet.
What's so bad about black-on-white text, sans-serif headers, serif texts and monotype blockquotes? Just because this theme set's specific colors and fonts/sizes, I'm not quite sure, how this automatically makes it any more beautiful than the standard (which generally is really responsive too)?
Beauty is indeed in the eye of the beholder, but although subjective, there seems to be a popular consensus that the browser's defaults can be improved. And apparently it doesn't take much to get to another popular consensus of what is acceptable. That's where a project like this takes us.
Beauty is subjective, some people like the style in the linked page, others not. Personally i like the default fonts and colors (at least on Windows, i think on Linux the default font sizes are a bit large) but not everyone does.
Besides this is just fashion, the defaults were chosen because at some point people found them beautiful, but over time they simply fell out of fashion. Nowadays they're there mainly to avoid breaking sites that do not override them.
I like this! More and more, I think about making my CSS sheets element only and moving more complex "component" styles into JavaScript. This makes me attempt to find semantic HTML representations of components before coming up with new styles and entering append-only CSS prison. So something like this would work great for me (even for more dynamic sites, really!).
Water is similar, but simpler and lighter. Milligram defines styles for generic HTML elements like Water does, but Milligram also has features that make some of your HTML specific to Milligram (such as button styles and grid layout), and it comes with the Roboto font, which increases download size.
The need for something like this - basic styling because the default display is so bad for raw html - suggests that there's something missing from our browsers. Of course everyone has their own preferences, but being able to add <theme "foo"> at the top of an html page would be very helpful. In many instances the exact styling isn't important as long as there's some styling. It would, among other things, minimize on bandwidth while providing a comfortable experience.
This reminds me of picnic.css [0], which uses the same technique of styling everything nicely by default, but adds some options for changing things when you want.
I've been wondering where this trend to use the system font came from. I understand that web applications want to use a system font for common operating systems so that they look a bit more native. But that doesn't necessarily make it a good choice for body text.
My main issue with web apps is that they ignore the choices I make for how applications look on my computer. We shouldn’t generally be changing fonts, picking colors and styling form components in apps like Slack: rather we should use the default look and feel of the operating system the user is running and use semantic color and font names so our apps fit in to the user’s computing environment.
Can you start another thread on how you got to this point in your life as a 13 yr old? I want my three kids (oldest 6) to be doing what you are doing in another seven or so years.
Kudos on a great project and thanks for sharing it with the world!
Not OP, but my dad was in a similar situation to yourself - when I was 12 he bought me an Arduino kit for Christmas and we spent the holidays building projects together. When I was 13-14 he started taking my sister and I to CoderDojos. I'm not saying this will work for every kid and I was nowhere near as advanced as this guy at his age but it has given me a what seems to be a great career path post-university and a good background in open-source software.
I love that you are considering how egotistical you are at 13. You seem like a really emotionally intelligent person which will serve you, by the way, so well in the software industry. Make sure to never neglect learning about who you are as a person emotionally; its an investment that will take you much further than just technical skills.
How about writing a blog? You are clearly already a good writer. I'm an author and writing helps me clarify my thoughts and has spurred my growth in ways that is complementary to my technical development.
I wondered when I checked out your profile and involvement on repl.it if you didn't have a blog and/or didn't host things on your own servers if this is because this is challenging for a 13 year old who does not have access to credit cards, etc?
I would like to see a version for those of us that structure our documents.
What is this structure you speak of?
Most people assume HTML has a 'head' and a 'body'. The head has script and tag things in it, the body is just free-form open-fire zone of content.
But there is more to it than this.
The body should have some structure to it. That means a 'header', a 'main' and a 'footer'. In the 'header' you are going to want a 'nav' and the same for the 'footer', you are going to want a 'nav'. Even if the links are to your social media sites there is still something to go in the respective areas.
Then when it comes to your 'main' content, if you believe in structure, you are wanting to have 'article' or 'section' with a possible 'aside' or two.
Then there are images. Images don't have to be in random 'div' elements. They should be in 'figure' or 'picture' elements.
Anyone who is not writing HTML this way, using the structural elements and structuring their document might as well just be writing in .txt format or posting jpgs of their pages to the internet. You have got to be organised. Ignorance of the HTML elements is not helpful, knowing them is. They shape how you think and how you organise your code.
A default stylesheet for people that write this way - structured - could have many useful touches. So CSS grid for the 'header'/'main'/'footer' could include the best way to ensure a sticky footer with the row definitions and align-self: end for the footer bit.
Images in picture/figure elements could be set to be done properly, if in a containing 'figure' then set to 100% width. If the main has a 'grid' setup then you could easily have well structured HTML show neatly with anything 'not structured' evident because it wouldn't be fitting in the boxes.
Document outline is important and a basic stylesheet needs to do badly at styling things that are not going to outline well. So the headings styles should only apply to headings that are in 'article', 'section' or 'aside' blocks.
There is also a small matter of pixels. When was the last time a pixel meant anything? 2007? Nowadays pixels are virtual. So it really has to be em/rems and viewer units all the way. The pixel is outmoded.
For your forms you want to think differently and more structured. So 'form' needs to be 'display: grid' and then your labels be column 1 with inputs on column 2. Then have a css variable in the responsive media query to set the inputs to column 1 if on mobile. Done this way you can get rid of the hacky margins and paddings on the buttons and just use 'grid gap'.
This means forms can then be a straight list of label/input pairs in well organised structured code that looks fantastic and is fully mobile out the box.
As it is the stylesheet is a good idea but it does not really bring any benefits to structured documents in the post-pixel world where CSS grid does all the heavy lifting of simple layout tasks.
What could have been good feedback is ruined by tone. This is someone who has in good faith decided to show the HN community. The fact that he's 13 doesn't even really enter into it.
Here is someone who has created something new and has come to share and the first thing you say is:
> I would like to see a version for those of us that structure our documents.
> What is this structure you speak of?
Let's try:
---
I love what you've done. I know that this is still new but I would really love to see some additional support for more structured documents.
<Insert more details about what you mean about structure>
I will try, if time allows, to create a pull request for these features.
In fact tips like yours are what is most useful to learn for me from here.
However, in primary school I learned a little bit about content sectioning. Stories had to have a beginning, a middle and an end. Titles were important too.
These concepts of 'header', 'main' and 'footer' with 'sections' are not a million miles away from how writing was taught in the olden days to primary school kids.
Just because the grown ups can't be bothered to structure their HTML as per the spec with these logical groupings I don't see why 13 year olds should get a free pass. I don't want the web to be stuck in a sea of div tags styled with floats forever.
Thanks for the feedback, although I would like to make the point: Water.css does style structured websites and doesn't involve any floats or div tags anywhere. If not for semantic html Water.css wouldn't work at all because that's what enables the classless approach.
And I'm purposely not including support for navbars and such as this is meant more for article pages and tiny demos and the sorts. If you're interested in adding a footer, though, I'm accepting PRs :)
However, I think you have the makings of something quite brilliant. Most of the web 'div soup industry' is stuck in the past, the tools are there and the world actually needs a really good HTML5 + CSS Grid starting kit for one off pages.
I think you can make some skeleton templates in HTML5 with what you are working with on the CSS. So no classes, a template with a header, main, aside and footer at the top level, then in the main the page title as h1, then an article with its own header in h2 with sections with their own h3 titles. Then in the aside a basic form. People can delete it but if they want a contact us then it is good to go.
Then in the footer have a nav. Put social media links. Also an address tag in the footer for the copyright notice. Yep, address tag.
If you also add a figure and an image with a couple of srcsets in a section then it is all done for people.
Next, styling. So no ids or classes. Basically a reset.css that uses css variables with fallbacks. The variables default to mobile and the fallbacks are for desktop. Do it all in ems.
Also add in a details/summary. These are not being used enough and they come with default styling that few know how to do. The arrow and the blue focus box need addressing.
The form, that needs to be simple label/input pairs with the css grid with the css variables and fallbacks making it responsive.
The aside is also responsive. It falls below the main content in the document structure and on desktop it turns into a sidebar, left of the main content.
It might take a week or two to put that together but it will put you far ahead of everyone out there who has been floating divs into 'responsive designs' with 5000 class tags for the last five years. Forget frameworks, forget divs and spans. Invent some new rules for classes, so in the template you have one article with class 'blog entry' and another with something like 'recipe'. Put the CSS together for some styling so that the whole component just needs the one class on the parent and element selectors do the rest.
If you build this out then there won't be a finer educational material out there for people wanting to learn to code. All the lessons can be applied to any other 'big project', the sort that have 500 div per page in them, needlessly.
If you use a small handful of css variables for 'color', 'background-color', 'font' and main document font size, perhaps with another for main content width then you can also have a 'night mode' button on there to swap these variables around to demonstrate however many themes you want, all achievable with a few variables instead of some compiled CSS bloat.
As mentioned, sorry to get off on the wrong footing but you are the greatest hope for sensible CSS I have come across yet.
There are many, many people who are using website builder things such as Wix to build simple sites. You can build something easier than those things for people wanting just a simple web presence on a page.
Structure in a web page does matter but nobody has it now as the world wide web is a sea of divs and spans. Search engines don't have structure as a metric but sometimes we do things because we want accessible, maintainable, simple quality design and not just hacks to game search engines.
You have made a great start, I think that you are green enough to be able to create something that really does make the web dev world think again as well as bring something that scratches not just your itch for a simple page well themed but for a lot of people who need a really good starting point for their own 'simple' pages. Simple sounds stupid in some contexts, I assure you that 'simple' is a virtue, any fool can make a complicated bloat of a web page, simple and elegant needs thinking. You can do it!
You're not getting the love here, though I agree with most of this.
Sadly, HTML5 offers virtually all of this out of the box, but it's not seen or understood by most. Mark Pilgrim's Dive Into HTML5 is itself mostly a demonstration of this (it lacks article and section tags, though is otherwise lean), and the page source itsel is very highly readable:
There are also notions such as microformats and standard templates, which smoth the way to standard and substitutable stylesheets as well as parsing, search, bibliographic, and archival tools.
I am finding that it is female developers who are on the conference circuit explaining how we have been doing it wrong and how we can do it right. I did the view source and I won't be adding him to my list of 'HTML5 gurus' just yet, even though times change and his work may be better now.
Same as my previous comment, no 'main' or 'nav' or all that stuff. There are these microformat things which are okay if you want to get your product info or book into Google in an sku/price/ISBN type of schema. But we conflate that with weird 'aria' accessibility things. Properly structured HTML just does that out the box.
So why use 'main'? Well, if you do reader mode in Firefox or Safari then it cuts the cruft out and just shows you the stuff you want to read. Or that you want others to read. It is not rocket science and you don't need any Wordpress style 'skip to main content' link hidden at the top or 'role=main', just the 'main' element will do.
But who knows that?
Everyone in the game should.
I checked the Apple site for HTML recently and they sell billions from that site. But none of the links in the footer are in a 'nav' element. I know people don't care and that I am the only person in the world that has noticed their 'poor HTML' but you would think they would be able to get that bit of structure right. Their site is pretty awesome, they have 'main' done but didn't do very well with the navigation links. I am not being a pedant for thinking that is odd but for people who only care about the latest frameworks and 'technologies' content is just data not something that needs to be structured. I don't care about 'technologies', to me content has to be structured right if it is to be taken seriously.
What I also find odd is that structure and HTML5 elements are easy. There are vastly less elements than there are random Bootstrap classes but nobody cares to learn the elements.
Apple has the footer links in a footer tag with role=contentinfo, which is somewhat appropriate (The role=contentinfo is somewhat unnecessary, since a top-level footer already implies it, but it doesn't hurt). Not all navigation has to be in a nav tag. To quote the HTML spec:
> Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.
You can argue that what Apple has here is comprehensive enough to warrant being called out as a navigation, especially since the structure there doesn't appear to be immediately accessible from other page sections, but it's not clear cut, and it's likely a predictable pattern for a user of assistive technologies that company homepages have such footers.
I am sure assistive technologies and their users are able to 'see' the footer for what it is. But Apple do have what I 'see' as a massive amount of navigation going on down there that goes beyond a short series of links. They have the short series of links in the absolute footer too. On closer inspection of the iPhone page they are using 'nav' elements for this. However the markup is still curious to me. There are h3 tags in label elements. The document outline is sound but it looks cranky to me.
According to MDN:
Placing heading elements within a <label> interferes with many kinds of assistive technology, because headings are commonly used as a navigation aid. If the label's text needs to be adjusted visually, use CSS classes applied to the <label> element instead.
They also have the breadcrumbs for the page in the footer. I approve of breadcrumbs but there is a place for them and that is in the 'main' content. Whether you show them on visually pretty pages or not is another matter, but a global footer isn't the specific content the breadcrumbs refer to, that is in 'main'.
Now Apple clearly care a lot about their page but it also has to look great on those 32 bit ipads that don't have the latest Safari on them. So they cannot use grid layout.
If they were able to use grid layout then they would be able to have a fraction of the markup plus they could have the breadcrumbs in main at the top of the document with them appearing at the top of the footer. The visual layout could be solved with the document structure being less of a hack.
They also load images as background images when I feel they are content images, not mere decoration. By doing so they are not able to use things like srcsets and make use of data saving on phones that request that mode due to low bandwidth.
I do find these design decisions most interesting. I also appreciate that they do have to have the site work for old 32 bit ipads - particularly if those users are to buy a 64 bit ipad! Their site is undoubtedly working well and they have gone the extra mile for accessibility. However, the more you look into it, even if first assumptions are wrong (me not seeing the 'nav') the more curious it gets. I didn't spot the 'nav' elements for the sea of divs with untold class tags, labels with headings in them and 'aria' markup. If it was true design elegance then it would be simpler markup and the assistive technologies could work it all out due to clear document structure. Plus I would spot the 'nav' elements first time.
Yes that is what I like to see - no classes! So long as one structures the content then it looks good. Or at least not 'unstyled'.
Tacit is behind the times when it comes to CSS Grid, I don't see the point in jiggling with floats, again it is one of those things that constrains how you think. With CSS Grid you can write content in a natural order and then position blocks of it according to design and, with a few CSS variables get it working in all viewports.
Interesting that tacit does not show default styles with structural elements. Maybe the HTML5 spec has been worked through rather than the starting point assumed to be structured content.
I can remember the days of Microsoft Word when some people would use templates and styles. Some people just did not get it and would make a title a title by hitting the 'bold' button and pushing the font size up, maybe using blank lines for spacing. I feel that the web is full of people who never understood styles in Word and didn't have a clue as to why you might need them.
This seems like an orthogonal complaint. For example, on my website, I make an effort to use semantic HTML elements–but that doesn't mean I couldn't drop in a CSS file that styled text and added margins like this one. I don't quite understand how this has anything to do with this framework.
I make a bunch of tiny static websites for API demos and such, and always run against the same problem: I hate the browser's default styles but don't want to spend time writing my own stylesheet for such a tiny app.
Now I can just include Water.css in my `<head>` and forget about it. The demo app will still work, it'll look good, and I won't have spent any time making a stylesheet.
Who?
Let me quote the GitHub repository:
> You might want to use Water.css if you're making a simple static or demo website that you don't want to spend time styling.
> You probably don't want to use it for a production app or something that has more than a simple document. Rule of thumb: if your site has a navbar, don't use Water.css. It's just not meant for that kind of content.
Water.css has a dark theme by default, but some users wanted a light theme so I added one. Think it's ugly? Feel free to create a pull request :D