All you may need is HTML
fabiensanglard.net
fabiensanglard.net
> But mostly css appeals to our vanity and ego.
Design isn't just about aesthetics. Good information design, clear visual hierarchy, accessibility, etc. all help with communication. The author's effective use of spacing, bold, and code tags show us that they know this intuitively, despite what they write.
But the key, underlying point to ALL this stuff is that you do NOT NEED TO WORRY ABOUT PRESENTATION until you have the CONTENT.
A huge temptation is to spend hours and hours tweaking the presentation as a way of avoiding actually creating the content; this is the real danger.
(should mention https://thebestmotherfucking.website of course)
On the other hand, I was disappointed to see the unique one of those I think it is worth to follow the advice [1] was not cited.
For curiosity reasons, I found out about [1] on a well-known website [2] that definitely puts content in front of presentation, even though I like their website's design.
Of all of them, I think the one you linked is probably the best. It is still interesting to watch the progression.
Such drastic difference with basic adjustments, damn
Initiate rant mode:
- The gray on gray is like a joke, except it's not. I get the theory and alleged benefits. I get that some do prefer it, especially for IDEs. I get that some are happy to see (or at least apply) it all over the web. It just does not seem to apply here. Man alive. Literally making it harder to differentiate the text.
- I don't mind adjusting the browser width to get the lines exactly the right length for my screen and reading preference. Actually, I far prefer it over all the other options. This is like a tragedy-of-the-commons or lowest-common-denominator or dumbing-down-on-the-false-premise-of-being-smart issue. Instead of utilizing what we have, and encouraging people to learn and become capable with the simple and flexible tools, it's one size fits all (or, you pick the size you think I want). Only it's not.
End of rant. Sheesh.
I flipped over into reader mode and it's much improved, solely because of line length and dark mode.
I can't speak for other frameworks but tailwind only compiles the classes you actually use at build.
The balance between design & function can be at odds when the mission of the page is not clear.
For consumption, these are awesome, your brain almost relaxes as it's easier than the usual onslaught.
The CSS of the second website is wrong, as it uses 'color' without setting 'background-color'. Assuming anything about the default background color is not possible because it is user-configurable in most browsers.
At least http://motherfuckingwebsite.com remains readable when you change your color settings (the second one is completely unreadable on my browser).
The text was readable as designed on a white-background. CSS that considers accessibility or print friendly is always good to add.
If the whole point of your website is to brag about code to accomplish reasonable formatting.... can we at least have code formatting? I think I have enough bandwidth to afford some line breaks.
Client side GA????
An UI made of disintegrated, inconsistent and half-assed tries at writing CSS/JS. Not a rare problem in my experience.
Also happens to me when trying to write a "tiny web app for fun" where the CONTENT is interactive and created by myself.
So, to extend your comment: you do not need to worry about content if your website isn't even reachable. A GET request should never result in the client being bombarded with captchas. Unless you have a sure fire way to determine if said client is a human or an evil AI taking over the world (nobody does), just serve the damn page.
It's definitely not, there is something else doing that to you. But it's not this website.
<li><a href=""></a>
</li>
[0] example post from my blog https://mvexel.prose.sh/20230227-keeping-osm-database-uptoda...
Everybody finds their writing juices differently. Push where it means you'll write more.
same went for emacs I stopped using themes
Bold statement. Those look mostly terrible to me.
Mailing lists are still good for that I guess.
But alas, base styles are a mess (yet still there!). They do have some hierarchy but accessibility and readability are bad. That's aside from aesthetics: just stuff like alignment, spacing, fonts, flow: very poor.
I am aware that more base styles would make that cursed "reset.css" even larger, but I guess if a large part wouldn't even need that, it would be fine. It would be a situation where everyone can choose "good styles" or "spend lots of effort to get even better, custom, styling", rather than everyone "spend lots of effort to get an even decent styling".
Keep it all the same as current if there's no tag on the page, but if you add something like <meta uastyles="1.0.0"> or something, apply an improved set of default styles.
Get rid of the need for resets with <meta uastyles="none">
Basically - I'd love a way to allow browser vendors to dramatically improve the defaults without breaking everything, and also giving frameworks an easy opt out.
There's nothing here that would stop you from still doing that.
But if we're talking about practicality... I think far more people would get a benefit from improved defaults (as long as they're not breaking existing sites).
While I've modified the user styles for my chrome profile as a part of being a web developer, I'm not aware of a single non-developer acquaintance who has (literally - none). Honestly, not even many of the devs I've worked with have done it.
It's just not all that relevant when the defaults are so bad that all the sites are overriding them anyways. Makes it very hard to apply a set of user styles that's sane, so no one does.
Make the defaults better, and maybe you can end up back there.
My browsing experience should not be determined by an artist or product designer 1000 miles away from me in an office somewhere.
Javascript transitions/animations, on the other hand... yeah. I won't got there.
Hell, that typeface is something anyone is subjected too if you do anything long enough.
The experience of getting to imagine how much thought goes into laying out text on a typewriter is something I think should be for everyone to try at least a few times.
Feel free to find a site better than http://motherfuckingwebsite.com/
Like I can barely imagine what your house might look like. Just like a purely functional weathered hovel with the absolutely barest essentials. A perfect prison cell
You need a UI team to create a page of readable text? That sounds like an expensive waste.
But it sounds like those 'UI' people think they know better and don't need suggestions from programmers about reading words, even though its what they do all day.
And I don't know where you've been for the last 30 some years, but the web is not a text only format, and the reason HTML was invented was specifically to be able to create a designed space where text can actually make sense and is not a gigantic wall of impossibly small black on white text.
Yet the market for text only novels is staggering.
Books are designed, too.
> scroll the mousewheel: giant footer section slides up taking half the viewport
> move the mouse cursor up: giant ass header slide menu drops down covering half the viewport
should be absolutely no motion on a page unless i specifically click on something, like play button or slide out button. and that includes parallax bullshit.
prefers-reduced-motion should be the DEFAULT not an override. ffs haven't we learnt anything in the last 20 years of web dev - you cant rely on web monkeys to build things right (\s).
---
and f*k you to whoever thought having mouse hover popup autoplay boxes on youtube was a good idea.
I don’t personally feel nearly as strongly about the subject, but I wholeheartedly agree with this.
Visual communication and design predates CSS. Information architecture, design, guiding the user through the message is definitely a skill.
CSS can do as much distraction as it can enhancement. It's one appeal of Tailwind, it's more than serviceable while learning about the design, hierarchy, and flow.
That can mean going all out in design, or having an HTML-only page like nothing. Both have value in their own way, and should reflect the creator to some extent.
Isn't that what HTML gives us?
If HTML were truly semantic, browsers could implement accessibility features around it, but because they're so vague, there's no real way for browsers to do that, which offloads the responsibility onto web developers, who in most cases aren't granted budget to do it. There are a handful of features such as alt properties, but these are pretty limited.
So yeah, HTML should give us that, but that's part of what users gave up when we decided it was acceptable to allow random websites to run code on our machines and tell us how our content should be displayed.
There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs), semantic HTML helps in some cases but is never going to give you automatic accessibility, and a one size fits all browser style is still not going to give you what you need even as you add increasingly unsemantic tags to try to improve it (which is exactly what was happening pre-CSS).
I've been writing web code since 1997ish, so...
> There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs)
I did not describe a golden era of HTML, because a golden era of HTML never happened. Instead, it was precluded by the introduction of JS/CSS. Had JS and CSS never been invented, we might have achieved a golden era of HTML, but we would have needed web standards to mature before that could happen. What happened was, web standards did mature, but they matured to serve websites rather than users. As a result, mature web standards center around JS and CSS, leaving HTML anemic and weak.
What we have now is a time of conflicting philosophies, with websites competing to add as much as possible to out "innovate" each other. Users still suffer the same inconsistent interfaces they did in 1997, it's just that instead of browsers being inconsistent, it's websites that are inconsistent.
All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
How does this differ from how <div> was being used before?
I've switched to using <section> simply because it's a better name, but I'm not sure it's made any meaningful difference in my code.
Another example of the pointlessness of this issue is <em> and <strong>. I've rarely seen code where these weren't used exactly the same as <i> and <b> were before. In rare cases, I've seen someone do something like make <em> a different color rather than italic, and that's almost always been a bad idea, because when HTML authors use <em> they almost always intend for it to be italic. In fact, I'd say we should just continue using <i> and <b> because those communicate intent better, but at this point I've worked in too many codebases that decided that <i> could be hacked to mean "icon" (i.e. using FontAwesome) which is a horrible, awful, no-good, bad, hack.
> All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
That's true, but I think we'd be moving forward a lot more quickly if we weren't devoting most of standards development resources toward giving companies more fine-grained control of our browsers through CSS/JS.
I'd say HTML for itself just gives us a way to give meaning or imply how something should be styled "headline of first order". In the end it's a markup language, not some magic styling tool.
How it is actually styled (in absence of CSS) is in the hands of the default rendering of your browser. That might very well be a very bad rendering, due to lack of knowledge/time/engagement of the people building/maintaining that renderer.
Also those renderes might come from a time and system where technical limitations where different, markup was different, lots of things were very different.
So I don't think we should expect HTML alone to "look nice" or work well in regards of readability.
I think we would win a lot if browsers default styles were beautiful (as in: really good, not merely fancy) designed. Many websites then would need just a few lines to set some colors, style that weird-custom thing they do or make it feel just a bit more personal.
And as mentioned, I achieve it myself with a style extension.
Message / medium have always mixed together.
Even folks who say content needs to be figured out before presentation... it's not so cut and dry. Your medium shapes your message - they are not mutually exclusive and for the receiver of the message, the medium matters for their reception of the message.
I understand the sentiment that TONS of CSS is probably a bad use of time. But trying to demonize or otherwise attach aesthetics the label of "meaningless" is, in my opinion, just as much egocentric as they claim CSS to be.
Why dismiss aesthetics out of hand like this, equating it with vanity and ego? Aesthetics are very important to people, possibly even more so than the information on the page.
That's not what I think the www is for, but not everyone agrees with me.
Then it shouldn't exist from the start.
To which I responded that I'd not use any JavaScript. Ideally, XML with stylesheets. Very light-weight, renders extremely fast, and is extremely friendly to automation tools (doesn't even require a browser for most tests). For the kind of product this was intended for, and I still believe it to this day, it would've been perfect: nobody needs any CSS animations there or any kind of interaction beyond filling forms and submitting them.
One of the interviewers was the head of the front-end department. He hadn't for a moment considered this to not be a joke, but pretended to answer this seriously by explaining that if they don't put a fashionable JavaScript framework into job description, they will not be able to hire front-end programmers.
In reality, there are plenty of things on the Web that could, in principle, be just HTML or, as in my example, XML + stylesheet, but won't be for no reason other than to feed the echochamber of the job market. Nevermind that from the business side this makes user experience worse, costs more to host and to maintain, and yet...
This is exactly why we are vague with tech stack in our job reqs. Why would you want talent that is laser-focused on specific keywords? What is the average lifetime of a JS/CSS framework? The game isn't to come in knowing this crap. It's to grasp fundamentals such that you can quickly learn the next ones.
I much prefer to hire less "skilled" employees who are more interested in the problem domain or product than they are any specific tooling. Goal-oriented developers can be taught to do anything in my experience.
A million times this. When I've hired, the specific languages/platforms/whatever the applicant has is of tertiary importance at best. What counts is the ability to engage in problem-solving, how well they will fit into the team, and how readily they can learn.
Everything else can be trained.
What people mean by "I will not be able to hire front-end programmers" is actually "I won't be able to hire cheap devs".
Much in the same way how programmers (and many others) are scared of "gaps" in their resumes (and will thus accept a job even if their finances would otherwise allow them to extend the job search further, creating more leverage on the employers), Web-programmers, specifically, will be vary today of putting, say, Mootools on their resume (because, oh the horror, I think it's like a decade old tech!). In the very same way programmers, especially in popular fields, like the Web, are compelled to follow group trends more than in less popular ones (eg. HPC).
Specifically, in the case of Web programmers, this has an additional side of creating a lot of bloat for no reason other than following fashion. Similar dynamics exist (or used to?) in the world of Java, where you have to (had to?) know about EE and Spring (which are huge and bloated frameworks, most probably don't need to use to get the work done, but were made a staple of Java programming due to fashion).
I think it's a bit different: the head-hunter agencies screen for these keywords, so programmers are incentivized to put those keywords into their resumes. Since programming jobs are seen as short-term investments anyways, programmers are looking at the jobs as the stepping stones to their later jobs, and so they feel pressured to look for a job where they can learn / hone the skill that they believe will be valuable in the job after this, and so on.
I forgot the name of the statistician who claimed that no matter the performance metric, if it is made known to the (human) subjects being so measured will quickly become irrelevant since the measured will learn to game the system. This is the result of applying a metric that grades on the number of years of experience with technology X, where the subjects are trying to optimize for their years of experience with technology X instead of a more complex and open-ended metric of being more knowledgeable or more talented or more dedicated etc. which aren't immediately and objectively measurable.
This is not a "pretend answer" and it's perfectly valid for devs to be picky about it. Nobody wants to work on garbage that started out as XML+CSS and mutated into a nightmarish mess that some "backend dev" cobbled together when the product team and the rest of the real world came knocking.
It's ridiculous that there even is a distinction between backend and frontend in 2023. It's so much easier to maintain a project when the devs can't feign ignorance.
I think you'd be amazed at some of the barebones functional systems that non-trivial segments of the world are satisfied with.
html_page_analytics.js html_page_bundle.min.js html_page_tracking.js html_page_d8fd766d76223ae.min.js html_page_user.js html_page_banners.js html_page_pardot_dfa7s778d9aa.min.js
What you are suggesting sounds something like golang templates and css. That works fine but you can’t easily get types in your templates. It’s a game changer when you have typescript at your disposal for your templates.
I remember a guy who wanted to make company documentation in LaTeX. Well yes it is great tool and we could put it in a git repo and render nice documents for the customers easily. Downside was 15-20 sales people who were not thrilled to use it and spend time learning how to use it.
I'm not sure though why sales people would need to edit it.
My discontent with LaTeX for documentation is that searching it sucks. I mean, you do get literal search for words, but if you want something smarter... PDFs don't interact well with searching tools we have.
Another problem: interactive scroll. In HTML documents you can scroll sections of documents independently of each other (if you need to), so you can create ad hoc views of your documentation that could be more useful to you (eg. collapse a bunch of tables or code listings just to see the text in between).
On the other hand, if you want to print it, oh man... it's going to look so much better! :)
"Why sales people would need to edit it?"
Because there were no dedicated people writing documentation, there were developers and sales people - that was it. Non technical documentation so "how to use the system" was going to be written by sales people.
Lots of times in a company you work with what you have and finding and hiring "technical writer who has experience or wants to work with LaTeX" I would count as hard task.
I mean, I have a feeling that if a company asked a technical writer to learn LaTeX, they would probably do it, even on their own time. It's a tough market, and learning LaTeX enough to produce something isn't a huge effort (also, there are a bunch of tools that prepare the boilerplate code for documents). But I can see how sales people might not have been impressed by such prospects.
(To be fair I am mostly depending on an incremental build and I'd say Java turns around in 2s, Javascript in about 20s. One of those breaks my chain of thought, the other doesn't.)
PS: Luckily, I'm not a frontend dev :)
If you even find new devs who'd want to work on this. Who wants to acquire very niche domain knowledge that you can't apply anywhere else?
That's not what I said. I think, that what you mean when you say "by hand" is the opposite of generating XML (and in case of XML, it's not CSS, the stylesheets are XSL that transform XML into HTML).
Before JavaScript frameworks were a thing, technologies like ColdFusion, JSP, ASP Classic proliferated. You can even find remains of this approach in relatively modern frameworks like Django. The idea was to generate XML or directly HTML on the server and send it to the client ready to be displayed rather than sending JavaScript that will request more data as it interacts with the user to build the interface. The former would be called "thin client", while the later is the "thick client". The former used to be more popular because programmers didn't see JavaScript or HTML as a worthwhile to learn language, not enough to build programs in it. It was seen as a target for transpilers.
This was before single page applications, or AJAX... The perceived downside of this approach was that for sites with many very similar pages the application server would have to generate a ton of HTMLs, which would be hard to cache server-side, so, allegedly, it would work slowly (compared to AJAX, where a basic HTML page with JavaScript framework would sit in cache and communicate using XML or JSON with the server to build missing parts).
XML + stylesheets is one of the ways to address this problem: essentially it does the same thing, but without JavaScript in the middle. The function of the XML part of the equation is to transfer the data that needs to be displayed, and the stylesheet transforms the XML into HTML that the browser knows how to display. Stylesheet can be generic and reused between different XMLs. It's not as flexible as using JavaScript but a lot easier on resources, and will probably beat AJAX solution in terms of speed.
Another benefit of XML + stylesheets is good integration with the browser testing tools. With tools like Selenium, you will always struggle to catch page state changes, and will not be able to respond to change as it happens, instead needing to poll for expected condition (that might never materialize). Stylesheets take this aspect completely away because there's nothing in them that happens asynchronously or in chunks. Unlike in single page application, where "page loaded" is undefined, there's an obvious way to tell when "page loaded happens".
The problem of XML + XSL(T) is that people have some preconceived notions about it. Very few people know the tool well, and for no particular reason, most people who know anything about the tool know very little about it, but are also very angry about it. Lots of polls for the "worst programming language" would mention XSL(T)... While the truth is that it's just very different from C, and that's what irks programmers. From engineering perspective, sites like, eg. this one, or Reddit or GMail would land themselves well to XML + XSL(T), but the reality is that modern day Web programmers, well, a lot of them, don't even know they have such a tool.
I find it so sad that our browsers have such bad default fonts that all websites feel the need to override them to get an acceptable look. It would be great if browsers had decent defaults for both the overall default as well as serf, sans-serif and monospace so that most websites who aren't worried about font branding can just stick with the default and users can get a good fond, or even their preferred font if they bothered to customize it.
There's no reason websites should even be able to set the font in my browser.
If it was just about websites achieving an acceptable look, you'd see people emulating industry leaders, but that's not what you see. Google, for example, uses Arial on its main page on my browsers at least--that's a font that's available on every browser I know of. If it's acceptable for Google, it seems like it's just acceptable in general.
Instead, the fonts being loaded are about websites achieving their own brand. I've built a lot of web frontends, and every time I get a rebrand contract, the designs I get contain a bunch of fonts.
As a user, I don't give a fuck about your brand. Being able to read your fonts clearly is a much higher priority for me than experiencing your brand. Fundamentally there's no reason at all that sites should be able to decide for me what font I read. I am lucky to have fairly good eyesight and no serious processing disorders, but users who have these issues are seriously negatively effected by sites overriding their browser defaults. And since few projects are given adequate accessibility budget, users are left with no recourse. Overriding a website's fonts with your browser settings doesn't really help, because sites often use pixels and other dimension units that make your site unreadable if you use a different font than what they tested with.
I tried this as a two-week experiment a year ago. I’ve never gone back, it improves the web so much.
(Well, actually I also block web font downloading altogether, for no particularly good reason, at the cost of icon fonts and Material Icons breakage, but it doesn’t often matter.)
Of course that can also be fixed, but there's only so far you can take this. I have the technical ability to edit CSS, but I don't reasonably have the time to do it for every site I visit.
Felt. I actually do adjust my user agent fonts and system fonts, and I hate it when these "system UI font stacks" aren't just "sans-serif" and I end up with Arial or Ubuntu because some guru said this is how you do it. Especially irksome though is the monospace fonts--either Courier New (which hints way too thin to be readable on my main display) or using some hard-to-decipher custom font that abuses ligatures.
But yes, I have seen decent browser fonts for most Linux distros.
Newer releases also have San Francisco Mono that it could use instead, which is even better since it's tuned for modern displays.
Even having some defined meta fonts with rough metrics so that you could say font-face: monospace-standard or whatever and have the text be roughly the same size everywhere would save so much effort and wasted data.
Including a small set of open fonts does seem like a good idea. I'd like to see Inter UI[0] included because it's a very nice screen/UI-optimized font would serve a similar purpose as "system-ui" does now, except without some of the pitfalls[1] that comes with.
[0]: https://rsms.me/inter/ [1]: https://infinnie.github.io/blog/2017/systemui.html
But no browser defaults to Courier New any more—Firefox on Windows was the last browser to finally update to a better font, just under a year ago (see https://bugzilla.mozilla.org/show_bug.cgi?id=1607913).
I fucking can't stand Consolas, give me Courier New because that font is readable literally anywhere.
Courier New is the most appalling piece of shit I've ever seen in my life. It's ugly at small sizes, jagged and unpleasant at medium sizes, and abhorrent at display sizes. WOW do I hate Courier. I hate it on Git Bash. I hate it in cmd, I hate that it exists. Consolas, by contrast, is lovely and beautifully-hinted at best, and inoffensive at worst.
I'll happily lump JavaScript in as a major accessibility concern. JS is most often used where it shouldn't (most recent in memory is the Unreal Engine docs). Using JS for such simple presentations is like building a 5000-story building to print a sheet of paper, when all you needed was the pre-printed sheet of paper (HTML, CSS).
I don't mind Consolas, and I like what is author using now (DejaVu Sans Mono), but their stance about varying reading experience depending on the OS makes me really, really devastated, because it just reflects a sad state of IT literacy and general adoption of basic philosophy of the web, which was built on premise that how content looks like depends both on author and user (through user agent) and fact that generic font family looks ugly is in other words defaults are bad combined with users have a bad taste and set bad default values.
As was said, we are supposed to express our preferences in (through) our (user) agent's preferences.
Most probably your browser will use four distinct fonts on this page, *all* of them (and more) you can define in your browser's or operating system's settings:
data:text/html,<p lang="ja">iii<code>iii</code><p lang="en">iii<code>iii</code>
Authors defining background colour without defining text colour is the reason we cannot effectively have default dark background and light text default in our UAs, because in this case we would see authors (light) background and ours (light) text.
On my site for example, I designed everything using Iowan as my main font because I know that it’s available on most Apple OS but then I manually picked a few fallback fonts that should be available on Windows, Android and the rest.
Default serif is just the last option if everything else doesn’t work.
It could be kerning, leading, default font size, all come together in very powerful ways before finding a very specific font to enhance the brand experience.
If we look at HN, the window we type a comment into continues to use a font when writing that can help induce more awareness of writing. Maybe it would be slightly different if it was a blinking square cursor. Or a slightly taller box.
This is blatantly incorrect or a flagrant misrepresentation. CSS can certainly improve readability without adding design.
Readability is a check list which stock HTML does not address.
If you stick to text files, you'll never have to go to caniuse.com ever. Need styles? Just make a PDF and throw that online. During the "XML HTML" phase the web went through, I never had to worry about validating my PDFs through an XML validator. Then when everyone decided using "<b>" and "<font>" tags was bad and insisting we switch to using "font-weight" CSS in a completely unrelated part of the file, guess what I had to do? Nothing! My PDF keeps rendering exactly the same way through every silly "trend" and "update" on the web, and never misses a beat on Lighthouse in Chrome.
Now if I could just convince all the browsers to implement .docx renderers out of the box, I'd really be set.
This only matters if you actually care about exactly how your website renders on any given browser. Most websites don't have any need to care. PDFs are the worst for this: They care, A LOT. Which means locking you in to some hideous rectangle that's a different aspect ratio than any monitors I own, locking down the fonts and colors so that I can't just rely on system defaults, etc.
If all you need is to convey text, and maybe take some input, HTML is a fantastic solution.
Just use some old chars (maybe them? https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing) and some spaces and boom, a nice style in a simple txt file!
The biggest problem with CSS is it's one language that's trying to do two things. I think that layout (grid, flex, anything that changes the shape of the page) and style (font, color, text sizes, etc...) are two separate things, and CSS makes it incredibly tempting to try to do both of those at the same time, which inevitably causes trouble.
Working on a website is easier when you can break those two things out into separate concepts. People love to praise/hate tailwind, but I think the best use for it is specifically for modifying layout. Layout changes deserve to be built right into the HTML itself because that's where you're looking when you need to reason about it, whereas style is more general and should be broken out into actual CSS rules to keep it more consistent across a site. Layout is much more directly tied to context than style is, at least as soon as you get into anything non-trivial. There really needs to be a better way to segment these two concepts.
At least, that's my hot take as a semi-passable css user.
HTML was mean to _be_ the document. CSS was meant to be a language for styling and re-styling those documents. That makes sense in the logic of decades past. You might have a bunch of documents, and go re-style them all when you move. Or a company might do this when they change their logo or get acquired.
But for a long time now almost every HTML document served on the web has long been a mix of design elements and one or more things that a human would call distinct documents, and CSS has kept up with styling those.
With a true "document", it's pretty sane to expect that you can readily style and re-style the same document with different stylesheets for different contexts without needing to go fiddle content. With full complex designs implemented in HTML, the HTML and CSS for at least those parts tend to be very tightly coupled and very likely to get rewritten together.
The fuzzy boundary between the content and the layout are a problem for both HTML and CSS.
I picked at this problem in a post this fall: https://t-ravis.com/post/doc/what_color_is_your_markup/
It confirms my issue with using tailwind. I like it! But as you mentioned “style” typically has a global, systematic, component based notion, and not a hierarchical one.
A perfect example is typography AKA font style and color. Yes, it has a structural/hierarchical notion, but only on an abstract component level.
Typography almost _always_ comes in aggregates. Font size, line height and more, even margins - they are very rarely orthogonal and composable.
Designers typically take great care to fine tune these things as components. Ask a designer to disentangle then into tokens and you get a very weird look!
On the structural level you want meaningful component classes to refer to them and maybe one or two modifier classes, if at all.
Thankfully tailwind offers @apply, so you can still leverage some definitions where it makes sense.
If you proclaim that CSS is "for vanity", your stables must have an awfully big ladder for getting on your horse.
Shall we take it one step further? Why even bother with HTML, semantic markup is just as much vanity as CSS: just put .txt files on the web. People can trivially copy-and-paste links to other files anyway, they copy-and-paste text all the time. Adding <a> elements is basically just browser candy. As long as the information's high quality, people will want to read it, right?
Sure, CSS is useful. But a lot of it is over-designed. The web in general, is over-designed.
Sure, that's like, my opinion. But no, they're not "one thing".
> As long as the information's high quality, people will want to read it, right?
I do. Probably, there's a fundamental difference in what we consider readable. I don't think pure HTML as rendered by modern browsers is necessarily ideal, but it's generally readable. Most of the extra elements, styling, javascript, pictures etc. on modern pages distract from the actual content and make it harder for me to read it.
Don't pretend that CSS is hard.
Yes, of course crazy CSS mastery to make vanity artworks on the web is hard, and yes doing stupid things with z-layer ordering and absolute vs relative positioning is the classic "family guy trying to work the blinds" gif, but decent CSS that makes information easier to read for a wide variety of people (including ESL, visually impaired, etc.) is barely any effort, and pretending we're all worse off because of CSS and that having a document format that lets you style your content with is a terrible idea is just willfully stupid.
(on that note: oh look, something that every single DTP product ever made supports, guess those are all terrible too, and I suppose that sarcastic joke about us all just using .txt files should get repeated here)
if i was to implement a browser that could properly render CSS for some given set of real life scenarios i would be getting back to you in 100 years. paying tax, banking, trading academic literature should not rely on a magazine formatting jenga puzzle
At the risk of being pendantic, asmallorange and hostgator are owned by the same entity[0].
That said, I like the premise of just writing and producing content and not necessarily worrying about setting up tooling. I think devs, and "geeks" in general, tend to enjoy tinkering with tooling, but it can be daunting for the less tech savvy. I suppose that's why things like Wordpress.com exist.
[0]: https://en.wikipedia.org/wiki/Endurance_International_Group
The more I learn, the more features look like training wheels and training wheels like restraints.
Their VPS offering is $55/month and is comparable to digital ocean's $18/month.
> A DNS pointing to the host Hostgator for an extra $12.95/year.
Why not use Netlify or GitHub pages? They can host static files for free.
I host a bunch of files and static html on my domain and I’ve moved it to github pages. The dns services bundled with the domain at gandi are enough to set it up on top of the free github pages, so my hosting is effectively free, and if I wanted I could still run a site generator.
Static html gets even easier by using something like simplecss, because that gives a basic design with zero effort on top of semantic html. https://simplecss.org/
Cloudflare Pages, Github Pages, Gitlab Pages, Netlify, etc, etc. It's all free at this level. Vastly distributed and they can all use CI/CD to build static-site-generator configurations for you, if you want that.
It's not about the money. Hostgator has been a recurrently awful host over the past 21 years, cutting people off as soon as they get popular, downtime when they overoversell their service. They're a relic, alongside Dreamhost, Bluehost, GoDaddy; the type of host we just don't need any more.
The rest of the article is right: you may not need anything more than HTML+CSS, but life is a lot easier if you don't have to build it yourself. I'll take Astro + Git + Cloudflare over "gen.php" + FTP + Hostgator any day.
> The fluff does not really matter much.
> WHY YOU MAY NOT NEED CUSTOM FONTS
> Custom fonts are a waste of bandwidth and a visual annoyance
Right-click -> View Page Source. Top of the page is a stylesheet that loads 2 fonts. Hard to take this article seriously.
It's hard to respect the advice of a designer whose deviations from their own rules make the design worse.
Almost any web-safe font[1] would have been a better choice.
[1]https://www.awayback.com/index.php/2010/02/03/revised-font-s...
I think articles that are just all about how you're bothering your readers can be a bit tedious, but there are ways even the owners are hurt by the belief they need every whizbang thing, because they all have maintenance costs and general quirkiness costs associated with them too.
One problem not listed is source code syntax highlighting. If you provide source code listings in articles, then highlighting is a big help to readers. Generating it in HTML is not fun.
Having written my fair share of HTML by hand, I'd say that the purpose may be better served by Markdown, or Org, or even plaintext. HTML has too much unnecessary detail if you're into low-effort content-centric stuff and cleanliness.
Learning HTML is fine, but learning HTML while avoiding CSS is not very useful, except as an esoteric hobby (like 6502 assembly, but much more complex). Using handwritten HTML if you're after content creation is unnecessary legwork.
OTOH holding an unorthodox view on a widespread technology, of course, improves one's chances to suddenly appear on the HN front page :)
Idk man. Doesn't seem at all complicated to me until you start involving CSS. Assuming you're just after basic content. Slap a <title> in <head>, a few <section>s in body, <p> your content. Maybe an <aside> for some spice! <a>, <img> and <video> might be useful if you want some hyper/multimedia.
The complications arrive when you want it to look like some designed page, regardless of user preferences, window/screen size, which browser, etc.
Agree though that Markdown and Org are good and useful tools.
On the main blog page, it sure looks like some of the entries are not sorted properly. For example the 10 Feb 2020 ThinkPad review.
Oh wait a second. Some of the dates are DD/MM/YYYY and some are MM/DD/YYYY!
If you need any sort of "stack" to fix the problem of "my dates are inconsistent", you're in serious trouble, my friend.
I appreciate it personally. I think most styling is about UX and not communicating information (although it can improve that). But I think it’s at least jaded and probably even a terrible idea to suggest websites should generally be implemented this way.
That combo is more than enough for almost all the websites out there, I've 3 different sites like that and they are blazingly fast, everything served from a $4 VPS (serving about 20k views per week).
[0]: caddyserver.com
I guess you mean because SSI is just a very limited mechanism as opposed to full blown Turing complete PHP or similar. But actually if the fragments/partials you include via SSI are user-posted content (comments) or syndicated content then of course SSI can't fence against <script> or other injections. In that case, you could use more sophisticated SGML mechanisms (other than SGML processing instructions as used by PHP or magic SGML comments as used by SSI) such as entity reference expansion that come with full type checking and context-dependent validity assessment for filtering all kind of injections (script elements, event handler attributes, image or link href injections or whatever). But you should at least use content-security-policy headers to block inline script.
Now wasn't that easy?
- Google Cloud Firebase Hosting - free; really good tooling to deploy, automatic CDN
- AWS S3 + CloudFront - a bit more setup, but more or less free
- Azure Static Web Apps - free
Firebase Hosting in particular is really easy to get started and connect a domain to it. The Firebase CLI tooling makes it dead simple to deploy updates as well.
But, really, in my dream world, ISPs would also act as registrars for their clients, so, once you pay them you get some automatic domain name, or maybe can pay a bit extra for a permanent one that you can take to the next ISP you sing with.
In many cases, a small amount of CSS can give you a lot of control over formatting in a way that is easy to maintain. Over the long term CSS has gotten much better in every respect but one.
That one respect is insofar as there is a "CSS specification" it is this
https://www.w3.org/TR/css-2022/
which itself refers to roughly 50 documents which furthermore has the mind-melting structure of "Document 17 replaces clauses 13.5 and 15.11.9 in Document 3". On top of that you need to refer to
for browser variations and various cheat sheets
https://css-tricks.com/snippets/css/complete-guide-grid/
which I'd usually advise against (you can consistently get the right answers if you look things up in the docs.)
Maintaining other people's CSS is also a bear and even maintaining my own is pretty bad for side projects that I work on sporadically for a few years (I wind up introducing a class to solve this problem and another to solve that problem and don't have much of a master plan.)
Then there are the various CSS frameworks which vary from useful to insane (the original Bootstrap which was about as easy to use as learning to paint with oils) and practices like BEM, which is the webs' answer to RAAI in C.
Please, eat your own dog food first.
The opposite of a great truth is also a great truth: You may need more than HTML.
The problem is (and I believe this is what the author tries to draw attention to) that people are fighting all sorts of half-backed stacks without necessarily having a fully justified reason for every incremental complication invovled.
The web is obviously more than a "clean page of text" metaphor. How much more we don't even know yet.
What would make this journey of discovery shorter is the simple golden rule that "computational complexity should be commensurate with the result"
The author criticizes generators, but apart from those terrible mysql CMSs there's also SGML, on which HTML (and XML) is based, lending HTML authoring affordances such as text macros, shared fragments, templating, custom shortform syntax a la markdown, stylesheets, pipelines, outline generators, link decorators, with full type checking etc. etc. HTML feels incomplete without.
The Thief reference, though, I don't get - is the point that mission briefs and picked up letters are using Times New Roman? It's a terrible screen font at small sizes, and also HN could do with a modest style upgrade to improve touchable areas/distances and support for prefers-color-scheme if only to hide you're browsing the orange site ;)
(1) With defaults, 3+ billion people already understand very well.
(2) For anything not a default, on the first day, the programmer understands and maybe no one else.
As I understand the history of UI programming, the HTML controls were built on, borrowed from, the controls in the IBM 3270 terminals heavily used in IBM's CICS (customer information control system) and originally designed for the user interface of airline reservation computing.
I don't know much about UI programming because my most important background in computing was for applied math computing for US national security where didn't use check boxes, radio buttons, single line text boxes, multi-line text boxes, links, etc. But as a user of the Internet and for the UI programming for my startup, I followed KISS, i.e., used HTML defaults.
This allows me to ship a static html site (S3 website) where the javascript functionality is limited to basic things, like toggling dark mode.
To build an "API", I crawl the files at compile time and generate json files in an /api folder, allowing me to fetch blog post metadata for searches that are processed on the client.
As icing on the cake, once the user has settled in, I use a service worker to pre-download/cache the all the posts in the blog site and allow for offline viewing. I have some tricks to avoid the annoyances of stuck sw caches.
Leads to a great user experience and maintainers don't need to have a backend portal - just write markdown and commit it straight to GitHub. Easy enough to teach people to use Typora and SourceTree
(Not a plug, it's a WIP and I have only put a few toy articles up) You can see it in action here: https://davidalsh.com/posts/the-case-for-a-sandboxed-script-...
I'm making a few too many requests in the first iteration, no cache control headers, asset minification, etc
Since then, I have been refining it for a contract that I am working on (introducing the SW) and I am keen to release it as an open source project - including a terraform script to deploy it to S3, setup Cloudfront and all that good stuff.
I always find static site generators a kind of leaky abstraction. They eventually try to abstract nearly the whole functionality of the web stack, and the larger the SSG the more apparent it becomes. But, for obvious reasons, they just cannot abstract all the peculiarities of the web from you.
I write posts in Markdown, use Pandoc to convert `.md` to `.html` and a simple Go script in 200-300 LoC [1] for my https://hirrolot.github.io/.
[1] https://github.com/Hirrolot/hirrolot.github.io/blob/master/g...
Also, the navbar at the top of the page might as well be invisible.
I'm still using Dreamweaver 8 for some old sites. I have to run it under Wine emulation now, but it still works. It still does a good job of layout.
Is there a more modern round-trip HTML/CSS tool?
I thought Dreamweaver was great when I first encountered it. That lasted until I happened to look under the hood at the HTML it was generating. What a horrifying, bloated mess it made of everything...
AFAIK there is no free lunch here; you learn to write it yourself, or you suffer it to be written poorly for you.
It's served via a CDN, so it's always really quick to load.
There's literally no cost to it for static sites.
You could create a git repository for your HTML site. Then, edit the HTML using VS Code. Every time you push to your repository, your site will get updated almost instantly.
All you have to pay for or worry about is domain name.
If you use a web host like Hostgator, your site will get banned when it gets a lot of traffic. Cloudflare has no such limits whether you get 10 visitors a day or 10k a day...
Writing in HTML sucks, and it's a distraction from your writing itself. Markdown or text are better on that account. And then pushing code through FTP ain't super fun, especially given that having a pipeline that runs Jekyll or Hugo is free on github and pretty much a copy-paste.
From a consumption perspective, having some form of consistency across your blog is also pretty good, even if to satisfy your ego, especially if you get it for free.
I would argue that setting up a bit of infra on top of it, which will probably take the better part of an hour if it's your first time, is a very good way of reducing the friction and making sure you actually write.
http://www.columbia.edu/~fdc/sample.html
Which one is: * Easier to navigate?
* Nicer to to look at?
We don't live in a HTML only world because no one wants to live in a HTML only world. Some techies might but 99% of ordinary people do not.
No one wants to look at black and white text all day, with every website looking exactly the same.
If this is what people wanted, then you'd see a lot more of these plain HTML websites. But you don't.
Resoundingly, the first. The second one is full of huge tiles that take up so much screen real estate, it's hard for me to scan over what is available. Crammed at the bottom are a ton of links, in no particular organization that was immediately apparent. The entire site is plastered with huge images everywhere, that don't really add to the content and just distract from whatever it was I was theoretically there for, and really don't help me understand the site at all. Also, the zoom effect on tiles keeps grabbing my attention when I was really just trying to move my mouse across them to get to something else that I'm now distracted from.
> * Nicer to to look at?
Depends on what you mean I guess; if you came to soak up pictures of smiling faces, I guess the second. But personally, I don't dislike the first.
> We don't live in a HTML only world because no one wants to live in a HTML only world. Some techies might but 99% of ordinary people do not.
I'm afraid this is a really awkward statement. There's no way to argue against it or really say anything to the contrary. You've framed it such that anyone who disagrees with you is "a techie" who in your definition does not represent any norm.
> Custom fonts are a waste of bandwidth
Latin subsetted fonts are generally 10-30Kb, it's really not that much. For comparison, it's unlikely you'll see blog authors get up in arms over a single PNG.
> they come with one of three evils called latency, FOUT, and FOIT
A few milliseconds of a different font appearing is truly not much of an evil, but can be addressed by exactly what the author links in their footnote.
Humorously, the author's own site is committing some sins here: both of two font files are >140kb, they don't have gzip on, and they have the fonts marked `font-display: block`. They could cut their CLS and LCP by almost 100% by addressing this: https://i.imgur.com/MOl32iS.png
Of course, it's already very fast, by virtue of having no other resources loading. This would be dramatically worse if there were scripts that needed to get downloaded.
Agreed. Make your own custom font files with only the characters you use, or are likely to use.
> A few milliseconds of a different font appearing is truly not much of an evil, but can be addressed by exactly what the author links in their footnote.
Browsers will wait for about 3 seconds for custom fonts to load before showing a fallback font.
> both of two font files are >140kb, they don't have gzip on
woff2 format fonts are already compressed, so gzip won't do much.
Depends on the `font-display` value on one's `@font-face`, which is where the author's choices of "latency, FOUT, and FOIT" comes from. For instance, Google Fonts uses `swap` by default, meaning the fallback shows right away: https://web.dev/font-best-practices/#choose-an-appropriate-f... (I also think Safari's `auto` font-display never shows fallbacks, but that may have changed)
But if you use `optional`, browsers will attempt to get the custom font into the first paint: https://drafts.csswg.org/css-fonts-4/#valdef-font-face-font-...
That's often enough. You can go another step further and preload the font, which I generally recommend. This especially helps if the font is otherwise discovered late by the browser.
When this hit pieces some against an entire tech-stack, always check the author's job, past expereince.
Our industry has not matured enough to split into expertise areas into solid titles, and grow respect for those titles just yet. As the author's title points it out very clearly as "Software Engineer".
Try getting a Job in any sizeable company by building your entire experience with HTML and tell me how it goes.
What is this, if not appeal to authority?
> Try getting a Job in any sizeable company by building your entire experience with HTML and tell me how it goes.
And this seems to be, "follow the crowd".
It is extraordinary claims, require extraordinary evidence, or experience/proven competence.
>And this seems to be, "follow the crowd".
And this seem to be, reactionary.
But they don't. All they require is for you to evaluate the claims, on their own merits, without examining the speaker for their credentials. Evaluating a claim based on the credentials of the speaker is quite exactly an appeal to authority.
> And this seem to be, reactionary.
I'm not sure what you mean by this, or how to take it, so I'll try again with more words. Nobody is claiming that the best way to get a job at a large company is to build an experience base consisting solely of pure HTML websites. Nobody is even claiming that this is a good way to get a job at such, or that it will work at all. This seems rather orthogonal to the claim that, depending on what you are building and what you are trying to accomplish, "All you may need is HTML".
I don’t get this argument. As a reader, I’m used to the monospace font of my OS because it’s the one I see everywhere. I don’t care at all about the fonts users of other OSes see. This custom font makes _your_ experience consistent, not the readers’.
Pretty much all the sites are now a days single page or with tons of JavaScript with a lot of xhr requests. Those xhr requests are huge too. Loading screens everywhere. Some of the loading screens are 5-7 seconds long.
And I have no luck with banks sites. They put a lot of efforts to block access.
There are complications, naturally: https://news.bloomberglaw.com/banking-law/small-banks-urge-c...
He talks about the evolution of his blog in this post[1] and has a link to the web archive of an early version.
All your blogs need is HTML.
Dreamweaver lets you pull in header/ footer HTML from a template, then see the complete HTML in the editor.
Your pages response shouldn't rely on this request succeeding.
I am getting my nose rubbed in this truth - about the benefits of basic minimal website design. Most websites are useless. Mine is pretty useless. I write it to have a web-presence, promote my consulting business, and because I feel a need to write (maybe that is an illness? - not sure..). I find writing forces me to think better, and the investment side of our business, requires I think well, or we die quickly. It's a harsh world now.
I found this Hackernews post, by researching how to update critical browser stuff, which has been borked for us, by our trading platform provider. Updating browser on Linux - and guess what? - lose all bookmarks, all customizations, everything. Arrrrgh!!! (happens EVERY update, of course).
Simple is often better. And the Web (most of it) has become crap, mostly. Or dangerous, toxic vector for economic assault. Bloody awful, nasty and sad. So it goes.
I am converting our crappy website from a provider (one.com) which bought our simplesite.com website builder thing, which worked pretty good. But the site had all this fancy stuff for menus and images and videos, and a truckload of .css stuff - sure, nice and fancy. But the conversion to the One.com builder stuff, does not work, of course. We cannot update (at all) our site from the data-description that one.com has in it's website-builder software. As of the forced conversion, we were complete off the air. Borked.
SO, this is stupid. Complexity and fancy design - is mostly stupid, and it also creates contrived dependency (keeps customers locked, makes them be forced to open their wallets and send you cash - good for providers, bad for customers.)
I got so pissed off, I decided to do it all ourselves. We built our site at AWS as an EC2 instance. Fucking website-building software is a scam, mostly.
The original poster is right. All you really need is HTML (AND some stuff to render videos and audio and maybe code to get paid for stuff, maybe...). Most of the .css stuff is fluff. And people are getting REAL tired of being dusted with fluff. OP is right.
Our old website is https://www.gemesyscanada.com It was a mess - a long bunch of stuff, posted over the years, research-logs, blogs, notes, etc. But now that it is a One.com, we cannot update it. The websitebuilder software gets to 90%, and then hangs - and we do not even get any error messages telling us what the problem is. Arrrgh.
We are building a simpler version - using AWS-EC2 - we have one free EC2 instance which I am experimenting with: http://35.182.107.190 and that is it. We have not even got a domain set up yet - it's all hacking & testing for now. But it looks like we can go this route. The whole thing is an exercise in vanity and ego. It really is, honestly. But why not? It is what our tiny little business does, and it is what I am. I've been doing AI since I went to Dr. Geoff Hinton's classes, and got a copy of Xerion working on a P/C running Linux - back in the 1990's. One must not hide one's light under a bushel, right? So, we need a website.
And a bad one, that looks goofy, and is honest, is better than a really fancy one, full of obfuscation, deception, dis-information and old-fashioned lies. (Kinda like - oh - just about most things now?)
All you may need is HTML. Yup. Mostly true. - M. Langdon, Director, Owner, Floor-cleaner, Barn-builder, Portfolio Manager GEMESYS Ltd.