I think my terminal's font is breaking the v2 graphs because the unfilled braille dots aren't blank rather unfilled circles. The v3 version doesn't work as my terminal doesn't support images.

On my Windows box it actually does work surprisingly well with the official curl binary and the graph looks great but the weather emoji mess up alignment towards the end.

I think these kinds of inconsistencies are the reason something like the way brow.sh does it makes more sense, if it's not plain text the only reliable way to represent it is via colored fixed width block characters as terminal UIs have been relying on those for ages so they are more widely supported.

A font that renders the empty braille pattern with unfilled dots seems very inaccessible to the visually impaired. Empty braille pattern sections should arguably always be blank.

I don’t think rendered braille is for the visually impaired...

Everything rendered on your screen matters for the visually impaired; even braille characters, however redundant.

This is great! Does it know ahead of time if we have colors before sending the response?

No, unless it's getting info from somewhere I'm not thinking of, it has no way of knowing what terminal you're using. In principle, I think the "accept" header is the right place to put that info?

`T` or `no-terminal=True` in the querystring will disable ANSI color codes in the response.

but there's no good way for a server to tell if it's requested by a text based client, wttr.in is hard coding a list of text clients' User-Agent [0], which is not so pretty imo. If look for "Accept: text/plain" in request header, curl as the most popular client won't set it.

[0] https://github.com/chubin/wttr.in/blob/4eedafb81356e62b9f1c8...

It's not even text/plain. We need a text/ansi (is there a better name for that?)

I think something like `application/term` would probably be better for this.

Wonder if I could get this to work in rainmeter or something.

Whooooooa that is the coolest thing I've ever seen!