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

391–400 of 551 posts

Re: HTML First

#391

Post by chriswarbo »

andai wrote: post #86

The main thesis seems to be that the user should be able to press View Source and understand what's going on. I agree, at least for web sites . For web apps , at least anything over 50 lines, you are probably going to want to use a typed language. (Well, you could technically use .js with TypeScript compiler and type annotations in special comments but I did not find that very pleasant.) I used to be really big on th…

> In fact, I find a beauty and elegance in shipping the whole thing as a single HTML file with no dependencies (1 network request!)

This is even easier now we have 'data:' URLs. It's also useful for avoiding problems on file:// URLs, which don't even need a HTTP server.

Re: HTML First

#392

Post by andybak »

MrJohz wrote: post #301
andybak wrote: post #234

Earlier quoted context omitted.

The "big" projects can do what the hell they want. They can afford to throw a ton of money at a problem. The small projects are where the people I care about are struggling.

Are people really struggling at that level, though? It has never been easier to write a complex page with minimal Javascript - there are more and more HTML elements that do what you expect (expandos and modals as some recent examples), Javascript is cleaner and more consistent across browsers (you really don't need jQuery anymore), and CSS is more powerful but also so much simpler (flex+grid solve so many problems).…

Sounds like we're agreeing with each other and disagreeing with the big SPA framework guy?

Re: HTML First

#393

Post by docmars »

xg15 wrote: post #329
MrJohz wrote: post #286

Earlier quoted context omitted.

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 i…

At that point, you're creating and writing a different flavor of date picker -- and in static HTML land, there is no clean way to update page content dynamically based on user input, without some kind of JavaScript library interacting with those elements (talking to the UI) and coordinating input data, displaying new derived data/info based on those selections with snappy, accurate feedback.

There are hundreds of ways to support this using JavaScript because the community has cleverly come up with many different flavors of view handling to suit different mental models and preferences. What could be better?

Re: HTML First

#394

Post by docmars »

fiddlerwoaroof wrote: post #324
RoddaWallPro wrote: post #275

Earlier quoted context omitted.

"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”

Why not do both? Gmail's a great example of this. Hold shift while clicking two checkboxes in a range of emails, and watch as the entire range is selected for you to manage. :)

Re: HTML First

#395

Post by bensecure »

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…

> Eg, will render as you expect because the browser will automatically close the span when you close the div. (!)

span is a bad example. indeed it will close - but then it will reopen (!) when the next text node occurs.

is a better example, and it will also auto close when you try opening a new

, which can be rather convenient when trying to write concise html.

Re: HTML First

#396

Post by resonious »

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…

I tried to push for an "HTML first" style frontend at my job, but we hired some run-of-the-mill frontend devs and they basically didn't get it and just wanted everything to be divs with VueJS controlling all of the logic and content.

One semi-objective thing we lost was accessibility. Much of the site is impossible to navigate via keyboard due to naively re-implemented behavior like links being divs with click event listeners. It's actually somewhat worrying - when regulations hit us, we'll have to scramble hard to get back what we threw out.

But all in all I kind of agree with you that it's very hard to find high profile examples of sites that are "HTML first". I believe in it, but haven't actually seen it pan out. But I suspect the reasons for it not panning out might be purely in education. By the time HTML became powerful, frontend dev education was already deeply framework-focused.

Re: HTML First

#397

Post by stanislavb »

tonyennis wrote: post #212
codeptualize wrote: post #207

Earlier quoted context omitted.

I think this is a great example of all the small details we take for granted in the tools we use, and we would miss without realising when following these tips.

That hidden CSRF field can be added without form_with though, and Rails still protects against not including it. I left it out of the example as it didn't seem relevant

Yes, it can be added, but manually going over all form. Also, how would it protect against a CSRF without the token in place?

Note: I totally agree that we should strive to go HTML first. However, this specific example is a bit unfair.

Re: HTML First

#398

Post by listenallyall »

resonious wrote: post #396
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…

I tried to push for an "HTML first" style frontend at my job, but we hired some run-of-the-mill frontend devs and they basically didn't get it and just wanted everything to be divs with VueJS controlling all of the logic and content. One semi-objective thing we lost was accessibility. Much of the site is impossible to navigate via keyboard due to naively re-implemented behavior like links being divs with click event…

> it's very hard to find high profile examples of sites that are "HTML first"

Because the tools to create it are relatively new, and the sites you're speaking of had already been written. What high-profile site didn't already have a massive legacy React/Angular/Vue codebase, and a team of framework-trained developers, as of 2021?

Re: HTML First

#399

Post by 1shooner »

couchand wrote: post #361
1shooner wrote: post #282

Earlier quoted context omitted.

A component level token would be if your `myCard` component populated all of it's styles with component-specific css-variables, e.g. "myCard-bg", "myCard-padding". It's basically defining the styling api for your component. If you have a new variant that needs to style another property, then you should probably extend your component's style api accordingly (by defining a new component token and providing the default)…

The Salesforce Lightning Design System makes extensive use of this technique; they call them "styling hooks". https://www.lightningdesignsystem.com/platforms/lightning/st...

Is Lightning primarily web components? That would make sense, since css vars penetrate the shadow dom, so with this approach there's no need to mess with loading your css into the component's shadow dom.

Re: HTML First

#400

Post by iopq »

andybak wrote: post #234
xgb84j wrote: post #160

Earlier quoted context omitted.

Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects. Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all. I personally…

The "big" projects can do what the hell they want. They can afford to throw a ton of money at a problem. The small projects are where the people I care about are struggling.

Smallest projects just throw up a bootstrap template and call it a day

something like this: https://www.hotelpalacebarcelona.com/

they don't care it's not "html first"

Post reply on HN