Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML First

html-first.com

Post reply on HN
Print view View original

471–480 of 551 posts

Re: HTML First

#471

Post by [deleted] »

zlg_codes wrote: post #468
josephg wrote: post #372

Earlier quoted context omitted.

> There was no real 'war' There was definitely a debate over how web browsers should interpret web pages - as XHTML or "quirks mode". HTML5 (with infinite backwards compatibility) was the outcome. Every major web browser implements HTML5 - complete with its super quirky and complex, but fully specified and consistent parsing rules. > XHTML 5 is still a thing. Is it though? On the web? I just tried, with this html: yo…

I'm going to let this link to a simple XHTML document speak for itself. I've configured it to work on lighttpd via the `mime-types.conf` file, and even have a commented-out meta tag you can use to fake it in cases where you can't manipulate a server. https://zlg.space/misc/example.xhtml Let me know how your browser sees it.

[deleted]

Re: HTML First

#472

Post by corethree »

ativzzz wrote: post #255
corethree wrote: post #11

React was designed to solve all these problems. Now these problems are used to solve react. Programming, like life, is a flat circle.

How poignant - another post on the front page - https://news.ycombinator.com/item?id=38236607 Top quote in the article > I don't think computing is a real field. It acts like a pop culture, it deals in fads, and it doesn't even know its own roots. And worse than that it does not know about the really good things that were done in the past. — Alan Kay

Really good quote. Pretty much sums up computing. Here's the thing, everyone doesn't realize it's just a bunch of fads. People think of it as some sort of science where we're just continuously improving and getting better.

Re: HTML First

#473

Post by zztop44 »

skydhash wrote: post #438
docmars wrote: post #402

Earlier quoted context omitted.

It's worth mentioning that the friction to deploy a web app is nearly zero these days, depending on how complex it is. As an example, shipping a macOS or iOS app, via official means, requires a lengthy review & approval process, upfront costs, buy-in into native languages with little to no use outside of these platforms, a limited selection of tools, and hard decisions about which version of the OS to support based o…

My preference is local first desktop applications. Sometimes it’s because I prefer files, sometimes it’s because native apps are more fluid and more egonomic.

What about for getting quotes on insurance? Or booking a restaurant? Or a flight or hotel? Submitting your taxes? Getting printable directions to a trailhead? Proving feedback on someone’s Figma document? Previewing a 3D model before getting it printed…

Is it your preference to install a new local first desktop application any time you wish to do any of these things?

Re: HTML First

#474

Post by brabel »

rndmize wrote: post #233

I get the idea - using the build-in capabilities of html is nice, clean, and simple. But that wasn't viable ten years ago, and it isn't today - and I don't particularly feel that htmx etc. is a better solution than something heavier like react. My go-to questions with anything like this are: how do things look if I want a dropdown? Multiselect? Datepicker? If we use do we get a datepicker across browsers? (Looks like…

> Is the look/feel/controls consistent across browsers? (No.)

And to think that having a native look-and-feel used to be considered a must for any desktop application!

I would be much happier if all websites's UI components (not the actual website design of course) had the look-and-feel native to my browser (and if browsers actually cared to make them look good, TBH) rather than inventing their own dumb styles for everything.

Re: HTML First

#475

Post by zlg_codes »

zztop44 wrote: post #307
zlg_codes wrote: post #237

Earlier quoted context omitted.

Could you expand on this? Class names in CSS are just as important, if not moreso, than naming variables in typical programming. Back in the late 90s and early 2000s, the dominant ideology is to use semantic class names, e.g. ".sidebar" instead of ".blue_bar" or similar. Essentially, don't describe how something looks with its name. Even when building JS apps, I use CSS classes semantically with ".selected" ".menubar…

The exception is when using a framework which isolates CSS at the component level, in which case your class names don’t matter anywhere near as much because you’ll only ever see them alongside the corresponding HTML.

Can't say I'm familiar with this type of webdev. How is the CSS isolated at a 'component' level? Is that not what selectors already do? I'm having trouble picturing how this is built or how it works.

Traditionally you put your template HTML or just HTML in one place, CSS in another, and JS in yet another, then tie them together via and . Are you saying there are frameworks that tie HTML and CSS together into the same unit? That is rather strange to me.

In such an environment, do people decide on no structure for their class names? I'd still want reusable CSS in such a situation.

Re: HTML First

#476

Post by zlg_codes »

codeptualize wrote: post #342
zlg_codes wrote: post #330

Earlier quoted context omitted.

> Example: Using Next.js again, out of the box it does instant navigation by preloading new content on hover, and not doing full refreshes when they aren't needed. Great for the user, less bandwidth used, much faster sites. That's just one example. I don't understand what you mean here. What content is being preloaded, what is being hovered on, why do you need only partial page loads? Is this for a doomscrolling UI w…

Could be, but also just page transitions, think a blog, documentation site, often you keep the navigation and just replace the content. If you are curious, it's quite easy to try. The results are really snappy, it's really nice. But, I'm not trying to convince you. If you are happy with Pelican and it works for you, great. All I'm pointing out is that we use these things because they do actually solve problems, often…

I'm not totally averse to trying things, I just often find myself unable to make much use of bespoke tools. It makes me feel uneasy to not have a strong grasp of what's going on under the hood of tools like that. Even Pelican bugs me with its extensible Generator and Renderer classes that still don't totally make sense to me.

There is a project I have in mind to build for a portfolio. An atlas of sorts. Is that something Next.js could make easier?

Re: HTML First

#477

Post by ndriscoll »

zlg_codes wrote: post #254
ndriscoll wrote: post #161

Earlier quoted context omitted.

Browsers have had built-in templating engines (xslt) for decades.

That's cute, now show me someone who's made something modern and usable with that tech. I used XSLT and XML to build a video game collection tracker. Just a page that could display things. It was a nightmare. I later spent a weekend building it in Python, added "export to JSON" and then made a tiny SPA with vanilla JS to do the job. It's very powerful and can do some neat things, but it's taught poorly and not easy t…

I'm not sure what you mean with it being a nightmare. It's my go-to for personal stuff. Most recently I used it to make a template for my photo albums. For personal stuff it works fantastically because it's easy to just use a simple text editor for everything with zero other tools required.

It's out of fashion these days, sure, but you could easily make e.g. a forum or a news site or a blog or a facebook type of thing. Anything where you want, well, templated html. So almost all of the web.

I know once upon a time the WoW armory was built with xml/xslt. It's convenient because then you've already also automatically got a data API; just ignore the stylesheet.

Re: HTML First

#478

Post by marcus_holmes »

Karrot_Kream wrote: post #466
marcus_holmes wrote: post #441

Earlier quoted context omitted.

I always see this as a communication/management failure. Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those. A feature that is super difficult to implement…

> The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry. But are they that wrong? We compute to, well, do things with our lives. To find out how to go places, to pay bills, to talk with friends, to meet with people, to learn about things. A view that computation should come with…

Yeah, I think so.

If building it one way will take 3 months and involve shipping 500Kb of JS to every user, whereas building it a slightly different way will take 2 weeks and ship only 50Kb of JS, then I think the second option is better, even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).

Our online lives would be a lot better if the product folks listened to the tech folks a bit more.

I like to draw a parallel to music; if the producer doesn't understand music at all, then maybe they should listen to the musicians a bit when it comes to creating a musical product.

Re: HTML First

#479

Post by chii »

MrJohz wrote: post #463
chii wrote: post #444

Earlier quoted context omitted.

if you're using react and then hand roll custom components and don't do accessibility, then it's just as bad as choosing a component framework which doesn't do accessibility. I am not talking about react (or any framework directly) specifically. > entirely on you of course - choosing a framework or hand rolling one makes no difference. It's still not production ready, if it doesn't have accessibility built in.

I think the point they're making is that you'd have the same problems with developers working HTML-first. Accessibility does not simply come for free in either situation, you need to make sure it's present. Choosing, for example, whether to use a div with a click handler, or a proper button, is a decision you need to make regardless of whether or not you're using a framework. So it seems incorrect to say that you los…

> developers who didn't understand the web platform well enough to design proper accessible controls.

And i actually think that it is _better_ for a developer not to have to do their own accessibility controls, but delegate this problem to the component framework. They have to know about the problem, but not have to spend cognitive budget thinking about it while they compose their UI from framework components - this should _automatically_ be taken care of by the design of the framework.

Re: HTML First

#480

Post by ricardobeat »

iudqnolq wrote: post #154
mattlondon wrote: post #120

Earlier quoted context omitted.

Well the point I was trying to make was to not do what the article says and name your class e.g. "green", but instead to name it something more sensible like "approved" or "updated" or something about the semantic nature of the style, rather than what the style actually is. The reasoning is that maybe today it is just "green" but then what if one day the color in the CSS is changed, and it is not actually green anymo…

The core argument for tailwind is that it won't just be "make the approved text white on blue instead of white on green". Maybe you'll get "make the approved text a bubble with a checkmark on the left and make the title two lines where the second line is ..." Frequently the change needed requires changing the html as well as the css (or maybe awkward advanced css). So you may as use a library/framework that lets you…

Exactly. Classes, even for the simplest styling tasks, have been replaced by components.
Post reply on HN