Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unreasonable effectiveness of simple HTML

shkspr.mobi

Post reply on HN
Print view View original

101–110 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#101

Post by chrismorgan »

dgb23 wrote: post #93
lovelyviking wrote: post #73

Those are not ‘crappy browsers’. If we call it “Browser” it should be browser, isn’t it? It should brows pages. It was never intended to be overweighted virtal machine and not a good one by the way. Past 8 years or so Youtube has nothing really more to offer then it was offering back then. The only new things it offers for me is overweighted dumb slow shit that fails to perform what it was perfectly doing 8 years ago…

> It was never intended to be overweighted virtal machine and not a good one by the way. Citation needed. It's been two and a half decades since people started using the web as more than just a delivery mechanism for text and images.

As an example of this, forms were in the HTML 2 spec of 1995, and you’ll recognise every last part of it as still working exactly the same way: https://www.w3.org/MarkUp/html-spec/html-spec_8.html. ( has fallen into disuse and is rare and generally discouraged, but all the rest is still universally used.)

Re: The unreasonable effectiveness of simple HTML

#102

Post by chrismorgan »

forgotmypw17 wrote: post #69

I,ve been working on a hyper-compatible web forum system. With some tweaking, I,ve been able to achieve compatibility with Netscape 2.x, IE 3.x, Mosaic 1.x, Opera 3.x, and everything since then, not to mention Lynx, Links, w3m, etc. I still have some advanced JS stuff, but it,s behind feature checks. 25+ years of various client compatibility, for people with older devices and retro fans. Amazing tech we should not th…

Pity that you must expose everyone’s passwords in plain text to achieve this (those older browsers won’t support TLS).

Re: The unreasonable effectiveness of simple HTML

#103

Post by ogre_codes »

reificator wrote: post #92
ogre_codes wrote: post #10

This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unu…

While I agree with your message of "make things accessible" I think you're pointing the finger the wrong way. > This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. > The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can functi…

> Using a div as a button is not "bog-standard" HTML or a "standard component". Use a button and be done with it.

Fully agree. In fact that is exactly point I was trying to make.

Re: The unreasonable effectiveness of simple HTML

#104

Post by stan_rogers »

mschaef wrote: post #33
zelphirkalt wrote: post #7

Earlier quoted context omitted.

I think this is an exclusionary mindset. Just because it is a tiny subset of users, it is OK to exclude them? How about when it is quite easy in many cases to support them, by using standard conform simple HTML? Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? In fact, just today I have seen it, on a VPN login, on a thing, that is suppos…

> Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? ... They don't know the noscript tag or something? This is often less about the developers not knowing a technique and more about the constraints they're working under. Maybe there's a third party auth library they're using that requires JS. Maybe either they or or their management have…

That doesn't explain the lack of a noscript message, which is the difference between "we really need you to turn on javascript" and "as you can plainly see, our page is broken".

Re: The unreasonable effectiveness of simple HTML

#105

Post by ogre_codes »

K0nserv wrote: post #83
ogre_codes wrote: post #54

Earlier quoted context omitted.

I suspect a lot has to do with the fact that it's easier to slap together a quick list/ menu thing than it is to make a select box look the way a designer wants it to. Similarly with calendar components, radio buttons, etc.

What has happened in that scenario is that the designer has failed in their job. Unfortunately it’s up to engineers to catch this, which they often don’t

Designers don't really know or understand the limits of how you can style a select box. Nor should they need to. A good team will work together around the limits.

Also, FWIW some of the problem is with the browser makers (still!!). CSS still has a lot of browser specific quirks when working with some components.

Re: The unreasonable effectiveness of simple HTML

#106

Post by ogre_codes »

jcranmer wrote: post #67
bachmeier wrote: post #43

Earlier quoted context omitted.

Unless there's a law I haven't heard of (definitely a possibility) it would be necessary to classify it as a commerce site for the law to apply.

Taking a quick look at the site, Beyoncé has a store page on it, which would be sufficient to classify it.

With regards to the ADA, commerce means more than just "Selling stuff" so I'd be careful making assumptions about that.

Re: The unreasonable effectiveness of simple HTML

#107

Post by nicbou »

apabepa wrote: post #19

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more…

In the end, I just end up using Firefox' reader mode, because what I really want is the main article. Everything else is noise.

Re: The unreasonable effectiveness of simple HTML

#108

Post by codazoda »

ogre_codes wrote: post #10

This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unu…

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.

I created a minimalist CSS framework called Neat CSS (https://neat.joeldare.com). I use anchors instead of buttons and explain why in the quote below. I'd love feedback on the accessibility of that alternative.

It's best to use semantic web tags whenever possible. Buttons are a unique case where you're typically linking somewhere, but the button tag doesn't currently support the href attribute. So, buttons are anchor tags with a class of button.

Re: The unreasonable effectiveness of simple HTML

#109

Post by unicornporn »

jcranmer wrote: post #27
recursive wrote: post #21

Earlier quoted context omitted.

> Making your site accessible isn't just a good practice, in the US, it is the law. Courts have rules that the ADA applies to web sites along with any other type of business. This seems to imply that web sites are businesses. If my hobby sites are subject to this, I'm going to be in trouble.

If you're not selling anything, then you're not engaged in commerce and you wouldn't qualify as a "public accommodation" and the law doesn't kick in for you. (Complete list of public accommodation is 24 USC §12181(7)-- https://www.law.cornell.edu/uscode/text/42/12181 ).

...and you'd be OK in the EU too.

https://ec.europa.eu/digital-single-market/en/web-accessibil...

Re: The unreasonable effectiveness of simple HTML

#110

Post by chrismorgan »

simias wrote: post #96
iforgotpassword wrote: post #40

Earlier quoted context omitted.

For YouTube I kind of still see a point, if only to not make scraping videos dead simple by not just having the plain URL of the video file in the html (yes there are still tools out there). But twitter is so ducking ridiculous in that regard. At its core it is a web site to share 280 character long strings, but as of recently you cannot do this anymore without JavaScript! They shut down the legacy page at the end of…

I would argue that the fact that video content is often so frustrating to scrape is symptomatic of the massive cultural shift the web has seen over the past decade or two. In the "old" web you could basically right-click -> save anything you want (ignoring plugin blobs for the sake of making my point more compelling). Meanwhile I tried manually scrapping a video from reddit the other day, I succeeded but it was quite…

Firefox exposes this stuff just fine: its context menu on videos has “View Video”, “Copy Video Location” and “Save Video As…”. (I thought that Chrome did too, but maybe my memory is faulty or maybe they removed it at some point.)

But sites can easily prevent all of this stuff from happening by putting something transparent on top of the video, so that you’re not actually right clicking on the video, but on another element.

And here’s the thing—there’s a sound technical reason why they all do that, and it’s not just legal nonsense. Those operations only make sense if you’re playing one video file, but as you remark, there are all the various qualities available, and all of these platforms are designed to be able to switch seamlessly between sources, so that the browser never does get told “play this single video file, it’s the whole thing”, but rather “here, play this (1080p) chunk”, then “here, now this (144p) chunk”, then “and now this 360p”—with the JavaScript monitoring everything and trying to make it flow as smoothly as possible at each step.

So… no, your browser actually doesn’t know about all of this, and that’s the reason that YouTube and the likes have stopped it from exposing it even in browsers that are otherwise willing to.

(You could still easily say that there’s a culture shift in this: in the distant past, the web valued simplicity and openness at the cost of performance and effectiveness; but as the internet went more and more mainstream, more and more developers broke ranks and insisted on unbreaking things for their users and improving performance and effectiveness, even at the cost of openness and simplicity.)

Post reply on HN