Live data from Hacker News

Ask HN: Abandoned/dead projects you think died before their time and why?

news.ycombinator.com

421–430 of 912 posts

Re: Ask HN: Abandoned/dead projects you think died before their time and why?

#422
post #365

Earlier quoted context omitted.

Nice list. Some thoughts: - I think without the move to NeXT, even if Jobs had come back to Apple, they would never have been able to get to the iPhone. iOS was - and still is - a unix-like OS, using unix-like philosophy, and I think that philosophy allowed them to build something game-changing compared to the SOTA in mobile OS technology at the time. So much so, Android follows suit. It doesn't have a command line,…

On XHTML, I think there was room for both HTML and a proper XHTML that barks on errors. If you're a human typing HTML or using a language where you build your HTML by concatenation like early PHP, sure it makes sense to allow loosey goosey HTML but if you're using any sort of simple DOM builder which should preclude you from the possibility of outputting invalid HTML, strict XHTML makes a lot more sense. Honestly I'm…

> Honestly I'm disappointed the promised XHTML5 never materialized along side HTML5. I guess it just lost steam.

The HTML Standard supports two syntaxes, HTML and XML. All browsers support XML syntax just fine—always have, and probably always will. Serve your file as application/xhtml+xml, and go ham.

Re: Ask HN: Abandoned/dead projects you think died before their time and why?

#423

Earlier quoted context omitted.

Google sucked/s at executive function because they completely lack appreciation for proper R&D and long-term investment and also kill things people use and love.

Honestly a lot of the time they seem to be be in "what do humans want?" mode.

Yep. And rather than ask people, focus group, or look at the evidence, they just guess or do whatever they want. Not much leadership or community engagement appears to be involved.

Re: Ask HN: Abandoned/dead projects you think died before their time and why?

#424

Earlier quoted context omitted.

> Would it kill people to have to close their tags properly? Probably not, but what would be the benefit of having more pages fail to render? If xhtml had been coupled with some cool features which only worked in xhtml mode, it might have become successful, but on its own it does not provide much value.

> but what would be the benefit of having more pages fail to render? I think those benefits are quite similar to having more programs failing to run (due to static and strong typing, other static analysis, and/or elimination of undefined behavior, for instance), or more data failing to be read (due to integrity checks and simply strict parsing): as a user, you get documents closer to valid ones (at least in the rough…

HTML5 was the answer for the consistency part: where before browsers did different things to recover from "invalid" HTML, HTML5 standardizes it because it doesn't care about valid/invalid as much, it just describes behavior anyways.

Re: Ask HN: Abandoned/dead projects you think died before their time and why?

#425
post #416

Earlier quoted context omitted.

Sure, authoring tools should help authors avoid mistakes and produce valid content. But the browser is a tool for the consumer of content, and there is no benefit for the user if it fails to to render some existing pages. It is like Windows jumping through hoops to support backwards compatibility even with buggy software. The interest of the customer is that the software runs.

> there is no benefit for the user if it fails to to render some existing pages What if the browser renders it incorrectly ? If a corrupt tag combination leads to browser X parsing " " as inline text but browser Y parsing it as a script tag, that could lead to serious security issues! Blindly guessing at the original author's intent whenever you encounter buggy content is a recipe for disaster. Sometimes it is to the…

and that's why HTML5 standardized the behavior, so both browsers will parse it the same, they just don't care if someone thinks it's "invalid" or not.

Re: Ask HN: Abandoned/dead projects you think died before their time and why?

#426
post #388

- Photon, the graphical interface for QNX. Oriented more towards real time (widgets included gauges) but good enough to support two different web browsers. No delays. This was a real time operating system. - MacOS 8. Not the Linux thing, but Copeland. This was a modernized version of the original MacOS, continuing the tradition of no command line. Not having a command line forces everyone to get their act together ab…

The reason XHTML failed is because the spec required it to be sent with a new MIME type (application/xml+xhtml I believe) which no webserver did out of the box. Everything defaulted to text/html, which all browsers would interpret as HTML, and given the mismatching doctype, would interpret as tag soup (quirks mode/lenient). Meanwhile, local files with the doctype would be treated as XHTML, so people assumed the docty…

> The reason XHTML failed is because the spec required it to be sent with a new MIME type (application/xml+xhtml I believe) which no webserver did out of the box. Everything defaulted to text/html, which all browsers would interpret as HTML, and given the mismatching doctype, would interpret as tag soup (quirks mode/lenient).

None of that is correct.

It was perfectly spec. compliant to label XHTML as text/html. The spec. that covers this is RFC 2854 and it states:

> The text/html media type is now defined by W3C Recommendations; the latest published version is [HTML401]. In addition, [XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html.

https://datatracker.ietf.org/doc/html/rfc2854

There’s no spec. that says you need to parse XHTML served as text/html as HTML not XHTML. As the spec. says, text/html covers both HTML and XHTML. That’s something that browsers did but had no obligation to.

The mismatched doctype didn’t trigger quirks mode. Browsers don’t care about that. The prologue could, but XHTML 1.0 Appendix C told you not to use that anyway.

Even if it did trigger quirks mode, that makes no difference in terms of tag soup. Tag soup is when you mis-nest tags, for instance . Quirks mode was predominantly about how it applied CSS layout. There are three different concepts being mixed up here: being parsed as HTML, parsing tag soup, and doctype switching.

The problem with serving application/xhtml+xml wasn’t anything to do with web servers. The problem was that Internet Explorer 6 didn’t support it. After Microsoft won the browser wars, they discontinued development and there was a five year gap between Internet Explorer 6 and 7. Combined with long upgrade cycles and operating system requirements, this meant that Internet Explorer 6 had to be supported for almost 15 years globally.

Obviously, if you can’t serve XHTML in a way browsers will parse as XML for a decade and a half, this inevitably kills XHTML.

Re: Ask HN: Abandoned/dead projects you think died before their time and why?

#427
post #37

A lot of things on https://killedbygoogle.com/ . I used to use 30-40 Google products and services. I'm down to 3-4. Google Picasa: Everything local, so fast, so good. I'm never going to give my photos to G Photos. Google Hangouts: Can't keep track of all the Google chat apps. I use Signal now. Google G Suite Legacy: It was supposed to be free forever. They killed it, tried to make me pay. I migrated out of Google. Go…

I'm still upset that Google Maps no longer tracks my location. It was very useful to be able to go back and see how often and where I had gone. Is there another app where I can store this locally?

I use this free and extremely bare bones app made by a friend: https://apps.apple.com/us/app/max-where/id1579123291. It tracks your location constantly, has a basic viewer, and lets you export to CSV. That’s about it but it’s all I need.

Re: Ask HN: Abandoned/dead projects you think died before their time and why?

#428
post #375

Earlier quoted context omitted.

If you forget a closing quote on an attribute in html, all content until next quote is ignored and not rendered - even if it is the rest of the page. I dont think this is more helpful than an error message. It was just simpler to implement.

Let's say you forget to close a element. What happens? Even today, after years of better error messages, the strict validator at https://validator.w3.org/check says: Error Line 22, Column 4: end tag for "b" omitted, but OMITTAG NO was specified What is line 22? It's up to you to go hunting back through the document, to find the un-closed 'b' tag. Back in the day, the error messages were even more misleading than this…

For reference, observe what happens if you try opening this malformed document in a browser: save it with a .xhtml extension, or serve it with MIME type application/xhtml+xml.

Firefox displays naught but the error:

  XML Parsing Error: mismatched tag. Expected: .
  Location: file:///tmp/x.xhtml
  Line Number 22, Column 3:
  

--^
Chromium displays this banner on top of the document up to the error:

  This page contains the following errors:
  error on line 22 at column 5: Opening and ending tag mismatch: b line 19 and p
  Below is a rendering of the page up to the first error.

Re: Ask HN: Abandoned/dead projects you think died before their time and why?

#429
Dreamweaver or some other real WYSISYG web page editor that could maybe deal with very basic JavaScript.

I just wanna make a mostly static site with links in and out of my domain. Maybe a light bit of interactivity for things like search that autocompletes.

Re: Ask HN: Abandoned/dead projects you think died before their time and why?

#430

Earlier quoted context omitted.

> but what would be the benefit of having more pages fail to render? I think those benefits are quite similar to having more programs failing to run (due to static and strong typing, other static analysis, and/or elimination of undefined behavior, for instance), or more data failing to be read (due to integrity checks and simply strict parsing): as a user, you get documents closer to valid ones (at least in the rough…

Sure, authoring tools should help authors avoid mistakes and produce valid content. But the browser is a tool for the consumer of content, and there is no benefit for the user if it fails to to render some existing pages. It is like Windows jumping through hoops to support backwards compatibility even with buggy software. The interest of the customer is that the software runs.

if developer accidentally left opening comment at the start of the html.

Rhetorical question: Should the browser display page even if it is commented out?

There is some bar for what is expected to work.

If all browsers would consistently error out on unclosed tags, then it would definitely force developers to close tags, it would force it become common knowledge, second nature.

Post reply on HN