Ask HN: What are solid examples of well written HTML and CSS websites?
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.
25 comments
[ 2.8 ms ] story [ 72.3 ms ] threadOne 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.
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 not disagreeing with you so much as giving my own tangential perspective.
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.
Doesn't work well on mobile
I could navigate
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.
> 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.
Most people should, but creating native ui code is slowly becoming a lost art.
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?
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.
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.
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.
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).
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/
Looks good. BTW, why <samp> for the icons?
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
Had to click back 3 times to get back here. Not cool.
Pretty good site other than that.
https://docs.uidrafter.com/shortcuts