No JS, No other HTML, just CSS.
<html> and <body> accept pseudo-elements. Why add such bloat?!
Using a solid border for the cursor instead of having it in the text content is a nice touch; because it's separated out you could probably use another animation to get it blinking, too.
would you use another keyframe or did you have something else in mind
You could even remove the link tag and use the link header in the http response instead https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Li...
Nice job tho. Now just need to make it in 3D.
https://mathiasbynens.be/demo/css-without-html - completely empty html, doesn't seem to work on Mac Safari any more, does work on Firefox for me. See https://css-tricks.com/using-css-without-html/ if you want to know how it works.
https://web.archive.org/web/20160420232319/cj-johnson.github... (original copy defunct) - kinda broken now, the source is just a single <link> (if you ignore all the stuff the Wayback Machine adds)
I know there are times when you need to do something CSS can't (and shouldn't do of course. But I mean when the 'thing' is design/style only, aren't we all already using only CSS for those things? Or am I just so old I still practice the separation of concerns and no one else is.
Also, while kudos to the OP for doing this, this is exactly a time when using CSS to do this is incorrect and using vanilla Javascript IS the right decision, as this is a behavior and not a style issue.
NB4: Yes I do code sloppy when time dictates, but I still seperate my HTML, CSS, and JS as the norm, not the exception.
Yes.
There are developers who have only styled websites using bootstrap classes. (or related css-frameworks, e.g foundation, bulma, etc...)
And there are developers who have only styled websites using tailwind classes. (or other related atomic css frameworks)
Both sets of developers lose out on some very powerful css features (e.g. page layouts using css-grid, container queries, light-dom web components, etc...) that can completely change the way you build websites.
------------------------------------------------------------
Bootstrap developers tend to use bootstrap instead of css because:
- They are entry/minor level front-end developers who are still becoming proficient with css. They tend to use only bootstrap at the beginning, then progressively use it less as their own knowledge improves.
- They aren't front-end developers and are using bootstrap as a crutch to get a front-end out for the system they are building
- They are older front-end developers who have been disincentivized to improve their skills. They have become stuck in a local maxima trap because they're relying on bootstrap to fill a knowledge hole, for example: How to code a responsive design (i.e. bootstrap classes -X> media queries -> reflowing rule based layouts -> container queries), how to build an accessible navigation, how/when to use js to build an interactive component, etc...
- An easy way to spot these kinds of developers is to see if they are:
1. using the BEM class naming scheme because they're coding a div soup instead of using fewer html elements and modern css selectors
2. using a js library to make something when a few lines of css will do the trick
------------------------------------------------------------
Tailwind developers tend to use tailwind because:
- They're using react, which doesn't have a good builtin way to keep component related styles close to the component itself. In css parlance, they don't know how to scope those styles to the component. They only know how to:
1. Put styles in a separate file like in regular page based websites. This method almost always fails because developers will change a style in an external file without realising that it affects more than one component, and they don't have sufficient visual-regression/snapshot testing to catch it.
2. Inline styles to each html element which turns the component into style soup. So they settle on tailwind to make class soup as a shorthand for the style soup. Instead they should be using a framework solution that scopes the css to the component (e.g. vue's `<style scoped>`) or scope the css to the component using web standards, or declare their styles in-component and yse their build system's asset bucketing system to dedupe the declarations.
Tailwind doesn't "miss out" on any of these css features.
https://tailwindcss.com/docs/grid-template-columns
https://tailwindcss.com/blog/tailwindcss-v3-2
"Light-DOM web components" aren't a CSS feature... and they certainly aren't one that tailwind prevents you from using.
I have an extension that adds a div to the page, Grammalecte, its breaks this website a bit. A div:first-child, or an id would fix it.
A reminder that extensions can affect HTML content and you need to target your elements in CSS in a robust way.
It's one broad class of problem really: many frameworks make changing the HTML they generate difficult or impossible. Inevitably you end up needing to inject a button or a hyperlinked image or something in a particular position, and you have to resort to Javascript to do something that isn't interactive and isn't a program, which feels like the wrong tool.
You could argue that both Javascript and CSS are the wrong tool for this use case, but CSS would be the more convenient wrong tool.
I love it!
Link: <//website.css>; REL=stylesheetedit: nevermind, that's a dead URL. But anyways, it's an extra http request you don't need.
I wonder if you could do this with no <div> using just the <link> tag.
Or do browsers add an implicit body tag if you don't put one that you can style?
What next? Single letter applications?
Conveniently abbreviates to SPA.
No, the link tag is there.
@keyframes typewriter {
00.0% { content: "A" }
00.4% { content: "A " }
00.8% { content: "A W" }
01.2% { content: "A We" }
01.6% { content: "A Web" }
02.0% { content: "A Webs" }
02.4% { content: "A Websi" }
02.8% { content: "A Websit" }
03.2% { content: "A Website" }
13.2% { content: "A Website," }
13.6% { content: "A Website, " }
14.0% { content: "A Website, i" }
14.4% { content: "A Website, in" }
14.8% { content: "A Website, in " }
15.2% { content: "A Website, in P" }
15.6% { content: "A Website, in Pu" }
16.0% { content: "A Website, in Pur" }
16.4% { content: "A Website, in Pure" }
16.8% { content: "A Website, in Pure " }
17.2% { content: "A Website, in Pure C" }
17.6% { content: "A Website, in Pure CS" }
18.0% { content: "A Website, in Pure CSS" }
22.2% { content: "A Website, in Pure CSS." }
}div::after { font-family: var(--secondary-font); font-size: 1em; user-select: all; content: " \A \ This website contains one <div> only. \A \ No JavaScript. \A \ The rest is pure CSS. \A \ \A \ The <div> is animated with CSS keyframes, \A \ styled with CSS variables, \A \ styled with CSS transitions, \A \ styled with CSS pseudo-elements, \A \ styled with CSS pseudo-classes. \A \ But that's it. \A \ "; }
am I not seeing something else?
I guess not all people are in the same boat though, and I suppose it is quite cool how much can be done with CSS these days! (not that you would necessarily want to).
But it's cool to see what's possible, mostly because learning how to overcome these challenges to use a tool in a way it shouldn't be used often requires you to learn more about how the tool works. That the tool is ill-suited is the point.
Of course, not that there isn't value in you pointing out that CSS content isn't accessible :) -- I have seen developers get tripped up by that in production settings particularly when building things like hover labels, so a reminder is always appreciated.
Browser bug? Seems like it's debatable although the spec leans in the direction of generated content being selectable: https://stackoverflow.com/questions/24385171/is-it-possible-...
https://lighthouse-metrics.com/lighthouse/checks/38f2276c-bc...
lol,