Ask HN: What are solid examples of well written HTML and CSS websites? | Hacker News Reader

Ask HN: What are solid examples of well written HTML and CSS websites?

37 pointsepolanski24 comments

Recently I started analyzing much more the documents and stylesheets I produce as well as reading more the official CSS and HTML specs. While catering to implementers of user agents, they are generally a goldmine of solid information.

I'd like also to get inspired by quality work on the web, but inspecting websites pretty much never yields anything that resembles a readable document, HTML semantics and CSS quality are generally in a disastrous state.

Thus my question, can you suggest websites who's html and css can be considered of extremely high standards?

I can't list many safe for MDN and wikipedia.

View on HN

http://www.csszengarden.com/ has been preaching separate content & presentation for as long as I’ve been writing HTML.

Fail

Doesn't work well on mobile

I could navigate

My website [1] is handcoded and I decided to push ES6 with ESM modules without any bloated build toolchain.

The website should work without JS but all the interactive features, gimmicks and improving parts are done with a bit of JS and CSS trickery ;)

Code for the weblog is statically pregenerated, and the article format is markdown.

I mostly built it for fun over the holidays, and decided to keep it as a creative space. Don't care what others think of it, and will never use angular or some other overengineered babel-using framework for my personal website.

I think that's what the (old) web was about: discovery of interesting corners on the web. And I want to keep that spirit alive.

[1] https://cookie.engineer/

The jingle. LOL

Looks good. BTW, why <samp> for the icons?

That's a cozy site you have! Love all the little inventions, but for some reason the flashy links (on :hover) stand out the most to me :D

A couple sugesstions for mobile version if you don't mind:

- Article titles could use word wrapping, overflow-x: auto or even something similar to <marquee> as it's impossible to read the longer titles now

- Since you use rounded borders for the article "cards", little horizontal margins (like 0.5rem) seem to be in order

Screenshot: https://i.ibb.co/59x5Fnh/IMG-20220327-150339.jpg

Please don't start filling up my browser history just because I scrolled down your site.

Had to click back 3 times to get back here. Not cool.

Pretty good site other than that.

I run programming at a (relatively) successful digital agency in Los Angeles. Everyone has a different idea of what’s perfect in the web dev world (and I’m scared to even post this for fear of being shredded here on HN lol) but I’ve tried to keep a running list of basic mistakes I see from junior engineers over the years here: https://github.com/funkhaus/best-practices

Maybe that helps point you in the right direction.

My advice: Just do your best, pick a direction that makes sense to you, be consistent with it, and be OK with changing your approach to work with a new team.

>No CSS resets

Wait why?

I use style guides and bem from several companies, it seems that you come "close" to it. (No idea how to bring this in.)

But there's really an explanation why this has to be done.

CSS normalisation > CSS reset

Not the original commenter, but I believe it's only specific to Meyer's CSS reset and its descendants. Unless you're laboriously redefining every element that you'll be using, the costs far outstrip the benefits of removing everything and starting from scratch.

Plus, there's this tendency to not test for accessibility (I know that a significant portion of websites today aren't accessible for people with disabilities...)

Even ignoring users' concerns (which is to emphasize is plain wrong), depending on the specific reset, it tends to f*** up CSS ordering and makes debugging issues generally harder (since it clutters up everything).

Couldn’t have said it better myself. starts slow clap

> HTML semantics and CSS quality are generally in a disastrous state

I believe many people have tried hard to do the right thing. But the truth of the matter is that HTML as a markup vocabulary is stuck at a 80's core language with a 90's vision for casual academic publishing mixed in, and then since mid/late 90's, CSS (and a gazillion of divs and spans) has been kludged on top to make up for HTML's lack of evolution and inappropriateness to describe digital content in this millenium. Yes we can kindof make it work, but it cannot be said that today's web stack is even remotely usable by actual content creators like even Flash used to be. Instead, we're churning through complex JavaScript frameworks, new languages, and entire new runtimes to exercise browsers into a workable platform for web apps with a laughable power budget.

What's left of grand visions for "semantic" HTML and structure/presentation separation, invented to lend credit to the HTML/CSS/JS trifecta after the fact more than anything else IMO, is maybe accessibility to some degree (which is at least something) and a hope for well-meant, bona fide SEO; and even the latter isn't helping anyone, and hasn't for a long time.

The fundamental flaw of the proposed structure/presentation dichotomy is that a piece of digital content should be captured close to the "intent" of its author, which in the majority of cases is very different from an 80's idea of an academic paper with section, subsections, and paragraphs.

This despite HTML being based on SGML which had always all means necessary to evolve markup in a highly structured fashion, and even encourages using your own vocabulary to map into an output/presentation vocabulary. For example, to model a sub-vocabulary for capturing a discussion thread like the one we're having here, which seems quite a natural use case for HTML - but nope, we must use hierarchical text and then pile a shit-tonne of CSS over it. Is that really "semantic", or rather a case of eternal September and embarrassing self-delusion?

This is a great comment. I'm pretty sure every non-trivial website would be better specified (as opposed to HTML) in almost any measurable way (LOC, clarity, etc) in say raw opengl.

Yes, creating a UI in an immediate mode tech would be pretty hard - still easier than HTML/CSS.

I'd love to see someone prove me right: Take any non-trivial site like twitter, facebook.com, whatever and reproduce it with opengl/d3d or whatever. I bet it will be less LOC (incl all the libs the source website includes), more clear, easier to extend, faster to draw, et cetera.

I’d love to see someone try and epicly fail to even render legible text. I have a feeling this thread is seriously underappreciating how many things browsers get right for them.

To be clear, I think the authors of the browsers have in general done a heroic job. I'm not talking about the browser impl, I'm impugning HTML and CSS as UI specification mechanisms.

Unfortunately I feel like there are too many different philosophies behind web design right now to point you to any given site. Mostly because any popular and complex site is going to use some levels of abstraction, i.e. React or Elm or similar. And so a lot of well-programmed websites don't have readable user-facing code. Or, on the other side of the spectrum, there are plenty of sites that value simplicity to the point that they have no-JS, minimal CSS, and super readable HTML. But that's not exactly hard to do.

One of the ways that I learn is by picking out a given HTML tag, for example, from the soup of a website's source code. And then reading the MDN page for that tag, which has information on the idiomatic ways to use it.

> And so a lot of well-programmed websites don't have readable user-facing code.

What does it means "well-programmed" if the end product isn't:

- accessible

- semantically correct

- light (no unnecessary javascript bloat, no unnecessary chains of dozens of divs, no cascading !important, very good performance)

I don't buy much the "well-programmed" fable of applications that don't show that in the end result.

I’m arguing that at a certain scale, writing HTML by hand is unmaintainable, and so the best option is to use a framework like Elm. Elm is going to compile and minify into unreadable JS that then generates likely-unreadable HTML. (I’m using Elm as an example since its syntax is so different, but the same applies for Reactor whatever the kids are using these days.)

I’m not disagreeing with you so much as giving my own tangential perspective.

My rails app has really nice HTML and CSS. All the class names are logical and lovely to code in.

My rails app takes that lovely HTML and CSS, and (in the middleware) it makes it look really ugly. It removes all the sugar, white space, newlines and SCSS niceness. It replaces all the lovely class names with numbered class (c1, c2...). It removes unused classes from the CSS.

So... it's well programmed, and very ugly when viewed by the user. It's smaller and semantically correct, but reading it client side is not really possible for a human, or a scraper (because the class names change)

Now the ugly HTML/CSS is displayed rather nicely, so the end results are (to the user) nice.

I'm not sure I buy the premise of the question.

Professional web developers don't have time to create elaborate abstractions for the sake of making their code "semantic" and easily understood by visitors reading their website's source.

Websites are ultimately for the user agent. "Semantic" HTML and CSS were never really so. They were guidelines to create code that was way more abstract than necessary and smuggled in a lot of terminology and concepts from print media, all of which were somewhat important before there were things like Firebug and proper dev tools.

Semantic html isn't important for visitors reading the source code but for web crawlers, seo and for accessibility.

> They were guidelines to create code that was way more abstract than necessary and smuggled in a lot of terminology and concepts from print media

This is historically very wrong. Also, printing of html documents is still one of its major uses (e.g. any time you download a pdf of a ticket you buy).

I'm honestly baffled at how little care there is for well written html.

If you don't care about your applications being html, don't bother putting them into browsers at all, just go native.

Or if you really need the browser base, put everything in a canvas, why bother with xml?

> Professional web developers don't have time to create elaborate abstractions for the sake of making their code "semantic"

This attitude is how I end up having to decipher that a loop of divs is just a simple list, or have to decipher that some other weird div with complex onClick events was just an anchor (a link).

There's plenty of benefits from writing semantically meaningful html and "professional web developers" should care about those if they want to write maintainable quality products rather than the next overbloated 5 MB JS broken e-commerce.

> just go native

Most people should, but creating native ui code is slowly becoming a lost art.

Maybe https://whimsical.club/ is what you are looking for?

Here's a shortcut-list page

https://docs.uidrafter.com/shortcuts

Reply on news.ycombinator.com