Hacker News new | past | comments | ask | show | jobs | submit | redmaniack's comments login

Thank you :)


Well, english is my second language.

Besides that, what I was really trying to say was that a tool like Normalize.css or Bootstrap's Reboot may be more helpful than the classic CSS reset.


Well, I also somehow expected this kind of feedback too.

I agree my findings are far far away from a specialized audit, but nor did I intended to do one.

I just wanted to check out some of the best practices & stuff, based on my daily experience as a web user and developer.


Please read my comment above, also here's how the above "nesting" compiles to:

.compose-form .compose-form__modifiers .compose-form__upload-description input::placeholder { opacity: 1; }


Who need easy to read post-build selectors in the age of source maps? Much better to have a file that is easier to read before the build.


I did.

    .compose-form .compose-form__modifiers .compose-form__upload-description input::placeholder { opacity: 1; } 
That looks like BEM, with all the underscores and modifiers.

Proper nested SASS would look like:

    .compose-form .upload-description input::placeholder { opacity: 1; } 
Scoped CSS would look like:

    .compose-form-abc123 .however-deep-or-shallow-you-want { opacity: 1; }


I'm not saying using BEM is a bad thing. Not at all, I'm using it too and like how it plays with Sass/scss.

e.g. I do like how Sass makes it easier to write BEM-like code similar to the below:

// style.scss .btn { ... &--success { ... . } }

// style.css .btn {...} .btn-success {...}

But when abusing Sass nesting and choosing a weak naming convention, the resulted CSS selectors can go wild. Here's an example: https://github.com/tootsuite/mastodon/blob/995f8b389a66ab76e...


Is output verbosity a problem? Narrower selectors are easier to reason about and faster to process, and compression should take care of most of the size difference, since it's so repetitive.


Glad you found it interesting. I enjoy to dig into this kind of analysis stuff from time to time:

A while ago I made an HTML study on around 8 million web pages: https://www.advancedwebranking.com/html/

Also, I wrote about this journey on CSS-Tricks: 1. https://css-tricks.com/average-web-page-data-analyzing-8-mil... 2. https://css-tricks.com/random-interesting-facts-htmlsvg-usag...

On accessibility, I'd have loved to try out some screen readers but at the moment I write this article, I thought this accessibility analysis would deserve its own separate topic/article. A11Y is always hard.

https://catalin.red/thoughts-on-accessibility/

Sorry for all these plugs.


The plugs are cool, thanks! :)

The 8 million webpage one was really interesting. I don't know why yet though. (I'm serious - I know this info will come in hand for figuring something out one day. Thanks.)

TIL about [aria-hidden] from "HTML/SVG usage"/"Hiding DOM elements"! I wonder what the raw stats on display:none vs visibility:hidden are (especially considering that they have different effects). I wouldn't have expected 117000 webpages (is this a discrete page count or a website count?!) to use the highly specific ".visuallyhidden"... oh it's part of the HTML5Boilerplate framework, that explains it.

The main issue with screen readers is that, AFAIK, JAWS doesn't offer a developer-access program! Or if it does, I've never heard of it. A LOT of people still use JAWS, AFAIK, in spite of the newer offerings out there. The main difficulty here is the differing-client-behavior problem, although NVDA and ChromeVox's free-ness are surely shifting the usage share (something I've wondered about for a while).


To be honest, I blame myself for not opening some pull requests yet, considering the project is open-source.

I'd love to contribute and try to improve things but this task might become gigantic on long-term, as the Mastodon project itself :)


Came here to tell you this :)

A blog post is nice and educational, but pull requests would move things forward way better!


Thank you very much ;)


The thumbs down was meant to be for the use of an icon font nowadays, in this case, FontAwesome. Don't get me wrong, I'm still using FontAwesome for many projects.

The thing is there are so many good reasons to use an SVG icon font system nowadays: pure vector, control over the individual shape symbols, positioning is easier thanks to knowing its exact size etc.


I just tried out Mastodon quickly after reading this, and what a disaster.

Icons are overused, there's no onboarding of the UI and it just throws you in with a bunch of icons, I wasn't sure what most of them did.

I started at mastodon.technology and it immediately follows the instance creator which confused me, when I checked his profile there was an icon with which I could unfollow(an X on top of a person icon), which I didn't know if it meant blocking or unfollowing.

No icon has helper text on hover or anything, you're just thrown in and there's already messages popping in your timeline and I didn't really know that I already followed these people, and I could click Local/Federated timeline and there wasn't much info on what those were.


Those UX issues would be far more useful being reported on GitHub than they are on HN.


That assumes GP's primary motivation is to support/improve the particular project, rather than discuss UX and kvetch with fellow hackers and designers.


I understand and agree with you. It's just that this is exactly what is possible with newer versions of FontAwesome. So it has in a way replaced itself by the tools you were looking for :)

It's just nitpicking; with the example it's pretty clear that it's the icon font that is bugging you.


Hehe, just let me know!


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: