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

321–330 of 551 posts

Re: HTML First

#321

Post by zlg_codes »

josephg wrote: post #316
zlg_codes wrote: post #292

Earlier quoted context omitted.

I'm adding context to this because you're only telling part of the story: self-closing tags are necessary for void elements in XML and XHTML, both technologies that are still supported on the Web. Since XHTML processes HTML as XML, it forces it to be well-formed. Unlike HTML, which has all sorts of tag-soup and quirks modes and other things, because it's lax in its syntax. Void elements lacking the need for a closing…

You can view HTML as a weird, quirky version of XHTML if you want. But XHTML lost the war. Browsers are HTML5 engines, not XHTML engines. And if you're writing HTML, the browser considers to just be a weird way to write . The slash is non-significant. So confusingly is not equivalent to . The problem I have with self-closing tags is that I've met so many web developers throughout my career who think that browsers und…

I can't disagree with making sure you're using them when they matter and avoiding them when they don't.

There was no real 'war', XHTML 5 is still a thing. Browsers are HTML engines because people who write HTML don't want to be forced into well-formed markup. They want the browser to guess what they meant and run with it.

There's also the whole "we need to be compatible with almost every HTML file dating back to the early 90s" conundrum that makes clean breaks in behavior, like XHTML, hard to pull off without pissing people off.

It should be clear which one is writing based on the DOCTYPE element. IIRC XHTML still requires a DTD to ensure its schema can be validated, while HTML 5 did away with it altogether and now just uses

Re: HTML First

#323

Post by wheresmycraisin »

codeptualize wrote: post #89

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I…

> This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference.

Not everything has be a Large Enterprise Application.

Re: HTML First

#324

Post by fiddlerwoaroof »

RoddaWallPro wrote: post #275
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…

"shift/control-clicking to get multiple things is a flat no-go from a UX perspective" - Do you mean that this is NOT how you should do multiselects? If that is what you mean, then how _do_ you do them? If I have a list of items and I want to select 10 or 15 of them in a row, I currently don't know of a better UI to do that with than shift+click.

Yeah, shift/control-click is a longstanding workflow for multiselect and macOS, Linux and windows all support it with various platform-specific subtleties. The worst part of the web is losing all these sorts of features because some web designer thinks they’re a “bad UX”

Re: HTML First

#325

Post by codeptualize »

zlg_codes wrote: post #304
codeptualize wrote: post #244

Earlier quoted context omitted.

So pelican and hugo are not frameworks? How is a static site generator any different from statically exporting next.js/nuxt.js or similar? I've used all the things mentioned, and I quite like the ergonomics of frameworks for static websites. Added benefit is that I can make static sites dynamic if necessary. And to be clear, these static exports are incredibly fast and performant. > you could roll your own SSG in a w…

I can't speak for Hugo but no, Pelican is not a framework. It's a static site generator. I cannot make general purpose, dynamic websites with Pelican. I can fake a few things, I can hook it up to cron to mimic it, but Pelican itself is concerned primarily with your data store, your theme, and generating static files to upload directly to your webspace. Sure, you can make plugins for Pelican to make it generate things…

And it's totally fine if it works you, I'm not saying one is better, I'm saying both are valid choices and if you statically export from a framework, it's not that different from what you describe.

> Frameworks force the dev into specific ways of doing things

Not really. Take Next.js, you can also use markdown (or more dynamic flavors of markdown like MDX/markdoc), you can use a headless cms, it doesn't really matter..

If you don't like Next.js you can pick a different solution, there are many! If Pelican is your jam, by all means, it's a great tool.

> I'm curious what you guys need on your sites that require so much JS.

In my day to day I work more on web apps, but lets stick to "simple" websites. 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.

Re: HTML First

#326

Post by n2d4 »

RoddaWallPro wrote: post #275
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…

"shift/control-clicking to get multiple things is a flat no-go from a UX perspective" - Do you mean that this is NOT how you should do multiselects? If that is what you mean, then how _do_ you do them? If I have a list of items and I want to select 10 or 15 of them in a row, I currently don't know of a better UI to do that with than shift+click.

Most normal users (aka if you read Hacker News, you're not one of those) don't and won't know about shift and control clicking. A more UX-friendly alternative is to have checkboxes; you can still have shift/control-clicking on top of that (for selecting many things quickly), but it shouldn't be the only option.

Re: HTML First

#327

Post by drpixie »

tabacitu wrote: post #145
codeptualize wrote: post #89

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I…

Why? Why does it need to be good for big projects in order to be good practice? I’m genuinely asking. I never understood this argument that people bring. In my view, the web is 95% small to medium projects. Most technologies should be focused on that - simple solutions for simple projectS. Add complexity later.

Anyway, a well organised big project is a collection of related small projects :)

And what's good for one small project is likely to be good for many small projects.

Re: HTML First

#328

Post by zlg_codes »

iFreilicht wrote: post #317
zlg_codes wrote: post #245

Earlier quoted context omitted.

To be fair, most UX "experts" are too busy chasing interfaces that are "inclusive", i.e. built for toddlers. Show me a powerful program with a "good" UI by modern standards and I'll show you a mess. VS Code is a prime example.

Interesting example. Why would you say VSCode is a mess? I feel like it's not in line with the current UX Zeitgeist I assume you're referring to (touch-first, wasteful whitespace, manipulative patterns, reduced functionality) at all. It provides multiple layers of access to functionality that allow the user to choose their trade-off between discoverability and speed. The UI is compact with very little padding and sho…

VS Code is a mess because there are few places I can click in the UI without triggering some weird part of the UI. Almost the entirety of the bottom bar is reactive. The sidebar has too many views to keep straight, it has an extension store or something? Using VS Code feels like handling a tool with no handle. I'm sure it has something useful but I feel overwhelmed and constrained when I use it. I can't depend on any of my prior UI exposure to effectively navigate VS Code without taking my head out of the code. It's simply too much on screen at once and relies on visual iconography which will NOT result in the same ideas conveyed between different users. VS Code feels like it's meant primarily for the enterprise, on projects that are massive and have extensive SOPs. I tried to adapt some of my development to it, just to try it, and bounced off really hard.

I'm really just more at home in Vim and a terminal window off to the side. Microsoft's way of doing things has never really clicked.

I can't speak for Fusion360 because I don't know what it is nor have I used it. There's just an issue in UIs these days where they're either toy-themed (Twitch, Discord, Etcher, other "friendly" software) or so overwhelming that you don't know where to start.

Where is the QuickStart guide for VS Code, for developers? With MS in particular, they do a poor job of reaching out to developers and actually understanding how they work or what they like. Maybe they only serve a particular type of developer; an audience that I'm simply not part of.

Re: HTML First

#329

Post by xg15 »

MrJohz wrote: post #286
c-fe wrote: post #246

Earlier quoted context omitted.

Quick thought regarding date pickers, specifically: > Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.) Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1…

I find I'm in the opposite position - I would rather the date picker is not consistent, because different date pickers have different purposes. The date picker I want to use to put in my date of birth is different to the one I want to use to add an appointment to my calendar, and that's different to the one I want to use to browse prices for different days, and that's different to the one I want to use to be able to…

What would be the specific difference between all of those?

For many use cases you described, the primary UX flow should probably not have a date picker at all, but rather the date would be selected implicitly through other user actions: i.e. to add an appointment, you might start with a full-page calendar view and click on the appropriate day; for prices you'll probably have "next day"/"previous day" buttons built into the page.

But those UX flows are orthogonal to the flows that actually do use a date picker, IMO.

Re: HTML First

#330

Post by zlg_codes »

codeptualize wrote: post #325
zlg_codes wrote: post #304

Earlier quoted context omitted.

I can't speak for Hugo but no, Pelican is not a framework. It's a static site generator. I cannot make general purpose, dynamic websites with Pelican. I can fake a few things, I can hook it up to cron to mimic it, but Pelican itself is concerned primarily with your data store, your theme, and generating static files to upload directly to your webspace. Sure, you can make plugins for Pelican to make it generate things…

And it's totally fine if it works you, I'm not saying one is better, I'm saying both are valid choices and if you statically export from a framework, it's not that different from what you describe. > Frameworks force the dev into specific ways of doing things Not really. Take Next.js, you can also use markdown (or more dynamic flavors of markdown like MDX/markdoc), you can use a headless cms, it doesn't really matter…

> 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 where units of content are presented one or a few at a time, on an infinite scroll?

When I do navigation I just build a and put s in it, programmatically if need be. Click to go where you want. Takes a full page load, but that's just how the Web works because you're going to another page. Links take you to other pages.

Is this for like an image gallery?

Post reply on HN