The notion that this feels refreshing enough to be compelling news is a testament to how incredibly convoluted our use of browser technology has become. It's nice to be reminded of CSS's humbler, less-radioactive days...
CSS has always been broken. For example, for many years it was impossible to vertically center an element in its parent (without extensive hacks). And still there are weird things like not being able to select all elements A which have B in them with a single CSS rule.
In my opinion, the reason that web technology sucks is that the standards are being created for novices instead of for developers. If the web was a place for developers, we would have seen multiple competing replacements for CSS years ago.
As a developer whose job is to deal with the ugly details of implementation, it's easy to forget the original purpose of the technology we're building.
Creating something for novices (or humans, as I like to call them) is the noble thing to do. Maybe the standards committee missed the target somewhat, but their goal was to empower anyone to participate in the web.
I'm getting a bit sidetracked now, but I highly recommend watching this fantastic talk by Bret Victor; it has really changed the way I think about the work I do:
https://vimeo.com/115154289
> Creating something for novices (or humans, as I like to call them) is the noble thing to do.
No, the noble thing to do for a committee is to acknowledge that you (as a committee, no matter how large) don't know what is best for all people, and that there are intelligent people out there (i.e., not part of the committee) who might have more insight than you do.
EDIT: Rephrased this a little because from the comments it seems this was misunderstood.
It's true that it costs nothing to join a W3C mailing list. However, if you join such a list and actually try to participate, you rapidly discover that:
1) Making a meaningful contribution requires being able to commit enough time to shepherd that contribution through the twin gauntlets of W3C process and internal committee politics;
2) The only people who can justify committing that kind of time are people for whom doing so is their full-time job;
3) Almost all of the people whose full-time job is participating in a W3C list are browser implementers;
4) Browser implementers, unsurprisingly, tend to see the problems and concerns of browser implementers as being inherently more important than the problems and concerns of other types of stakeholders in the Web (e.g. Web developers, marketers/adtech people, privacy advocates, accessibility advocates, etc.).
You generally discover this the first time you have the temerity to offer an opinion, at which point you are bombarded with responses about how you don't really understand the issue because you're not a browser implementer and have no idea how hard it is to be a browser implementer because browser implementers have it harder than anybody else in the world including lepers and orphans and seriously you have no freaking idea how anything in the world even works and bro do you even implement we didn't think so thanks for your useless opinion now go away.
(Full disclosure: I may still be a little bitter from my participation in the HTML5 process.)
I agree. The more worrying thing is that with proposals like CSS Modules, we're going even deeper down the rabbit hole with classes everywhere for everything.
Perhaps, but I think we're actually on the right track. With enough tumbling down the proverbial rabbit hole, we might finally just pop up on the other side.
Our tools have gotten good enough to allow us to imagine many permutations of a hypothetical future-browser, and the best ideas coming from these experimental technologies are being embraced by companies like Facebook and Google, who represent an obvious power-player in terms of spec influence.
In particular the recent trend of eliminating all the global scope/cascade issues (most notably via "CSS in JS" from the React community) is a good sign that our technology is evolving -- not merely mutating.
ul li { list-style-type: disc; }
ul li li { list-style-type: circle; }
ul li li li { list-style-type: square; }
ol li { list-style-type: decimal; }
ol li li { list-style-type: lower-roman; }
ol li li li { list-style-type: lower-alpha; }
These are bad. Very bad. Example: <ul><li><ol><li> uses unordered styling on the ordered inner list.
A little better:
ul > li { list-style-type: disc; }
ul ul > li { list-style-type: circle; }
ul ul ul > li { list-style-type: square; }
ol > li { list-style-type: decimal; }
ol ol > li { list-style-type: lower-roman; }
ol ol ol > li { list-style-type: lower-alpha; }
But it breaks the font sizing. Also it would be cool if H1 would be smaller inside an ARTICLE than H1 outside of an article like the default setting in Safari etc.
Would be good if useful defaults wouldn't be destroyed by too general css.
When I first learned about CSS I was pretty intrigued by the
W3C Core Styles [1]. They were a pretty good illustration of the separation of presentation from the underlying markup.
Zen Garden is pretty much the opposite of what one should do nowadays. Someone wrote some markup and sprinkled a ton of CSS hooks on top and then someone else came along and wrote the CSS.
If you've ever wondered how some websites end up with a meg of CSS, that's exactly how that happens. Each view/page starts with some markup, then you sprinkle some one-off CSS hooks over it, and then you write some overly specific CSS rules which are impossible to reuse. Rinse and repeat.
It's more efficient to create a library of reusable building blocks and then build your views/pages out of these. All of the more organized approaches (BEM, SUIT, etc) work this way. You always use what's already there and you only extend a component or create a new one if it's absolutely necessary.
I use the last approach, libraries that make up my elements.
But I always feel bad with all the CSS classes in my markup.
Back in the days I often had only <10 CSS classes and created my styles relative to that. I had the hope that those 10 classes would vanish with HTML5 and its special div-tags.
But now I'm running around throwing bootstrap classes around like there is no tomorrow.
Oh, that one does bring back memories! A proto-CSS Zen Garden of sorts, absolutely fascinating at the time.
We used to spend hours applying those 8 stylesheets to our pages and deciding which one we preferred... Really edgy types used two, or perhaps even three, different styles on their handwoven Web Pages.
Can we please use this as the new basic stylesheet that is used in browsers like Firefox and Chrome? Who decided that those ugly default stylesheets must be be applied to unstyled documents?
The <aside> styling was an experiment, since I'm really not sure how to style those nicely. On a large enough screen, the aside sites off beside the body text, and on a mobile browser, the grey line is visible on the right and you can scroll over to see the aside. Unfortunately this doesn't work well at all on screen sizes small enough that the aside half fits.
I come from a graphic design background with training in typography. While you _can_ specify font-size in any units CSS understands, typography as a field has traditionally used PT and EM units for sizing and spacing.
- for container size I use % or PX
- for margins, spacing, and padding I use EM or PX
Turns out I'm wrong about that 1px is required to be 1 device pixel. But the 3/4 rule is not universal and only applies to print. I don't know how different implementations handle this.
CSS 'pixels' are a dark, dark magic, come back to the light!
CSS pixels are a measure of your viewing angle, the physical measurement of the device, and your screen's pixel density. Basically 15px should look like 15px should look like 15px, no matter what you're looking at, but because the actual pixel densities of screens differ it can be really weird to think about.
You may need a 30px icon to display 15px wide on a retina screen, even though it sounds like a 15px image should be 100% large (and therefore crisp) at 15px in CSS.
CSS 'px' units don't map directly 1:1 with pixels in your screen, it's weird. :/
In general, CSS 'PX' is great for spacing inside and outside containers. I often use 5px or 15px padding in places that don't directly touch or contain text. Where text is involved I like to define my spacing in 'em' units because those are relative to the 'font-size', so if I change the font size the spacing will still look great!
It's almost more of a reset, than anything, but when you're authoring a classless stylesheet, the line is blurry. Using a readable width for the overall document makes it several times better than the default styles alone. The preformatted styles are much nicer than the defaults, too.
Very nice project. This is a quality normalize stylesheet.
It however pains me how this is heralded as something new by HN. "Finally, someone figured out how to do CSS correctly!" ... Shows how most people have no idea how to work with CSS yet comment on it. CSS Resets and Normalize stylesheets have been used for decades.
Edit: I feel like I should add this I'm not bashing this project. I recognize the quality of it.
This actually doesn’t normalize anything; that is, it doesn’t account for differences in the various UA stylesheets and how they render things by default so things are consistent between browsers.
Perhaps there are some things that could be incorporated from Normalize, which documents the subtle (and not so subtle) differences in how browsers handle certain elements: https://github.com/necolas/normalize.css
This looks so good and nice. I would definitely use it with some modifications for a drop in replacement of markdown block inside some blog. But will wrap it in a class ( e.g. .article-content ).
What is a beneficial stylesheet system, according to me, is a system that can scale and gives you the opportunity to create a complicated website. This unfortunately doesn't. Sorry.
It’s 2015--have the browser use real small-caps if the font supports them. Even if it doesn’t, you’re probably better off letting the browser make them instead of you creating them.
font-feature-settings: “smcp”;
on an element turns lowercase letters into small-caps;
Personally I think a much better question is why change the box-sizing? I’d call it out of scope for something like this. Very seldom have I encountered a situation where I actually want border-box rather than content-box; there are normally better ways of doing things. (Truth to tell, I’ve wanted padding-box more often than border-box in recent times, but only Firefox supports it.) Ideally calc() can be used too; it’s more powerful and expressive and well supported nowadays. The last piece of the puzzle to make it all fit together well on more complex arrangements is CSS variables, but they’re only available in Firefox at present.
Do people realize here that classes in HTML were actually invented to hook styling info through CSS and that it's actually the approved and promoted use case by the standards body?
I can't speak for everyone, but I suspect web developers are used to staring at "markup soup" when viewing the source of a pretty-nice-looking website such as the one showcased here, and so this seems refreshingly elegant.
I know I certainly appreciate as little of the markup soup as possible. I tend to try and use as little markup as needed to write semantically correct code. However, these days people expect you to use the twitter bootstrap and markup soup to build sites and web apps. I don't understand why people are fighting the web rather than working with it.
