Where is the good old… alignment with no CSS
Bring back and
You can revive with a tiny bit of css: https://www.quaxio.com/blink.html
Every HTML Element
91–100 of 136 posts
Re: Every HTML Element
#92Earlier quoted context omitted.
unlike the tag where younger people will just stare at you in a creepy extended unblinking gaze. it would be so much more satisfying if it still made them blink.
I absolutely need to write a polyfill for that.
blink {
animation: 1s ease infinite blink_effect;
}
@keyframes blink_effect {
0% {
opacity: 0;
}
50% {
opacity: 1;
}
100% {
opacity: 0;
}
}Re: Every HTML Element
#93I like this! It's fun to compare it to "A blog post with every HTML element" [1][2], which gets at a (very!) similar thing but in a very different way. This post primary shows , and is a little more chaotic (meant positively!) whereas the other post is much more prose and explanation heavy (also good, but very different). [1] https://www.patrickweaver.net/blog/a-blog-post-with-every-ht... [2] HN discussion: https://n…
Whoa! I'm a big fan of yours. You've really inspired me to think more creatively about the web/software. Thanks a ton, I'm glad this reached you.
After looking at the source for this, I have a tangential question (feel free to answer even if you aren't the OP):
Whats the advantage of creating a separate `label` element before/after the input and using `for=` compared to simply wrapping the target input in the label element, like the code snippet below?
Your Name?
Re: Every HTML Element
#94Except this custom one I just invented that I implement in my custom browser
Raises the question, how far can you get using only custom elements and css? It sometimes appears that the modern ideal is to not have an element "do" anything on it's own and depend on the css to define it's purpose. But we still have a lot of historical baggage we are carrying around.
> Raises the question, how far can you get using only custom elements and css?
I am so glad to see someone use "raises the question" correctly instead of using "begs the question" which does not mean "raise the question".
In response to your question - you'd be surprised if you have a few (3-4) webcomponents for the most common needs in front-end; things like client-side includes, etc.
In fact, with just client-side includes you get 50% of what a front-end framework gives you (ability to create reusable and standalone components).
Of course then you spend the time you won in ditching the framework to figure out ways to pierce the shadowroot so you can apply your global styles to the component :-(
Ask me how I know.
Re: Every HTML Element
#95Except this custom one I just invented that I implement in my custom browser
Too bad OP is not omniscient and capable of predicting your made up tags
> Too bad OP is not omniscient and capable of predicting your made up tags
I think a more accurate word here would be "prescient".
"Omniscient" means knowing everything, but I believe that "everything" doesn't include "everything now and in the future.
"Prescient" means knowing future events, i.e. "predicting"
(Emphasis mine)
Re: Every HTML Element
#96Most people insist on only using one element, which is the element of last resort, according to MDN. This is our friend, the . The only use case I have for is in a details/summary where there is no CSS to select the contents of a element, excluding the . Does this mean I use instead of , as a 'direct replacement'? Nope. When using CSS grid, there is no need for wrappers around everything. I do like to use the full HT…
> I do like to use the full HTML element set, and, with scoped CSS, to style the elements, rather than have loads of divs with loads of class attributes. It all looks so much neater, particularly if the unstyled CSS looks rather good.
From a discussion on HN a few days ago, I bookmarked this: https://github.com/dbohdan/classless-css
For the most common types of front-end work one needs to do, classless CSS is enough.
Re: Every HTML Element
#97Very dismissive. Anyone not using should take a second look. Of all the elements, this is the one to change font, size, color, etc. in any dynamic text without offsetting anything in your layout. Do you really want to throw your user's text inside a inside your nice layout? No.
Re: Every HTML Element
#98Very dismissive. Anyone not using should take a second look. Of all the elements, this is the one to change font, size, color, etc. in any dynamic text without offsetting anything in your layout. Do you really want to throw your user's text inside a inside your nice layout? No.
Indeed, is for inline elements what is for block elements: a way to organize and apply styling.
With raw html/js it can also be used for targeting text changes.
Re: Every HTML Element
#99Earlier quoted context omitted.
Too bad OP is not omniscient and capable of predicting your made up tags
> Too bad OP is not omniscient and capable of predicting your made up tags I think a more accurate word here would be "prescient". "Omniscient" means knowing everything, but I believe that "everything" doesn't include "everything now and in the future. "Prescient" means knowing future events, i.e. "predicting" (Emphasis mine)
That's obviously up to your definition, but omniscience as commonly understood as an attribute of the Christian God is also knowledge of future events (which is why it's usually argued that it conflicts with free will).
"The future" is part of "everything".
Re: Every HTML Element
#100>>Ah, now there's some breathing room, thanks to . That's XHTML which is XML. HTML does not use and does not need a closing slash and never has in any HTML specification. https://html.spec.whatwg.org/dev/text-level-semantics.html#t...
I hate that XHTML went away. HTML parsing is terrible