Live data from Hacker News

HTML is the Web

petelambert.com

141–150 of 341 posts

Re: HTML is the Web

#141
post #53

Earlier quoted context omitted.

> What's the use of "installing" an application these days? Once I "install" an application, for example libreoffice: - It works even if I do not have a working Internet connection (or back in the day, even if I had removed the original media from the drive); - It works even if the original is gone. That is, by "installing" an application, I gain a permanent, offline, working copy of it.

Most of this isn't a given anymore with software vendors going subscription-only like Adobe's Creative Cloud. On the other hand, PWAs (Progressive Web Apps) also work in offline mode without a "traditional" installation step.

Not even Steam works like that.

Stay offline for 30 days (iirc) and try to play the games you paid for.

Re: HTML is the Web

#142
post #46
post #29

Earlier quoted context omitted.

This is grossly underestimating the complexity of IG, FB and the likes. Everyone likes to tell other people how they should build their stuff, that's the easy part. Do you think React would have been created if "HTML and a little Javascript for interactivity" was enough for Facebook to deliver the UX they wanted to? No, there was a business need, and what existed simply wasn't good enough, maintainable enough or easy…

No, its not for the UX, but for tracking you in every way as precise as possible. Second, most of you is not Facebook or Google either and have no need for additional complexity. Third, a strategy some of the big companies do to slow down startups that may compete with them is to create an illusion of how fantastic it is to develop applications with this new tool. So instead of focusing on actual business value, a lo…

> No, its not for the UX, but for tracking you in every way as precise as possible.

Source? I realize this is HN and FUD about Google/Facebook is just accepted as truth, but this is a little too FUD-y for me.

Re: HTML is the Web

#143
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…

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?

Re: HTML is the Web

#144
post #70

Earlier quoted context omitted.

The real question is why should links in an email message be clickable? Restricting email messages to plain text would make it much more difficult for attacks like that to succeed.

... and make emails completely useless.

Ever head of copy & paste?

Won’t make them “useless”, maybe inconvenient for non-security minded individuals.

Re: HTML is the Web

#145
post #137

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…

The reason browsers use the document as a building block is to provide a consistent and accessible UI to everyone using your site. This is the exact same thing that Windows, Apple, Android, etc do with their UI frameworks that they recommend you use. It also provides the ability for websites to safely degrade on older browsers because unknown elements can still be rendered in the correct hierarchy. Now in both cases,…

Platforms should provide the necessary low-level APIs to hook into their accessibility- etc... features without having to use their high-level UI frameworks, and they should provide lower-level services like high-quality text rendering.

Mostly this already works, I can open a standard file dialog, or copy data into or out of the system-wide clipboard. If there are any APIs for accessibility missing (e.g. for hooking into screen-readers), I would consider that a bug on that particular platform. There's no reason that applications which use the system UIs should behave any different from applications using custom UIs.

Re: HTML is the Web

#146
post #3

I pretty much agree with all the article. Back in 2001, when Web Standards were on the rise, people used to validate their HTML code. It was shown as a badge of prestige when you had 0 errors. Semantic HTML was a hot topic and most of the developers I worked with were a sort of HTML taliban. But the popularity of frameworks helped developers forget the basics and concentrate more on learning how to get the most out o…

All my webpages had the valid xhtml badge! https://commons.wikimedia.org/wiki/File:Valid_XHTML_1.0.svg I still have a hard time un-learning ` `

I currently serve real XHTML5 code on my website with the correct media type of application/xhtml+xml. https://www.nayuki.io/

This works properly in all modern browsers (Chrome, Firefox, Safari, Edge; PC, Mac, Android, iOS) and even Internet Explorer 11. Though in the past, I had to make concessions for older versions of IE, serving the same code as text/html instead.

I arranged things this way because I hand-write much of the HTML code on the site, and want to catch syntax errors as early as possible without the browser silently (and possibly incorrectly) fixing my mistakes. In any case, this is living proof that XHTML5 works.

Re: HTML is the Web

#147
post #78

Earlier quoted context omitted.

All my webpages had the valid xhtml badge! https://commons.wikimedia.org/wiki/File:Valid_XHTML_1.0.svg I still have a hard time un-learning ` `

Opening can of worms: did you serve them with any of the available XML MIME types? If not they worked simply because of the bug in the browsers (SHORTTAG means a different thing in HTML compared to XML) and all XHTML code served with HTML MIME type would be littered with ">" if browser treated it right ;)

br is an empty element (https://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Stric...), so
should work fine

Re: HTML is the Web

#148
post #137

Earlier quoted context omitted.

The reason browsers use the document as a building block is to provide a consistent and accessible UI to everyone using your site. This is the exact same thing that Windows, Apple, Android, etc do with their UI frameworks that they recommend you use. It also provides the ability for websites to safely degrade on older browsers because unknown elements can still be rendered in the correct hierarchy. Now in both cases,…

Platforms should provide the necessary low-level APIs to hook into their accessibility- etc... features without having to use their high-level UI frameworks, and they should provide lower-level services like high-quality text rendering. Mostly this already works, I can open a standard file dialog, or copy data into or out of the system-wide clipboard. If there are any APIs for accessibility missing (e.g. for hooking…

There are ARIA attributes which let you customize the advertised meaning/intent of an element, but there is nothing to, say, mark that a particular location on the page should be considered a button. As far as I'm aware, this matches how Android, Windows, iOS, etc work.

There are so many parts that go into the accessibility of an element, handling tab index, handling keyboard input, handling screenreaders, spoken voice prompting, etc, that a custom solution usually ends up being detrimental to the user's experience.

Re: HTML is the Web

#149
post #72

Earlier quoted context omitted.

> very few sites in the grand scheme of things were solely rendered with Flash ...yeah, because that's not what Flash was about. Flash was an application platform (ok, so more like an Animation platform) first and foremost. Why would anyone run their whole site in flash? It wasn't the right tool for that job.

> Flash was an application platform (ok, so more like an Animation platform) first and foremost. Why would anyone run their whole site in flash? It wasn't the right tool for that job. And this is exactly what I'm trying to say. Back in the day you would very likely reach for Flash if you wanted to build an FTP client that ran in a browser. Totally reasonable use case because that's a highly interactive app that doesn…

but most sites had some flash on their site. just like the previous person said: flash was never intended to replace the website entirely - flash was intended to supplement it. and that need went away with html5/css3, which is why it was deprecated as the insecure behemoth it was.

Re: HTML is the Web

#150

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…

I don't think that is an unpopular opinion, since I am of the same. I agree with you that the URL is the most important feature of the web. Without it, you could just as well deploy native apps because it wouldn't really make that much of a difference. Without javascript and a heavy client side, I wouldn't have a job today since the application I build is simply not possible to create with just html+css. Sure there a…

What we need, in my opinion, is a new protocol. Leave http(s) for documents and make a new protocol designed from the ground up for interactive applications. That solves the problem of trying to shove an application into a document viewing sub-system and should allow for more creativity and efficiency, depending on what this new protocol turns out to be.

What's happening now is like trying to force ftp to show documents, with markup, and forms, and so forth when it's just supposed to transfer data.

Post reply on HN