>The site is also unusable on mobile, because ASCII art unlike proper semantic HTML is not easily rescalable by the browser. And it's inaccessible by users relying on screen readers, ironically because of all the ASCII cruft.

As web developers, we're used to "everyone" being the audience, but that's not the case here. As a stylized visual representation of the weather, it's fine. I dig it.

Making sure something is accessible to screen readers is generally an important thing (and could be worked on here) but I give this project a pass because the visual design is the whole point of the exercise.

And while I viewed this on mobile (and was fine for me with zooming), that clearly isn't the audience. Again, it could be improved if the author felt like it, but even if "fixed" (perhaps having morning, noon, evening, night being stacked vertically on mobile) I don't think this would be hardly anybody's goto weather reference on mobile. It's meant for us desktop users who are lovers of the terminal aesthetic.

Oh, I agree that this is really cool in terms of aesthetics.

I'm pointing out that the grandparent's comment about this being minimalistic, and comparing it to real weather apps as being absurd. If you're building a toy project aimed solely at programmers on desktop, there's a lot of things you don't have to care about. Some of those things are exactly the 'bloat' the grandparent has been complaining about.

The point wasn't necessarily this specific implementation. But the general concept of lightweight text web responses. Without several MB of JS, CSS, graphics aassets, etc.

Fair 'nuff! Thanks for the clarification. (The other stuff isn't the only source of bloat--for example, weather sites as a category feel (on average)...um...spammy (can't think of a better word) to me when it comes to quantity and presentation of ads and "suggested content"--but I get ya.)

>The site is also unusable on mobile

Not everyone wants their webpages to be seen on mobile, this one works perfectly in lynx. Does your website work in lynx?

I would go out on a limb and say yes. Any website designed with screen reader accessibility in mind would work with Lynx, which is a more capable browser than screen readers.

That's not really true: JAWS, the most popular screenreader, works with IE and Firefox.

You can have a single-page javascript app be totally accessible. You could also have an ASCII art app that renders perfectly in lynx be totally inaccessible to a screen reader.

FYI: It scaled perfectly fine on my Android/Galaxy S5 so while it's scalable, I can't comment on how "easily scalable" it is nor if screen readers would have a problem.

I would think screen readers would have no impact. Text is pretty much text (utf8, etc...) and the scaling is handled by your font choice not your text choice.

^^shrug^^

ASCII art is not scalable when you mix it with text like on this site since scaling the art will also make the text unreadably small.

Screen readers depends on the semantics as defined in HTML to recognize what to read. In this case when you use text to define the 'layout' of the page, screen readers loses the ability to differentiate between content and presentation. This is also one of the reasons why using tables for layout is a bad idea.

On iOS the page scales as expected. The only visual glitch with columns not matching up is something I'm getting on non-zoomed desktop as well. Presumably this is from specific source text of as-of-yet unexpected lengths not being handled properly during calculation of the maximum columns.

The accessibility issue would be resolved by using workarounds typical of screen-reader solutions: ARIA markup, tricks like Bootstrap's .sr-only class, etc. At the end of the day, neither images nor ASCII art are going to be accessible, so if you implement the required accessibility functionality, theoretically there is no difference between them. I do shudder to imagine just how ugly the source would look (hide every character of the nonsensical ascii from screen reader, and replace it with proper text representation).

On Android the browser renders the page at full width, making the icon and text unreadablely small. You can zoom in, but that shouldn't be necessary in the first place if the site was responsive.

Bootstrap's screens reader only classes are somewhat of a hack, and does the opposite of what you're suggesting anyway (aria-hidden is the proper way to go, but as you said that will mean adding a ridiculous amount of markup to the page), while images support screen readers natively via the alt attribute - no messy markup needed.

As noted, you can fetch the page via curl. Takes just over a second total.

Contrast ~6 - 60 for a typical web page these days (and yes, Firefox appears to be part of the problem, but I'm willing to trade a lot of speed for utility).

The inaccessible comment is somewhat ironic. If the display of the ASCII craft is in a terminal at least I have some control over the font size and, in particular, the background colour.

Sorry, I meant cruft - autocorrect didn't recognize the word and corrected it to 'craft'.

And the same control extends to users on the Web at the very least. Userstyles/scripts and extensions can modify websites, giving users the ultimate control over website content.

My point was in response to the grandparent's statement that most modern apps get in the way of the user - those exact same things are also crucial to, for instance support screen readers and mobile users.

> in particular, the background colour

I use this on my computers at work. Its wego and the ONE frustrating thing is you can't change the colors so that they work well with a light background.

Could you not wrap it all in a div and do something like:

    #ascii-art {
        font-size: 2vw;
        overflow: hidden;
        white-space: nowrap; }