Live data from Hacker News

HTML is the Web

petelambert.com

171–180 of 341 posts

Re: HTML is the Web

#171
post #94

Earlier quoted context omitted.

Web pages that don't show anything without JS are broken. Ones that show only a message about enabling JS are worse. It seems JS;DR was already a thing long before I felt the need for it yesterday, when I simply missed that article about synths at ableton.com because it was broken. https://indieweb.org/js;dr

What about web applications? I am the office champion of accessible web, but recently we made a web based game, in canvas. Without js, there's no game engine, so we had a noscript tag. That synths article uses built in JavaScript synths (using audio apis). I agree the text should display without JavaScript but the purpose of the article (get hands on with synths) is eliminated without JS. Basically, the web not only…

If you like synths on the web, check this out.

https://learningsynths.ableton.com/

Re: HTML is the Web

#172

Earlier quoted context omitted.

I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some po…

I’ll bite: Why is it bad to put a click handler on a div? Because we’re losing the semantic content of the markup?

Because there's already an element for that. Putting a click handler on a div is a hack.

In a clean (from scratch) dev situation, when would it make sense to use the div option?

Re: HTML is the Web

#173
post #89

I recently used Semantic-UI ( http://semantic-ui.com/ ) in a project. Semantic-UI is a web framework where "semantic" means there are human readable class names like Compared to Bootstrap, Semantic-UI ships with high level "components" ("views", "modules", "collections"). And here comes the ugly: They all abuse HTML as if it was 2008. Div soup everywhere. Even lists have to be formatted as Divs, something I havent do…

Oh my! I didn't believe that code example you just gave, so I had to go look it up for myself. I'm astounded. https://semantic-ui.com/elements/list.html#list

to be somewhat/slightly fair, the very next example talks about using a `ul` for the list.

Re: HTML is the Web

#174
post #92

Earlier quoted context omitted.

Second that. For the user, flash applets where super easy to block in general and to whitelist on pages where you wanted to use that particular flash application. Basically the same was true with Java. And for a certain extend JavaScript -- until the ugly DHTML menus arised and websites stopped to be usable without JavaScript. Nowadays there are only two options: Either you block JavaScript --- and percieve a 1995's…

The 1995 view is superior. It loads fast, doesn't hog CPU, never does anything unexpected, and has limited tracking capacity. I cringe whenever I browse without NoScript. If your pages can't render in my sandbox I just go somewhere more sensible.

It's superior only until you want to do something that does actually need JS - sometimes "go somewhere more sensible" isn't an option when you actually need to do something specific (e.g. buy an Amtrak ticket).

Re: HTML is the Web

#175

Earlier quoted context omitted.

Browsers are not required to support JavaScript; in fact, HTML has a specific tag to support this case.

Yes, but the standard recommends against actually using it. > The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail. For this reason, it's generally better to avoid using noscript, and to instead design the script to change the page from being a scriptless page to a scripted page on the fly, as in the next example https://html.spec.whatwg.org…

I think it's important to note that a "scriptless page" does not literally mean "give me a blank white page unless I turn on JavaScript".

Re: HTML is the Web

#176
post #165

Earlier quoted context omitted.

For one, it won't play nice with accessibility helpers... screen readers, keyboard interaction, etc.

While I agree semantically use of can be clearer, clickable divs can still play largely fine with most accessibility technologies if ARIA attributes are used. Does it semantically make the most sense? Not necessarily, but it isn't a blocker to most accessibility tools and use and support for ARIA attributes is pretty widespread nowadays, including all of the major browsers and screen readers. > https://developers.goo…

Number of times I remember seeing an an app using `` with proper aria attributes: 0.

Re: HTML is the Web

#177
post #19
post #5

A Web page is a document. No it's not. It never was. Even a long time ago when websites were static things rendered by the browser once and then left alone there was always a tree of nodes underlying everything. The only thing that's changed in the past three decades is that now when we make websites and web apps we often ship a little JS application that lets the user modify the underlying tree. That's what the web…

The truth is both web "pages" and web "apps" are documents, and both are the web. Web pages which use javascript to render text or fetch remote content by AJAX can still be as much documents as fully static HTML pages, if their primary purpose is to convey textual or visual information. And fully static sites can be made interactive without javascript, though backend processes. Viewing "pages" and "apps" as wholly se…

> Viewing "pages" and "apps" as wholly separate and mutually hostile paradigms seems to be a recent cultural development born more out of frustration with advertising and modern complexity than any technically meaningful distinction between the two.

Well there is a pretty fundamental tension between programs written in a Turing-complete language and a program written in one that is not. Resorting to too much power too early is dangerous and messy.

Re: HTML is the Web

#178

Earlier quoted context omitted.

I once toyed with the idea of serving XHTML page as application/xhtml+xml, but the fact the browser (back then, not sure about now) will just display XHTML error and doesn't render anything was a deal breaker for me.

By "the browser" you mean "Internet Explorer". The only browser that couldn't handle XHTML.

With XHTML any syntax error completely aborts rendering, there is no fallback - the browser will display a native error page instead.

Re: HTML is the Web

#179

Unpopular opinion... but I think this is a too limited view of the web. My contrary opinion is that the actually important feature of the web is the URL, and the important feature of the browser is that it provides a sandboxed platform for running untrusted code without a builtin "walled garden moral police". It would be nice if operating systems would be exactly that, but for some reason "commercial" OS vendors are…

[deleted]

Re: HTML is the Web

#180
post #77

Earlier quoted context omitted.

I'm inclined to disagree, but I guess the real problem is that webpages on the internet are being forced to serve both purposes. Paradigm 1 - interconnected, hyperlinked web of text-and-content-based documents: open, accessible, amenable to indexing and tooling and so forth. Paradigm 2 - delivery vehicle for cross-platform, full-featured, somewhat-security-sandboxed, applications. I agree with the article that it's s…

I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some po…

Nothing about React stops you from correctly putting click handlers on buttons.
Post reply on HN