Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Yes, that is an issue I am looking to fix. Basically has got to do with HN markup being the ugliest thing I have seen. Tables all along with no classes and whatsoever. So targeting is a pain in the ass.

Will see if using pseudo class for first element helps me out.



sort by: page size:

Thanks. I'll think about making some elements clickable. But if some are clickable and some are not it might be even more confusing if non of the elements are clickable. So I'm not sure if it's a good idea.

I'll consider changing it to "Open in HN". It is more clear about what it does but it's also longer and maybe a bit redundant.


Adding some classes is alright. Things like "row", "column-6" are tolerated evils.

Look at the button from his article:

<a class="text-xl rounded bg-orange pt-1 pb-1 pr-4 pl-4 text-white hover:text-white no-underline leading-loose" href="#">Buy for $10</a>

That's way too granular.


After a first glimpse: multiple classes per node (or things like class=" ") are handled incorrectly and DOM hierarchy is ignored altogether (ul li ul anyone?). I wouldn't recommend this tool to anyone, sorry.

Yeah, I wanted to focus on using pseudo elements to pull content in from data-attrs but obviously I could/should have gone into more detail on the other bits and pieces. Thanks for the suggestion.

Then you dont really end up with a DSL that looks just like the one in the article, though – this is noticeably less nice :)

The best I could think off were designated initializers like:

    Div{{.class = "footer"}, B{"some text"}}
But making tags, attributes and plain text work nearly as nicely as in the lua table example seems not super straightforward to me.

Mmh, yeah. Sometimes I lack reading comprehension.

So, I would think it's not a thing that can be solved with style guidelines, maybe a different diffing paradigm that handles elements addition or deletion from a list?


You're right - this is something that I've been meaning to look in to as well, just to remove the need for more DOM elements. I also want to add offsets in.

Agreed. Most of the time, it's great and leads for a cleaner DOM. But it could cause issues. A workaround I use in my own styles is doing something like class="plain", then the table rule would be table:not(.plain).

I find it interesting that instead of using tags to target a list-item, it suggests putting a class on every li in the HTML. Seems rather bloating to the HMTL if you have a number of long lists.

Is using descendant selectors in that case bad enough to offset all those class attributes? I think I'd rather put a class on the ul or ol so that I can target the parents if needed and then can still easily target the li children.


Same here, and to be honest I'm still not sure what the clean solution would be for this level. With that particular html structure and class/id usage there maybe isn't any…

I understand but then why not .card > *:nth-child(1) and then so on down the child list? You could get away with those two selectors to match anything with at least an initial name. No decisions except for the first name.

Some editors like Brackets allows you to edit other files online and handles css specially so you can edit it just by hovering over class names, etc.


IMO you can and should still add useful class/id names to explain what your elements are doing. Those just won't have any styling associated with them.

Hmm, I use to try that kind of stuff, but it gets kind of unmanageable pretty quickly. And sometimes it just plain breaks down. For example, with the same form field example. We use the idea of `Field-label` and `Field-legend` across multiple field types. Checkboxes end up having the `Field-label` be the second child instead of the first.

Generally trying to tie it to order in the DOM just becomes very fragile, when really a classname is actually more semantic in terms of the meaning sticking with the element and being able to use it anywhere.

I think trying to separate JS hooks from CSS hooks is an anti-pattern actually. Like having `js-` prefixed classes. Because realistically you aren't changing the class names enough for it to be a problem. And if you do change the class names there's a good chance you'd want to change the `js-` prefixed one too and eliminate any benefit they were giving you in the first place.

You might be able to get it to work for simple components though. But I'd be weary since there are only so many HTML different elements, and the special pseudo-selectors can only get you so far.


Fair point. I'm planning on making those elements "tag" agnostic. That way, you can use a CSS class or a <button> instead of an <a>.

Yeah, I was initially thinking block-level elements, but just selected text should be easier.

I've thought about doing the list of smaller lists but it could cause issues with the DOM (if you care about it) since components must return a single element. Will look into that fixed data table.

Thanks, for the suggestion. We're rolling out advanced mode soon, which will allow you to edit the CSS selectors and RegEx operating on the page's HTML to define the selected data elements

Thanks for pointing this out. I should probably mention this approach in my article for cases when you need to work with slotted elements but don't want to inherit all page styles.

They also change the HTML structure. There's no selector that works well when the data, structure, class names, and IDs can change between page loads.
next

Legal | privacy