Geocities ; It was a "put your html here" Free web hosting back when people barely knew what html was. Today you have to be a rocket scientist to find a way to host a free static "simple" page online.
Ask HN: Abandoned/dead projects you think died before their time and why?
421–430 of 912 posts
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#422Earlier 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…
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?
#423Earlier 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.
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#424Earlier 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…
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#425Earlier 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…
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#426- 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…
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?
#427A 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?
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#428Earlier 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…
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?
#429I 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?
#430Earlier 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.
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.