Earlier quoted context omitted.
Can you help me understand the utility of Daisy UI? Seems like it's the good old classes+stylesheet with extra steps (tailwind)
Well, instead of writing this for every button in your web app: Button You can write this: Button The utility is pretty clear to me
I'm betting on HTML
311–320 of 458 posts
Re: I'm betting on HTML
#312I really want to believe in the semantic web, I really want to believe in the ability of the browser to provide me with good default modules with a good default styling, but for now I just have to accept this is not the case. The fact that I have to think about labeling a input (why is this not an attribute ?), not being sure if I should use it as a wrapper of as a sibling with the `for=` attribute... and this is jus…
> I have to think about labeling a input (why is this not an attribute ?) If input labels were html attributes, forms would be much less versatile. It would merge 2 visual elements into one, which would make it hard to adjust the display (think of inputs with right-aligned labels to their left, or checkboxes with labels to their right). And a "label" attribute would mean a plain text content... Seems awfully restrict…
>And a "label" attribute would mean a plain text content.
Re: I'm betting on HTML
#313Earlier quoted context omitted.
Lots of websites already present a machine friendly site to google-bot and some other spiders. I don't see why they can't offer the same to other bots and only serve the Javascript-heavy pages to humans.
The idea of maintaining two entirely different versions of the same side gives me flashbacks to the days when they sir had a separate "m." codebase for mobile. There's a reason we found better solutions there, building and maintaining the same site twice is almost never worth it.
Re: I'm betting on HTML
#314I don't want to totally neg on web dev. But it does suck donkey balls. I've been doing it for years. From writing raw html,to using scripting langs, frameworks and what not. And the amount of time it takes to do not a lot I figure is just a colossal brain drain. We just went on holiday, and all I wanted to do was look up places to go eat and drink, or visit for the day, and most of the sites sucked. Or were out of da…
Or because they forget to. And almost no one visit their site anyway.
Unfortunately, Facebook and Instagram took that place. Where is it, phone number, what time is it open, some pretty pictures. Done.
Re: I'm betting on HTML
#315Earlier quoted context omitted.
The idea of maintaining two entirely different versions of the same side gives me flashbacks to the days when they sir had a separate "m." codebase for mobile. There's a reason we found better solutions there, building and maintaining the same site twice is almost never worth it.
This is why you wouldn't build "two entirely different versions of the same site", you'd build one version and toggle the tag on and off.
Its really easy for this to break and go unnoticed for a while as well. You could run tests against the static version, but I wouldn't be surprised at all to see them "temporarily" disabled because a new feature needs to go live and something is the breaking in the static tests
Re: I'm betting on HTML
#316Earlier quoted context omitted.
then realized there's literally no way to tell. It's all flat. I hate that. I'm waiting for that fad to be over. I kind of liked material design, but it's too much of a pain to put into everything. Flat, borderless, and unidentified is so easy to do. The all flat approach encourages dark patterns. Lists of trackers you can opt out of, scrollable, with no scroll bar and no window border. There are important buttons hi…
The process pretty much started with Windows 8, which was released in 2012. I don't think the flat style will go away anytime soon. At most, skeuomorphic elements will be slowly phased in. Material design at least adds shadows, and "neumorphism" adds back some 3d popping out, although I haven't seen it much.
Re: I'm betting on HTML
#317Earlier quoted context omitted.
You might like this: http://youmightnotneedjs.com/
There's a scroll indicator! It tells you, by looking at a thin bar, how far down the page you are! What a novel idea! I wish browsers had this builtin so that we didn't need to implement a bar for showing the user how much of the document is left to scroll. (Seriously though, wtf did firefox make the scrollbar autohide? In order to see it the user has to interact with the page. It's worse in the debugger, where horiz…
Re: I'm betting on HTML
#318Earlier quoted context omitted.
This seems reductive to me. There's "HTML" and then there's the kind of website where the final DOM isn't known until the user has already been attempting to read it for 10 seconds. There is a substantial difference in the % of browser capabilities that need to be exercised between the extremes of use. Complexity of implementation is what ultimately separates the good from the bad. Any tool can be operated skillfully…
Lots of websites already present a machine friendly site to google-bot and some other spiders. I don't see why they can't offer the same to other bots and only serve the Javascript-heavy pages to humans.
There are a few sites I impersonate Googlebot to, they're much more usable that way.
Re: I'm betting on HTML
#319Earlier quoted context omitted.
This is why you wouldn't build "two entirely different versions of the same site", you'd build one version and toggle the tag on and off.
That may not work for a lot of sites that depend on client rendering and don't server-render the full page content Its really easy for this to break and go unnoticed for a while as well. You could run tests against the static version, but I wouldn't be surprised at all to see them "temporarily" disabled because a new feature needs to go live and something is the breaking in the static tests
Re: I'm betting on HTML
#320Earlier quoted context omitted.
> I have to think about labeling a input (why is this not an attribute ?) If input labels were html attributes, forms would be much less versatile. It would merge 2 visual elements into one, which would make it hard to adjust the display (think of inputs with right-aligned labels to their left, or checkboxes with labels to their right). And a "label" attribute would mean a plain text content... Seems awfully restrict…
I don't understand the following. Would you be kind enough to elaborate ? >And a "label" attribute would mean a plain text content.