_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI This Website Has No Class
shermantanktop wrote 5 min ago:
> Also, just look at that markup. So clean. So shiny.
Thatâs the essence of so much of this obsessive bit-twiddling:
irrelevant aesthetics. The functional aspect of this is a disaster, as
others have noted, locking styling to page structure in a way that will
require structural changes to the CSS just to move an element on the
page.
cluckindan wrote 43 min ago:
This makes me confident that BEM-like classes are still the best
approach for large and complex sites, as long as the
.block__element--modifier pattern is followed, so there are no
.block__element__secondelement type classes, and things like nesting,
descendant selectors and :has() are avoided where possible.
Using custom tags invariably leads to the aforementioned, and browsers
need to do extra DOM traversal to target styles properly. Not so with
BEM: a flat list of class selectors maps cleanly to elements, so when
the browser is parsing HTML to DOM, it doesnât need to wait for all
descendants to be parsed (for :has() to work) or do extra checks to
determine whether its current path in the DOM matches a nested or
descendant selector. It can just keep on parsing and rendering.
This may not feel like it makes a difference if youâre browsing the
web on a veritable supercomputer, but for anyone on an older device,
the difference will be between instant and kinda sluggish.
alberth wrote 51 min ago:
I think the better framing is: "eliminate/reduce the number of DIVs".
Because the real problem I see is that the generic DIV is grossly
overused, when built-in HTML elements already exist for exactly the use
case intended.
I rarely see HEADER, FOOTER, NAV, even P because people just use the
generic DIV tag instead.
URI [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/El...
AmazingTurtle wrote 1 hour 14 min ago:
Checks query selectors
> document.querySelectorAll('*[class]');
tons of elements with class
Theodores wrote 1 hour 14 min ago:
This is what I like to see, however, I think that more can be done with
the document structure.
I use a section element to enclose a heading with the paragraphs that
immediately follow it, thereby scoping text to a heading.
The advantage to this approach is that you 'gain a class' (okay a
section) that can be used for styling.
I am not keen on adding my own make-believe elements, however, I have
found that, if you know your HTML elements, you can write surprisingly
human readable HTML.
There is no need to be fundamentalist with going 'classless', classes
are the way to go for situations such as when an element changes.
I also take heed of the HTML5 spec and the advice regarding the use of
'div'. There really is always a better element to use, and, with 'divs'
removed, it is trivial to layout any content with CSS grid.
Scoped CSS is also a game changer, however, you have to pretend Firefox
does not exist, which is fine by me for my hobby site. Scoped CSS means
that you can keep the CSS simple without bizarre selectors that the
next developer will not like.
It all depends on what you are trying to create. If you were to want to
do your own version of Gmail then you are in a world of complexity.
However, blogs, ecommerce and much else does not need to be a complex
mess with a 10000 line 'add to' CSS burden.
esher wrote 1 hour 15 min ago:
My sympathies! I developed a small CSS frameworks many moons ago [1].
It provided basic styling for elements directly and used the cascading
part of CSS a lot. I see the benefits of utility classes and how it
fits to web components. [1] -
URI [1]: https://medium.com/teutonic-css/retiring-my-own-little-css-fra...
gethly wrote 1 hour 21 min ago:
One way to look at this from programming points of view is
interfaces(class) vs objects(id). Tying everything to specific object
means refactoring becomes impossible. Whilst also relying solely in on
interfaces means you might have too loose of a logic for anything
meaningful.
donatj wrote 1 hour 22 min ago:
I did a lot of front end work from about 2000-2015, but I've fallen
into almost entirely backend professionally. That said, I still enjoy
it and try to keep up. I have a side project SPA I developed using a
css pattern I'm calling "apps"
Basically I have JS "controllers". Every controller type gets a root
HTML element. They pick the element type, these root elements
automatically get a css class ala "{controller}--app"
Then from within each of these controllers I largely only use
un-classed HTML - and style almost entirely based on direct ancestor
">" operators. Something like
.sidebar--app {
> ul > li > a {
// style sidebar
}
}
I generally keep the scope of what is a "controller" pretty small, a
few elements deep maximum. It's a sort of hierarchical mvc and
controllers have controllers have controllers, so for instance my
sidebar controller has a search controller. The search controller just
manages its own elements and reports changes via events. This pattern
has kept the JS and CSS very clean and understandable, and the
generated HTML pristine.
I've been hacking on this for close to a decade, it's a fun little side
project. It's pretty large in scope yet it's honestly been a delight to
work on. The styling of everything is quite scoped so there's very
little unexpected problems. The actual HTML is readable and pleasant.
Martin_Silenus wrote 1 hour 24 min ago:
Funny thing is that it could really have no class.
blenderob wrote 1 hour 58 min ago:
Has the author bothered to view source their own website? If I search
for class= on their view source, I see 175 matches!
hennell wrote 1 hour 35 min ago:
Had you bothered to read all the way to the bottom you'd see that is
mentioned. Delete the nodes and the class= search fails.
jbreckmckye wrote 2 hours 10 min ago:
We tried this 20 years ago with "CSS zen" and the Bad Old Days of
"semantic CSS". It failed because you cannot completely couple HTML
structure and presentation.
Usually you have more complex styles and visuals than your HTML can
express and trying to invent selectors / HTML heirarchies to describe
them gets difficult very quickly
In addition you often need to support multiple style systems on a
single web application whilst the design evolves, or else it becomes an
all or nothing rollout when you change stuff.
It's common for engineers who weren't around back then to look at the
abstractions that modern FE systems provide, and question if they're
even necessary. That's healthy. What's not healthy is assuming they
were only invented for fake or historical reasons, and telling everyone
to just abandon them for commercial projects.
robin_reala wrote 1 hour 33 min ago:
20 years ago CSS didnât have the power it does now. There was no
:has, :where, subgrid, and a whole bunch of other tools that let us
effectively decouple structure from styling. Times have now changed,
and itâs worth evaluating whether there are opportunities to roll
back some of the changes we were previously forced to make.
donatj wrote 1 hour 49 min ago:
You've got the horse before the cart, and completely misunderstand
Semantic CSS.
The styling should simply serve to improve the content. The content
should generally stand on its own without any styling.
In semantic CSS the goal is to write your HTML with as little regard
to presentation as possible. Your HTML is simply structuring human
readable data. At this step you give it no thought of appearance.
Styling that structured data comes second. You write the CSS to make
the structured data look nice, and ideally do not touch the HTML in
the process, at all. The styling is but an affectation.
This fell out of favor because people cared more about looking flashy
than quality content, they didn't want to put any thought into
developing the actual page and wanted to start with the design. It's
a symptom of the overall disease of the modern web.
This is more achievable with modern CSS than ever before and I pray
for it to make a comeback.
munchler wrote 1 hour 13 min ago:
Note for carriage owners: âHorse before the cartâ is actually
the correct order.
wpm wrote 1 hour 32 min ago:
I don't do a ton of web development but I occasionally need a
little webview or form, and this is exactly how I write them.
That's how I was taught, you know, progressive enhancement. I
didn't even know there was any other way lol
bgarbiak wrote 2 hours 24 min ago:
I tried this approach years ago. Now I consider it an anti-pattern. You
really donât want the look of your website/document to be dependent
on its structure. Things like li:has( > a + p) - it seems so clever
initially, but then you need to have a button instead of an a, or an
icon, or a wrapper over entire thing; but only for a single item on the
list. You either end up with messy CSS that covers all these scenarios,
or you just go back to classes.
I kinda see a potential usefulness of custom attributes, but Iâm
still not entirely sure how theyâd be better than classes. Whatâs
the advantage of [shape-type="1"] over .shape-type-1?
taeric wrote 22 min ago:
I'm curious why you don't think the look should be dependent on the
structure? I can agree that some structure dependence would be a bit
restrictive, but most structural items in the browser are
specifically for how things should look?
I think the confession at the end of the article is correct, that
this asks a ton of the authors of sites. But the article is also
correct that accessibility is much better for this style than it is
for competing ideas. Just compare to the div heavy style that is
common in places like substack.
butlike wrote 13 min ago:
Because a can be either a horizontal nav bar or a vertical list.
Without differentiating the , how would you style it?
vharuck wrote 7 min ago:
At the risk of pedantically answering just this one example, wrap
the nav bar list in a element:
URI [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Refere...
webstrand wrote 14 min ago:
The problem is that, in the current state of CSS, it's a two way
binding: The styles are dependent on structure to make the look,
and the structure is dependent on styles to make the look. Often
times you wind up needing to add a wrapper div, either to give a
root for selectors or to provide some CSS context like stacking,
containers, perspective, etc. And when you add that container
class, your classes that are structural often all break in
difficult to debug ways.
I used to follow CSS zen, now I'm more of a "put a class on every
element describing its purpose semantically". Then, when I need to
change the structure of some component, adding a wrapper, changing
an element type a -> button, etc, most of my styles keep working
just fine. I'm not a fan of Tailwind, my method is more like BEM or
Atomic CSS but with less naming-convention-rigour.
I should mention that most of my work is in building interactive
components. You might be able to make the case for structural css
for more flow-like content. But even then, when designers start
asking for full-bleed elements in flow, you have to start breaking
structural semantics and tying the two together.
wpm wrote 1 hour 34 min ago:
It probably depends on the context you're applying the pattern to.
This post is a blog site. Each article is a static document, unlikely
to have considerably odd or exceptional structure as a general rule.
Like, the page has one "button". Probably works really great here.
grebc wrote 1 hour 49 min ago:
Each page can easily have its own relevant inline styles for
different layouts/composition.
Implemented it this way with static generators and web apps before
very easily.
Not to mention it is so stupidly quick.
clan wrote 2 hours 6 min ago:
Is there no middle ground?
I love the clean approach with classless. Documents do have a
structure and is makes it easy to change by just swapping out the CSS
without touching the document.
But could you not just add the class only when you really really need
to break the structure? The middle ground for me would to do my
utmost to avoid classes within reason. So as few exceptions as
possible. I know this is selling elastic bands by the meter.
On the other end you have Tailwind CSS. I know many are happy with it
and find it has a nice developer velocity. But I find it overly
verbose and "framework of the day"-ish.
So for me it is classless until my head hurts. Then I'll sprinkle in
a class to get work done.
ysavir wrote 1 hour 10 min ago:
It depends a lot on the rate of change of the document.
Documents that experience little change don't need classes because
their structure is reliable.
Documents that change often have unreliable structures, and will
require frequent updates to the CSS rules to match structure
changes. Using classes insulates the CSS from the document
structure, mitigating the need to update CSS as the document
evolves.
It also depend your development strategy. If using Vue components
and writing the CSS in the same file as a dedicated, small-scoped
components, it's practical to update the CSS references alongside
the document changes. But when there's distance between the HTML
and the CSS, or there are components in use who's structures may
change unpredictably (such as from 3rd party libraries), classes
provide a safer reference.
There's no need to have an ideology of using classes or not using
classes. The practical approach is to assess the nature of your
work, the rate of change of the documents, and to adopt practices
built around those assessments.
coneonthefloor wrote 2 hours 54 min ago:
I really like the concept of this. I'd love a html reference guide
(pattern library?) with plain html no CSS or JS to document the basic
building blocks of the web.
edent wrote 2 hours 54 min ago:
I love this - and I applied the lessons to my own site. It was
fascinating to see just how often I'd slapped a class on something
which was never going to be re-used.
Similarly, WordPress spams tonnes of classes everywhere. Most are
unused.
So I took a look at rewriting my CSS to target by logical structure,
rather than just random names dotted about. It mostly worked well,
although it did mean that I occasionally had to write a selector like:
`li[itemtype="Comment"] > article > div[itemprop="author"] {}`
701mk wrote 3 hours 12 min ago:
That's why I like using PicoCSS on small projects, it instantly adds
style without much classes needed.
CafeRacer wrote 3 hours 31 min ago:
Great job!
But, I'm sticking to tailiwnd :D
chamomeal wrote 3 hours 38 min ago:
The dark option is definitely the most readable but wow those other
themes on this site are super nice looking!!
xandrius wrote 3 hours 58 min ago:
So even almost classless websites can be laggy websites.
chamomeal wrote 3 hours 40 min ago:
It was super snappy for me. The snappiness actually stood out. In us
east
xandrius wrote 2 hours 23 min ago:
In the EU on Firefox mobile and was weirdly slow.
Alifatisk wrote 26 min ago:
It was snappy for me, also in EU on Firefox mobile
jrrv wrote 4 hours 0 min ago:
:%s/;/:
admissionsguy wrote 5 hours 8 min ago:
I can only see ~half of each line on my phone and cannot scroll, so
whatever they are doing, they are doing it badly.
paganel wrote 4 hours 49 min ago:
Also, can't seem to be able to select text, for one reason or
another.
defanor wrote 3 hours 13 min ago:
I can see whole lines and select the text in a desktop Firefox, but
the fonts are messed up (thinned and otherwise tweaked) and colors
are set to reduce the contrast, making it hard to read. As with
most of the design-related articles, I had to use the reader mode
to actually read it. But the content can be guessed from the title
(with a hint that it is about CSS) anyway: they have simply removed
CSS class selectors, replacing them with element selectors, adding
combinator selectors, pseudo-class selectors, and so on.
singularity2001 wrote 5 hours 8 min ago:
It also has no style
the_other wrote 5 hours 24 min ago:
I like it. Nice effort. Plus I like the visual style a lot too.
I feel there's a mismatch between creating novel "semantic" elements,
and then customising them in the markup, rather than the contextual
approach (nesting, rich selectors). The mismatch is that the new
elements still apply a "what" approach, but the attributes used for
customisation apply a "how" approach and leave it in the mark-up. It's
still like `` rather than `main p { background-color: red; }`.
I get that there's a trade-off between purity and code that's nice to
work with, and I think you've hit a very readable, appealing and
creative balance.
dayvster wrote 5 hours 33 min ago:
Hah that's a cool and creative exercise.
Love the writing style as well
habibur wrote 5 hours 34 min ago:
Right click -> view source.
Found "
elaus wrote 3 hours 10 min ago:
Yeah, that title is absurd. The page contains 175 "class=..."
attributes.
grebc wrote 1 hour 47 min ago:
Itâs mentioned in the article that code highlights still use
classes.
progbits wrote 4 hours 41 min ago:
I think that's fair. It's not semantic information (I mean in a way I
guess it is, but you wouldn't want a screen reader to present it as
such), so classes are fine there.
xandrius wrote 3 hours 59 min ago:
It says no class though.
thiago_fm wrote 5 hours 42 min ago:
I love the design of his blog -- the use of dots, link highlights etc.
It also brings back memory of 2000s internet, but merged into Today's
design standards. I assume this was intentional.
Martin_Silenus wrote 1 hour 26 min ago:
Its link hovering effect is probably the worst I've seen for a long
time, not to mention the fact that it just makes it unreadable.
Iv wrote 5 hours 42 min ago:
Well, HTML was supposed to be a generic language to describe typical
documents. Most websites don't need more than the default elements.
From an outside perspective, it is perplexing to see the constant back
and forth webdevs do between making website more complex and
rediscovering the simpler first principles
zwnow wrote 5 hours 14 min ago:
I am sorry but its not the devs who want complexity. Users and
Designers want a snappy interactive UI with lots of animations to get
the "vibe" right. Devs are usually fine with websites looking like
they are straight out of 2003 (considering all the language doc pages
I've seen)
von_lohengramm wrote 1 hour 44 min ago:
>Users ... want a snappy interactive UI with lots of animations to
get the "vibe" right
[citation needed]
zelphirkalt wrote 3 hours 40 min ago:
That depends very much on the type of developer.
Personally, I would first try to get the semantic structure of HTML
right for the content I want to display. Then I would look at what
I can do in CSS to make it look nice, but without going full
overboard. Stick to things that are now standard in browsers, and
that are responsive and resize and float nicely. Perhaps, if
necessary even something like the checkbox hack, but probably try
to avoid it, since it is a hack. Then the site already looks
sufficiently good usually. At no point in this comes JavaScript
into play, because this is about visuals, and that should be
handled by HTML and CSS. I will use JS, when I have something
dynamically changing and/or interactive on a page, and I will try
to make a noscript alternative, perhaps usable by the user simply
reloading the page.
However, I have also seen a lot of frontend devs, who just throw JS
framework at everything and since everything is JS anyway, they
also do things that could be simple HTML and CSS using JS instead.
The result are those pages, where one is greeted by a blank white
page, when not running JS.
So there definitely are a lot of devs, mostly frontend devs, that
do this kinda thing, and it often secures their job by introducing
complexity under the guise of looking fancy.
Example from a previous job: Making buttons that have 2 corners cut
off, but the main navigation bugs regarding responsiveness, that
led to broken layout took 3 months to fix. Transferring a
navigation from one project to another? 3 weeks.
zwnow wrote 3 hours 10 min ago:
Frameworks are a lot simpler than building with vanilla html, css
and js. At least that's my experience... Requires a lot less
boilerplate too.
Regarding the noscript alternative solution. I do not know a
single modern website relying on users refreshing the page to
update content. Except for HN maybe. This approach is very very
outdated and will frustrate users.
philote wrote 1 hour 56 min ago:
It depends, the frameworks I've seen require a ton of
boilerplate (ie. the things tools like create-react-app sets up
for you) and have quite a learning curve. Using what you
already know is simpler, and some of us know vanilla html, css,
and js. It also very much depends on what you're making. Many
sites don't necessarily need much interactivity or to
constantly receive updated data.
zelphirkalt wrote 2 hours 53 min ago:
The refresh page thing is, as I explained, a fallback for
users, who don't want to run or cannot run JS. 99% or more of
the users will never see this. I personally would be grateful,
if web devs took precautions and paid attention to also having
a no-JS workflow for things where it is relatively simple to
implement. It also has to do with accessibility. A JS-only
page, that results in a blank white page has exactly zero
accessibility.
gherkinnn wrote 5 hours 53 min ago:
I recently went down a similar path to build the FE of an app. It
worked fine at first and I learned a whole lot about recent updates to
CSS. And boy, has it come a long way. Cascade layers, nesting, and the
:has selector tripple-handedly change how views can be written for the
better.
It is a solid solution for blogs and apps with a distinct document
feel, but for anything beyond that I found it too limiting and brittle.
Back to components and Tailwind.
gherkinnn wrote 3 hours 37 min ago:
Looks like I threw myself in to a Tailwind flamewar. I should've
known better.
TW+TSX is easily the most productive way for me to write UIs and has
been for 5 years. Don't like it? Don't use it but please leave me
alone.
crazygringo wrote 2 hours 40 min ago:
> Don't like it? Don't use it but please leave me alone.
That's not how HN works. HN is for discussion. If you make a
comment, people can discuss.
If you want to be left alone, then perhaps "don't use" the comments
section.
h4ch1 wrote 4 hours 28 min ago:
I don't get this comment at all; you say CSS is too limiting but
somehow Tailwind, which is just applying CSS using classes is
liberating?
Tailwind actually complicates a lot more things, when you have to
specify variants for example, there you go installing tw-variants,
writing Javascript just so you can get different sorts of buttons.
This is fine for larger component libraries like shadcn-ui, but for
simplicity, I'd pick up pure CSS for something like button .error;
and button .secondary.
(yes I know you can just @apply whatever you want inside those
blocks, but what's the benefit of tailwind then?)
robertlagrant wrote 4 hours 21 min ago:
> you say CSS is too limiting but somehow Tailwind, which is just
applying CSS using classes is liberating
If you read the article you'll see what they're talking about. It's
not "CSS is too limiting" it's "CSS only applied to elements is too
limiting".
lawn wrote 4 hours 37 min ago:
I've never heard anyone complain that CSS is too limiting. If
anything it's the opposite.
iLoveOncall wrote 5 hours 57 min ago:
> I removed a non-trivial amount of CSS (now about ~5KB of CSS over the
wire for the entire site)
That's around 2% of the size of the single page of that article, it
absolutely is a trivial amount, especially when it complexifies so much
the maintenance or addition of the website.
philipwhiuk wrote 2 hours 19 min ago:
It'd be even more irrelevant if the site didn't do
"public,max-age=0,must-revalidate" on the CSS file.
OtherShrezzing wrote 3 hours 50 min ago:
In fairness, the page loads two enormous fonts. Lots of blogs just
use system fonts, so the advice is generally useful if you're trying
to reduce your own site size. The total payload without the fonts are
around 12kb, so reducing the CSS to 5kb is a fairly big deal. Without
the fonts, the entire site could be delivered in the first TCP
packet.
Gabrys1 wrote 5 hours 50 min ago:
The 5KB is trivial. They don't mention how much was actually removed.
Maybe 200KB? Who knows
drcongo wrote 5 hours 37 min ago:
It has also vastly simplified the maintenance of the website.
DIR <- back to front page