Writ – Opinionated, classless styles for semantic HTML | Hacker News Reader

Writ – Opinionated, classless styles for semantic HTML

cmcenroe.me

150 pointscitizenk61 comments

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.

http://www.w3.org/Consortium/join

Or just join www-style[1] or public-webapps[2], or there's the WHATWG mailing list for all of its specs[3]. All of these are totally free to join.

[1]: https://lists.w3.org/Archives/Public/www-style/ [2]: https://lists.w3.org/Archives/Public/public-webapps/ [3]: https://whatwg.org/mailing-list#specs

> All of these are totally free to join.

This is true, but misleading.

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.)

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.

You mean like this?

    :matches(A B) {
       color: blue;
    }

http://www.w3.org/TR/selectors4/#matches

I think that, no, the point was to style elements A that happen to have B inside, while :matches will apply to elements B that are wrapped in A.

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

Oops, I didn't notice this, thanks!

Edit: https://github.com/programble/writ/issues/4

Feels like a response to: http://motherfuckingwebsite.com and http://bettermotherfuckingwebsite.com

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.

https://github.com/programble/writ/issues/5

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.

[1]: http://www.w3.org/StyleSheets/Core/

http://www.csszengarden.com/ is a neat example of that too: some wildly different visual designs with the same 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.

It uses these 12 IDs:

css-zen-garden, design-archives, design-selection, zen-benefits, zen-explanation, zen-intro, zen-participation, zen-preamble, zen-requirements, zen-resources, zen-summary, zen-supporting

And these 39 classes:

archives, benefits, css-resources, design-archives, design-name, design-selection, designer-name, explanation, extra1, extra2, extra3, extra4, extra5, extra6, indicator, intro, main, next, page-wrapper, participation, preamble, requirements, resources, select, sidebar, summary, supporting, view-css, viewall, wrapper, zen-accessibility, zen-faq, zen-github, zen-license, zen-resources, zen-submit, zen-translations, zen-validate-css, zen-validate-html

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?

Why cannot unstyled document be nice by default?

It would probably break some websites.

Run this on some websites and you'll see some things moving around:

  document.head.insertAdjacentHTML('afterbegin', '<link rel="stylesheet" href="https://cmcenroe.me/writ/writ.min.css">')

Chrome and Firefox both support user stylesheets, so you could do that.

Reminds me of a more complete version of Tacit [1].

[1] http://yegor256.github.io/tacit/

I've been using tacit a lot, and its working out great for my one page apps.

On the reference page https://cmcenroe.me/writ/reference.html the aside note causes a horizontal scrollbar for me. Chromium 43.0.2357.81 (64-bit) on linux.

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.

Edit: https://github.com/programble/writ/issues/6

Same here, Chrome 44.0.2403.157 m on Windows 7.

A CSS framework that actually separates content from presentation. I wish that kind of things was more common.

The body font size seems tiny to me.

Yeah, font-size: 14px is a bad idea. It should really, really be put back to 16px (just leave the definition out!).

Font sizes are even better if defined in PT instead of PX!

Eh, 16px = 12pt, simple 4:3 ratio, why bother with the pt unit at all?

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

- for text sizes I use PT or %

Here's a short, good primer for typography on the web: http://www.markboulton.co.uk/journal/five-simple-steps-to-be...

Yeah, on 96 DPI. Anywhere else you rely on browser scaling if you don't use pt.

Edit: Ok, so I'm not a web developer, so I read after it: http://www.w3.org/Style/Examples/007/units.en.html

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.

16px will always be 16px, unless you redefine CSS pixel size. pt is more scalable.

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!

https://github.com/programble/writ/issues/7

I honestly can't see why the Writ stylesheet is better than the standard html output. It seems to me that he just used a new font.

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.

The line-height change alone is a huge improvement in readability.

Not all abbreviations are initialisms, and small caps therefore aren't always appropriate.

Bootstrap (and various other similar systems) lets you specify this, by adding a class of .initialism to the <abbr>

http://getbootstrap.com/css/#type-abbreviations

https://github.com/programble/writ/issues/16

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

I agree that "normalize" wasn't the right word. It's however closer to what this do than "reset".

I don't know how I would call Writ. "Baseline" perhaps? Something like that.

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.

I agree that would be a good stylesheet system, but it is not Writ's intended purpose.

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;

    font-feature-settings: “c2sc”;

turns uppercase letters into small-caps.

More at https://drafts.csswg.org/css-fonts/#font-variant-caps-prop.

Safari’s renderring engine WebKit just got font-feature-settings: support: https://twitter.com/webkit/status/631827777319256064.

umm ok but why not box-sizing?

html{box-sizing:border-box} *,:after,:before{box-sizing:inherit}

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.

http://caniuse.com/#feat=css-variables,calc

Personally I think a much better question is why change the box-sizing?

Because the default content-box is a pain in the ass to work with, so to be able to use border-box all the time is a good thing: http://www.paulirish.com/2012/box-sizing-border-box-ftw/.

As you say... browser support, but also is more concise.

And personally I love the other box-sizing :)

FYI writ.bassam.co

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.

Yes, but clearly in this case classes were not needed to make clean, responsive, and readable design.

Sick.

Reply on news.ycombinator.com