The Web Design & Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›360 »

Leshy: Jun 21, 2004

The Merkinman posted:

If you set the height to something smaller, so that the list doesn't fit in one column --height: 400px ... it does weird stuff.

With the current lists in the CodePen, it looks as expected down until about a minimum height of 260px, where the number of columns starts exceeding the width of the container. Changing the explicit width on the lists to flex: 0 1 166.67px will alleviate it a little bit by allowing the lists to shrink as needed, but again you will hit a lower limit at some point.

In the end, the lists are individual items that will not break into multiple columns, and when you have more lists or longer lists than the container can handle, you will have issues. If you also want the individual list items to wrap into new columns, you would have to put all list entries and headers into a single list � that would allow flexbox to automatically wrap them correctly, but you would lose the individual list semantics. This is pretty similar to what your suggested JS-based solution would do, by evaluating each individual list item and placing it manually.

This exercise shows why fixed sizes are generally not recommended in webdesign, especially when dealing with variable content. The moment you end up with an unexpected amount of content, things will break in one way or another and you're going to have to set up a bunch of contingencies to deal with those. Having said that, I do not know what your specific use case is here.

# ? Feb 12, 2024 21:45

Adbot: ADBOT LOVES YOU

# ? Apr 20, 2024 01:15

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Leshy posted:

With the current lists in the CodePen, it looks as expected down until about a minimum height of 260px, where the number of columns starts exceeding the width of the container. Changing the explicit width on the lists to flex: 0 1 166.67px will alleviate it a little bit by allowing the lists to shrink as needed, but again you will hit a lower limit at some point.

In the end, the lists are individual items that will not break into multiple columns, and when you have more lists or longer lists than the container can handle, you will have issues. If you also want the individual list items to wrap into new columns, you would have to put all list entries and headers into a single list � that would allow flexbox to automatically wrap them correctly, but you would lose the individual list semantics. This is pretty similar to what your suggested JS-based solution would do, by evaluating each individual list item and placing it manually.

This exercise shows why fixed sizes are generally not recommended in webdesign, especially when dealing with variable content. The moment you end up with an unexpected amount of content, things will break in one way or another and you're going to have to set up a bunch of contingencies to deal with those. Having said that, I do not know what your specific use case is here.

Oh wow. I just noticed something which would explain some of my confusion. Looks like that works in Chrome, but not Firefox (what I was doing dev in) nor Safari.
In the latter two, while it does flow onto multiple columns, the width of #lists stays the width of only one column.

# ? Feb 12, 2024 22:34

Leshy: Jun 21, 2004

Ah, you're right. On Firefox (and presumably Safari) the auto setting on the Grid container does not play nice with the actual width of the flexbox it contains.

Setting it to fit-content should work: https://codepen.io/LeshyNL/pen/BabqMKr

# ? Feb 13, 2024 22:56

Ihmemies: Oct 6, 2012

We implemented a billing system as a server side rendered single page app, with typescript, tailwind, node.js, handlebars, htmx and postgres.

Oh boy this sucks. Pg plugin to node.js just ditches the type information, and nothing actually cares about the types during runtime. So we found out our numbers in interfaces are actually strings after a database query etc.

My blood pressure can't take more of that. I want to try a different style of footgun - would SeaORM and some rust framework like Actix or Rocket work for web development, as an actually typesafe alternative? :v:

I really can't deal with these scripting languages anymore.

https://github.com/SeaQL/sea-orm
https://keats.github.io/tera/docs/
https://actix.rs

Ihmemies fucked around with this message at 08:07 on Mar 25, 2024

# ? Mar 25, 2024 08:01

MrMoo: Sep 14, 2000

Drizzle ORM is the main one that comes up in search results, although it�s a bit tedious that yet again another layer wants to be the single source of truth for domain models.

https://orm.drizzle.team/docs/zod

# ? Mar 25, 2024 14:58

prom candy: Dec 16, 2005; Only I may dance

You're basically not gonna get database-to-client typesafety without using an ORM or query builder that wants to define your schema. Drizzle is very cool. Similarly there's Jet for Golang, but I haven't used that.

# ? Mar 25, 2024 18:49

abraham linksys: Sep 6, 2010

if you just want runtime type-safety with no ORM, you can hand-write zod schemas for the expected query results, and this brings up typescript to parity with, like, every other typed language where the types exist at runtime. there's some libraries that'll integrate this like slonik (https://github.com/gajus/slonik).

MrMoo posted:

Drizzle ORM is the main one that comes up in search results, although it�s a bit tedious that yet again another layer wants to be the single source of truth for domain models.

https://orm.drizzle.team/docs/zod

if you're using an ORM like drizzle you probably don't need any extra runtime validation? it already has its own schema DSL that i assume would enforce stuff at runtime

if you want actual end-to-end type safety when interacting with a database that is a huge can of worms in any language and can be a pit of a pain in the rear end to get set up (e.g. my java-heavy employer eventually gave up on JOOQ's DSL for being way too hard to work with and is still keeping on with JDBI). stuff like prisma exists but whoof that is some heavyweight stuff

abraham linksys fucked around with this message at 19:07 on Mar 25, 2024

# ? Mar 25, 2024 19:04

Sab669: Sep 24, 2009

Is there a better place to ask Dumb Angular Questions?

I have some function which uploads a file to my .NET API and either refreshes the page if the file is valid, or presents a list of errors if the file is invalid. For the latter, the C# code is just a simple:

return StatusCode(500, listOfErrors<T>);

My Angular function is basically just:

code:

foo(){
  this.uploadService.upload(file).subscribe(
  next: success => {
    //refresh the page
  },
  error: err => {
    //present the list of errors
  }
  ;)
}

upload(file: Blob): Observable<string>
{
  //creatiion of some objects
  return this.http.post<string>(apiUrl, formData, HeaderObject).pipe(catchError(this.handleError<string>('File Upload')));
}

But despite the API returning a 500 error, the code still steps into the "next" block. I feel like I've gotta be missing something absolutely stupid but I cannot seem to figure it out today :sigh:

Any ideas?

Sab669 fucked around with this message at 21:10 on Mar 25, 2024

# ? Mar 25, 2024 21:01

prom candy: Dec 16, 2005; Only I may dance

abraham linksys posted:

if you just want runtime type-safety with no ORM, you can hand-write zod schemas for the expected query results, and this brings up typescript to parity with, like, every other typed language where the types exist at runtime. there's some libraries that'll integrate this like slonik (https://github.com/gajus/slonik).

if you're using an ORM like drizzle you probably don't need any extra runtime validation? it already has its own schema DSL that i assume would enforce stuff at runtime

if you want actual end-to-end type safety when interacting with a database that is a huge can of worms in any language and can be a pit of a pain in the rear end to get set up (e.g. my java-heavy employer eventually gave up on JOOQ's DSL for being way too hard to work with and is still keeping on with JDBI). stuff like prisma exists but whoof that is some heavyweight stuff

adding runtime costs with something like zod is only really worthwhile if data is coming from sources outside your control imo. what you consider "outside your control" is entirely subjective though, i.e. i use zod to parse response shape for APIs that i control

# ? Mar 25, 2024 21:03

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

Sab669 posted:

Is there a better place to ask Dumb Angular Questions?

I have some function which uploads a file to my .NET API and either refreshes the page if the file is valid, or presents a list of errors if the file is invalid. For the latter, the C# code is just a simple:

return StatusCode(500, listOfErrors);

My Angular function is basically just:
code:
foo(){
  this.uploadService.upload(file).subscribe(
  next: success => {
    //refresh the page
  },
  error: err => {
    //present the list of errors
  }
  ;)
}

upload(file: Blob): Observable<string>
{
  //creatiion of some objects
  return this.http.post<string>(apiUrl, formData, HeaderObject).pipe(catchError(this.handleError<string>('File Upload')));
}
But despite the API returning a 500 error, the code still steps into the "next" block. I feel like I've gotta be missing something absolutely stupid but I cannot seem to figure it out today Any ideas?

i don't know angular at all, but my guess would be either catchError or this.handleError is swallowing the exception and instead returning a value that doesn't trigger the error block to run

# ? Mar 25, 2024 21:10

Sab669: Sep 24, 2009

Ugh, yea, honestly this place seems to decorate drat near all of their functions with that so tbh I thought it was just boilerplate Angular stuff (I still consider myself quite new to it) but digging into it, clearly not - if I just delete that whole .pipe(...) now it works exactly as it should :downs:

Thanks lol.

# ? Mar 25, 2024 21:16

SirViver: Oct 22, 2008

Sab669 posted:

...

Just a sidenote, I think a 400 Bad Request status code would be more appropriate for input validation errors than a 500 Internal Server Error.

Personally I'd only let the API's global unhandled exception handler return a 500. Any error condition you actively check for as part of your business rules should use whatever HTTP status code is most befitting of the situation - which is most likely one of the 400-range, like the ever elusive 418 I'm a teapot. But joking aside, realistically it's most likely a 400, 403, or 404.

Of course, technically it doesn't make a difference, as long as it's a status code that gets correctly interpreted as an error code by your HTTP client.

# ? Mar 25, 2024 23:18

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

422 might also be correct keeping in mind that nobody cares about any status code. As opposed to 400 Bad Request, 422 Unpossessable Entity says that while the request was interpreted and understood the server still isn't going to process the request due to something about the content of the request. Like yeah you gave me a cat name, but the cat name was too short so try again.

I guess 400 Bad Request is more like the whole request is fubar. But I've definitely seen it used more.

# ? Mar 26, 2024 00:10

Sab669: Sep 24, 2009

Yea you're probably right that 500 doesn't make the most sense. Was very much just a, "Copying the way these other endpoints do it" internally consistent jobs.

# ? Mar 26, 2024 00:59

FISHMANPET: Mar 3, 2007; Sweet 'N Sour
Can't
Melt
Steel Beams

The specific codes don't matter, but a good rule of thumb is "4xx is the user's fault, 5xx is the server's fault" lots of tooling will operate on those assumptions.

# ? Mar 26, 2024 01:08

prom candy: Dec 16, 2005; Only I may dance

The codes do matter and I think we should argue about them. 422 for invalid input, fight me.

# ? Mar 26, 2024 06:28

FISHMANPET: Mar 3, 2007; Sweet 'N Sour
Can't
Melt
Steel Beams

I'M A TEAPOT

# ? Mar 26, 2024 15:26

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

Is there a way I can tell vite, when it's in serving mode, to not mess around with loose CSS files? I have two of them with basic formatting instructions for Paged.js.

In dev mode everything works fine, because they're in the public dir marked folder. When I build everything, the file layout also looks as its supposed to be. But when I want to test said output by using vite serve, while it serves the CSS correctly, if it's the first thing I attempt to load in the browser (by addressing it directly from the address bar), as soon as the app runs, vite starts serving it wrapped in some Javascript HMR boilerplate stuff from what it looks like. So Paged.js kind of ignores it with what not being CSS anymore.

I will eventually attempt to see what happens if I override the @page attribute on the DOM node, but the feeding a CSS file to Paged.js has so far worked smoother, because I've had already to do enough horrible things for in-place rendering of print previews in this SPA.

# ? Mar 28, 2024 19:39

Ytlaya: Nov 13, 2005

We have a (POST) form with target="_blank" on our website to get the results to open in a new window/tab, but apparently this doesn't work in the Orion web browser (it does work in other major browsers). It seemingly just submits the form with no inputs. Are there any alternatives to this (or possibly a setting in the Orion browser that could cause it)?

My boss is insistent that the "open in a new tab/window by default" behavior remain, and understandably so. It's an analysis website, and the page in question is one where you can run a variety of analysis tools on editable data, so users don't want to have to keep hitting back, or manually telling it to open in a new tab.

The only possibly explanation for this I could find was something related to "XHTML Strict" not allowing target="_blank" but I don't know if that's the actual reason.

# ? Apr 19, 2024 16:44

Ytlaya: Nov 13, 2005

Ytlaya posted:

We have a (POST) form with target="_blank" on our website to get the results to open in a new window/tab, but apparently this doesn't work in the Orion web browser (it does work in other major browsers). It seemingly just submits the form with no inputs. Are there any alternatives to this (or possibly a setting in the Orion browser that could cause it)?

My boss is insistent that the "open in a new tab/window by default" behavior remain, and understandably so. It's an analysis website, and the page in question is one where you can run a variety of analysis tools on editable data, so users don't want to have to keep hitting back, or manually telling it to open in a new tab.

The only possible explanation for this I could find was something related to "XHTML Strict" not allowing target="_blank" but I don't know if that's the actual reason.

# ? Apr 19, 2024 16:45

Rawrbomb: Mar 11, 2011; rawrrrrr

Ytlaya posted:

We have a (POST) form with target="_blank" on our website to get the results to open in a new window/tab, but apparently this doesn't work in the Orion web browser (it does work in other major browsers). It seemingly just submits the form with no inputs. Are there any alternatives to this (or possibly a setting in the Orion browser that could cause it)?

My boss is insistent that the "open in a new tab/window by default" behavior remain, and understandably so. It's an analysis website, and the page in question is one where you can run a variety of analysis tools on editable data, so users don't want to have to keep hitting back, or manually telling it to open in a new tab.

The only possibly explanation for this I could find was something related to "XHTML Strict" not allowing target="_blank" but I don't know if that's the actual reason.

Have you tried filing a bug report? I dont see anything on their tracker. But, how are you serving the page itself? Are you serving it with a strict doc-type? I'd question who is using this browser by any % of your userbase that you should be spending time on solving this problem.

# ? Apr 19, 2024 17:41

CarForumPoster: Jun 26, 2013; â¡POWERâ¡

Ytlaya posted:

We have a (POST) form with target="_blank" on our website to get the results to open in a new window/tab, but apparently this doesn't work in the Orion web browser (it does work in other major browsers). It seemingly just submits the form with no inputs. Are there any alternatives to this (or possibly a setting in the Orion browser that could cause it)?

My boss is insistent that the "open in a new tab/window by default" behavior remain, and understandably so. It's an analysis website, and the page in question is one where you can run a variety of analysis tools on editable data, so users don't want to have to keep hitting back, or manually telling it to open in a new tab.

The only possibly explanation for this I could find was something related to "XHTML Strict" not allowing target="_blank" but I don't know if that's the actual reason.

Throw up an error message if the user agent is the orion browser telling them to use a different browser. Orions market share is what? 0.01%?

# ? Apr 19, 2024 18:05

Rawrbomb: Mar 11, 2011; rawrrrrr

CarForumPoster posted:

Throw up an error message if the user agent is the orion browser telling them to use a different browser. Orions market share is what? 0.01%?

There are a number of 0's missing from their share %. https://radar.cloudflare.com/reports/browser-market-share-2023-q2

Valvaldi is 0.001 and I've heard of them, and they're not limited to a specific OS.

I wholeheartedly agree with your statement. Why are you fixing this obscure browser, unless some significant % of your userbase is actively using it?

# ? Apr 19, 2024 18:38

CarForumPoster: Jun 26, 2013; â¡POWERâ¡

Relatedly, Compliance says we need to make sure that all pages for our blog support every country's laws so we must support North Korea's proprietary browser, NorK Juche. They say I need to add a little happy dancing peasant who doesnt look gaunt and has plenty of food to every page.

# ? Apr 19, 2024 18:54

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

just throwing out ideas but maybe you could save the response to a database somewhere and instead open in a new tab a page with the response ID, which the newly opened page will query and display the databased-saved results

or maybe tokenize the payload that's being sent in the url and untokenize it in the new tab and make the request.

idk man

# ? Apr 19, 2024 19:10

Last Chance: Dec 31, 2004

What the hell is the Orion browser about? Never heard of it

# ? Apr 19, 2024 20:39

CarForumPoster: Jun 26, 2013; â¡POWERâ¡

Last Chance posted:

What the hell is the Orion browser about? Never heard of it

Not new tabs, apparently.

Looking it up it looks like a privacy focused browser for apple nerds. The tech greybeard maker of the browser also makes a search engine that you have to sign up to use. Very promising projects my dude.

# ? Apr 19, 2024 20:46

Clark Nova: Jul 18, 2004

Last Chance posted:

What the hell is the Orion browser about? Never heard of it

Kagi (paid web search company) makes it. I thought it was just supposed to be a version of Safari that can run uBlock but a surprising number of things were weird and broken when I hosed around with it for fifteen minutes a couple of months ago :shrug:

# ? Apr 19, 2024 20:48

Adbot: ADBOT LOVES YOU

# ? Apr 20, 2024 01:15

N.Z.'s Champion: Jun 8, 2003; Yam Slacker

Ytlaya posted:

We have a (POST) form with target="_blank" on our website to get the results to open in a new window/tab, but apparently this doesn't work in the Orion web browser (it does work in other major browsers). It seemingly just submits the form with no inputs. Are there any alternatives to this (or possibly a setting in the Orion browser that could cause it)?

My boss is insistent that the "open in a new tab/window by default" behavior remain, and understandably so. It's an analysis website, and the page in question is one where you can run a variety of analysis tools on editable data, so users don't want to have to keep hitting back, or manually telling it to open in a new tab.

The only possibly explanation for this I could find was something related to "XHTML Strict" not allowing target="_blank" but I don't know if that's the actual reason.

sounds like an overzealous popup blocker (ad blocker). Orion have some docs about configuring their ad blocker. Maybe you could detect Orion and tell users how to fix it.

i really wouldn't want to support more than that, but if you must then I guess you could try a JS equivalent onsubmit= ... window.open(...); or if your postdata can be serialized as url params use a GET instead; or the hackiest thing I can think of is changing the submit button to be a link styled like a button whose href is dynamically updated with your form data so that the user just clicks on a link with target=_blank which ad blockers usually don't have a problem with

N.Z.'s Champion fucked around with this message at 22:37 on Apr 19, 2024

# ? Apr 19, 2024 22:34

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›360 »