12 ms·

The evolution of the web, and a eulogy for XHTML2

179 points by tannhaeuser 7y ago

indentit 7y ago
One of the things I hate most about HTML 5 is that documents don't need to be well-formed XML, and are even encouraged not to be - `<hr>` instead of `<hr/>` etc, thus excluding XML processing tools from being able to work with HTML documents. Then one needs to support tag-soup / follow the HTML5 parsing guidelines to the letter when the whole mess could have easily been avoided. This affects text editor plugins etc. where one might want to utilise a single plugin/codebase and use XPath to traverse both XML and HTML documents easily
- tannhaeuser 7y ago
  I don't quite understand the XML fetishism. HTML is originally based on SGML, and SGML is every bit as structured as XML by definition, since XML is specified as a proper subset of XML. From the XML spec: > The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. The "generic" part refers to XML being canonical, fully-tagged markup not requiring vocabulary-specific markup declarations for tag omission/inference, empty elements and enumerated attributes like is necessary for HTML and other SGML vocabularies making use of these features. That XML has failed on the web doesn't mean one has to give up structured documents. In fact, HTML can be converted easily into XHTML using SGML [1]. If anything, markup geeks should embrace SGML (an ISO standard no less) to discover the power of a true text authoring format. For example, SGML supports Wiki syntaxes (short references) such as markdown. [1]: http://sgmljs.net/docs/parsing-html-tutorial/parsing-html-tutorial.html http://sgmljs.net/docs/parsing-html-tutorial/parsing-html-tu...
  - bhaak 7y ago
    SGML is much more complicated than XML. Look at this "<p<a href="/">first part of the text</> second part". This is a valid document fragment in HTML 4.01 because HTML is authored in SGML. Writing a correct XML parser is much easier than writing a correct SGML parser, and what's more important, it's much easier to recognize errors. I agree with OP that HTML5 should have been XML from the start. Nowadays, you hardly write any HTML by hand and even if you do, it's easy to write syntactically correct XML. It's true that you can convert any HTML into XML with ease but it's still a stupid, unnecessary step.
    - tannhaeuser 7y ago
      > HTML5 should have been XML from the start The point is that this hasn't happened; neither back in XML's heyday, and much less today. Now you can bemoan XML's demise until the end of time, or you can fallback to XML's big sister SGML. As I said, SGML has lots of features over XML that are in fact desirable for an authoring format, such as Wiki syntaxes, type-safe/injection-free templating, stylesheets, etc. on top of being able to parse HTML. Many of these features are being reinvented in modern file-based CMSs and static site generators, so there's definitely a use case for this. Whereas editing XML (a delivery rather then authoring format) by hand is quite cumbersome, verbose and redundant, yet still doesn't help at all in how text content is actually created on the web.
      - dragonwriter 7y ago
        > Now you can bemoan XML's demise until the end of time XML, while not the main format for modern HTML, isn't dead, so why would one bemoan it's demise? In fact, it's quite widely used.
      - bhaak 7y ago
        Is SGML even still used? The only usecase I remember besides HTML is DocBook and that of course also has a XML variant for a long time. SGML is needlessly complex as an authoring format. Even HTML was considered too complex and that's why we got lightweight markup languages like MarkDown and AsciiDoc. I would be very surprised if we ever turn back to something like SGML. Especially as there are well designed LML as AsciiDoc or reStructuredText.
        incompatible 7y ago
        SGML was in fact designed to be typed by hand, as an evolution of earlier mainframe markup languages at IBM. The idiosyncratic shortcut features are supposed to reduce the number of keystrokes needed for entering text.
        tannhaeuser 7y ago
        To give you an idea of what SGML is capable of, see my tutorial at [1]. It implements a lightweight content app where markdown syntax is parsed and transformed into HTML via SGML short references, then gets HTML5 sectioning elements inferred (eg. the HTML5 outlining algorithm is implemented in SGML), then gets rendered as a page with a table of content nav-list linking to full body text, and with HTML boilerplate added, all without procedural code. [1]: http://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html http://sgmljs.net/docs/producing-html-tutorial/producing-htm...
  - zokier 7y ago
    HTML was based on SGML, but HTML 5 is explicitly not SGML anymore and specification calls the format "inspired by SGML". So to be fully conformant you need a custom processor instead of being able to use standard tools.
    - tannhaeuser 7y ago
      HTML5 doesn't cease to be based on SGML by a browser cartel with the express intent to transform the web into JavaScript-heavy web apps declaring so. WHATWG isn't an accredited standards body so what they declare a "standard" or "conformant" means shit. Especially if they don't bother to actually publish a standard that doesn't change all the time. Their "living standard" thing is at best a collaborative Wiki space of sorts where (a closed group of) "browser vendors" attempt to agree on how to do things, and is falling apart lately. WHATWG's "standard" has witnessed the web becoming a Chrome monopoly, and Opera and MS to cease browser development altogether. SGML is the only game in town able to parse (a significant part of) HTML based on an actual standard, and is also the only realistic perspective for folks interested in the web as a standardized communication medium going forward.
      - ChrisSD 7y ago
        HTML was "based on" SGML only in the sense that it borrowed a lot from SGML. However in practice it was never an application of SGML. HTML4 tried its best to move developers to SGML based HTML but devs ignored it. HTML5 recognises that there was this gulf between the specification and the actual usage and sided with real world usage.
  - alkonaut 7y ago
    Every platform has xml parsers and serializers. To generate html5 tag soup you need bespoke tools. Xml is also structurally so much simpler than xml. Making an editor able to auto indent xml is simpler than making it auto indent html.
- FlorianRappl 7y ago
  Even if `<hr />` (or others, e.g., `<img />`) would be required XML processing would not work. HTML (prio to HTML5) was full of quirks (e.g., table handling, formatting elements, ...), which cannot be expressed by a DTD that is used from XML. As a result, the DOM as seen from an XML POV could always be different from the real DOM even if the source could be parsed. HTML5 just standardized all these quirks, leading to a uniform parsing model instead of an even bigger x-browser mess.
- makecheck 7y ago
  I wouldn’t say “easily” avoided. You can’t ignore the billions of web pages that would have already existed in a format that was non-compliant with XML at the time. With so much “prior art”, there is simply no way that any browser will ever be able to throw out its fuzzy/imprecise parser, which means that support for well-formed XML requires them to maintain two readers: precise and imprecise. As far as XML “tools”, I am shocked at how even now I encounter real XML parsers that don’t necessarily reject malformed data files but do atrocious things with them (like silently pretend that certain tags were not even in the file). Thus, I end up using extra steps like a linter as a front-end sanity check. And while this example is a pure-data application, a linter is also a sensible front-end sanity check for HTML. XML isn’t going to win over HTML if it requires the same steps to clean up imperfections in the process.
superkuh 7y ago
That last paragraph absolutely nails it. Trying to re-implement the operating system as the browser is mutually exclusive with it being a good browser or standard for webpages. > If anyone constructed a PDF, which was itself blank but, via embedded JavaScript, loaded parts of itself from a remote server, people would rightly balk and wonder what on earth the creator of this PDF was thinking — yet this is precisely the design of many “websites”. To put it simply, websites and webapps are not the same thing, nor should they be. Yet the conflation of a platform for hypertext and a platform for applications has confused thinking, and led developers with prodigious aptitude for JavaScript to mistakenly see mere websites of text as a like nail to their applications hammer.
- andylynch 7y ago
  I’ve seen PDFs like these- it’s one way for publishers of (costly!) industry research reports to allow limited downloads and still track who’s reading them (the kind where a copy is listed at 5000 USD for non subscribers). And they are horrible to use, but do serve a purpose.
  - lucasverra 7y ago
    what is interesting to notice is that is the research industry that gave birth to the web that this article rightfully wants to differentiate from document/application web
- nitwit005 7y ago
  It's worth remembering that, because there were no Javascript or HTML APIs for many things people felt their pages needed, a huge portion of the web was loading up flash, silverlight, or java applets. Now, maybe they never should have allowed Flash and friends, but the genie was well out of the bottle. You could either have HTML and JS based functionality, or the plugins.
  - skunkpocalypse 7y ago
    WHATWG should have published a standard to replace Flash -- all the same goals as Flash, but a clean-slate standards-driven design. Instead they infected the HTML standard with everything Flash was being used for.
ealexhudson 7y ago
One benefit of XHTML not mentioned is that, as an XML spec, it can be embedded into other markups. OpenDocument / OASIS ODF for example, uses it extensively - the written documents are basically just HTML, which for many applications is much more accessible than the OpenXML equivalent. A lot of people used to emit XHTML with invalid string builders rather than XML serialisers though. Much XHTML was ruinously broken.
pgcj_poster 7y ago
> This is unsurprising given the total willingness and business incentive of major players such as Google to drive the applications use case and their comparative disinterest in the semantic hypertext use case Indeed, I am consistently surprised at the document-display features that are still missing from web browsers that are increasingly preoccupied with serving as application runtimes. The web was originally envisioned as a platform for scientists to share documents, but thanks to Google dropping MathML, there's still no cross-browser, non-kludge way to display math. Browsers still can't justify text properly. Even with hyphenation (which iirc is still a problem in Chrome), the greedy algorithm used for splitting text across lines still results in too much space between words when justified. There seems to be a complete lack of interest in Paged Media support, so if you want your web-page to be printable with nice formatting, you basically need to provide it as a PDF. I've gotten to the point where I'm often happier to read something in-browser as a PDF than as a web-page. Sure, it can't reflow properly, but at least it won't have a 2-inch sticky header and make XHR requests to 10 different domains. My vision-impaired father reports that his text-to-speech software now works better with PDFs than with real web-pages. This is insanity.
- ahartmetz 7y ago
  Also there is no way to include a file... Let's say you have a menu at the top of your website. You can't use frames because frames are bad mkay, and you can't include it. So you have to copy-paste it into every page manually, using some build system or even using some DHTML technology. Chrome and only Chrome has an include extension, but for security reasons (something about cross-site foo), you can't use it when testing an HTML file on your disk, because you need a hostname to check the same origin policy. You need to put it into a local webserver, which, fortunately, is fairly easy with Python.
  - wodenokoto 7y ago
    Yeah, I never understood why there wasn't an <include> element in HTML, that would just paste the content of the linked document. Why wasn't such an element added in the late 90's or early 2000? In the early days, when dynamic webpages were processed by something called CGI and even when we started using PHP, this was like 90% of the use case for doing a dynamic webpage. The last 10% might have been some sort of counter.
dustingetz 7y ago
semantic web can only happen if paired with a new business model that is not advertising and e-commerce. Also, to get alignment from coders they need to fall into the pit of success. So it needs to be a new thing, separate and distinct from HTML.
ainar-g 7y ago
Thank you for posting this! Now I know that I'm not the only “grumpy old man” who smells the fishy part of the “Modern Web”. With that said, I would love the author to go on and elaborate on other advantages of XHTML2, such as possible integrations with XForms (including more inputs and sending requests without page reloading and without JavaScript), XFrames, the single header element <h>, every element as a hyperlink, etc. Then there are MathML and XSLT. If XHTML2 became a reality, we would probably see XSLT 2.0 more actively adopted by the browser vendors, which is a good thing in my book.
- techdragon 7y ago
  XForms is one of the things I wish would be more widespread, it’s such a good idea in principle. I think it just gets tarred with the “XML is bad” brush and ignored.
  - ainar-g 7y ago
    Someone should write an article and call it something like “‘XML Considered Harmful’ Considered Harmful”. By no means is XML a very nice one to work with (manually). But at some point during late 1990s it had a real chance of becoming the document and data mark-up language, with standards allowing you to do pretty much anything with it. And a bunch of WYSIWYG tools for those who are allergic to plain text and scriptable editors. And I think it would be a slightly better world.
    - acdha 7y ago
      I wish the XML community had given proper priority to usability along with quality tooling and examples. There was a solid decade where people would work on a spec which sounded cool but effectively never shipped from the perspective of working developers or did so with enough bugs/inconsistent support/poor performance/bad UX that it was a net cost. As a simple example, you still can’t use XPath 2 portably because libxml2 never implemented it – absolutely nothing that the XML standards community was working on had even 5% of the value that would have come from fixing that or countless similar problems which had a constant pressure to stop using XML. The same was true of good documentation and examples: the assumption was that other people would take time to learn these convoluted specs but most of them started using JSON instead because they could ship so much faster.
scandox 7y ago
> The number of web browsers capable of consuming plain (X)HTML massively exceeds the number of web browser engines capable of consuming the modern application platform, a number which stands now at approximately two.
- saagarjha 7y ago
  WebKit, Gecko, Blink?
roca 7y ago
This piece gets many things wrong --- or at least fails to present both sides of the argument. WHATWG did not "usurp" the W3C. The W3C abandoned HTML development by focusing on XHTML2, incompatible with HTML. This left an opening for someone to propose backwards-compatible extensions of HTML, since the W3C was explicitly not interested in that. WHATWG was formed to do this and produced HTML5. HTML5 was adopted by industry, XHTML2 was not. In an attempt to stay relevant, the W3C tried to stage a hostile takeover of HTML5. That attempt failed because the W3C had blown their credibility by that point. However there were still some advantages to having a W3C-approved HTML spec, so an agreement was reached where the W3C could approve the specs produced by WHATWG. There are technical reasons why HTML <object> was not suitable for audio and video elements. For example, media elements need to expose media-specific JS APIs (e.g. seek()), but the MIME type of an <object> can change over time due to URL loading and DOM attribute changes, which would mean that the interface exposed by the element would need to change unpredictably over time, which would be a nightmare for developers. Also, there were very nasty legacy browser compatibility constraints around (mis)use of <object>. The author misunderstands, or misrepresents, the WHATWG's spec design philosophy. Unlike the W3C, the WHATWG treated compatibility with existing Web content as essential. That means the WHATWG specifies existing browser behaviour where there is significant existing Web content that requires it. The W3C, on the other hand, tended to assume that Web developers pay attention to specs and that writing down conformance requirements would magically cause all Web content to be updated to satisfy them. Those assumptions are not true. (The idea that Web developers would migrate to XHTML2 because the W3C proclaimed it as the future was in the same vein.) XML syntax for HTML failed for various reasons but not because of the WHATWG or browsers, which always supported XML syntax for HTML. One major problem is ensuring that dynamically generated XML pages are always valid XML. It is very easy to have bugs so that under some conditions (e.g. malicious user input) the server outputs invalid XML and produces a "yellow screen of death". Common examples of those bugs were bugs that allowed the Unicode 0xFFFE or 0xFFFF code points to slip into the XML output, which are not allowed in valid XML. A similar problem is when users interrupt a partial download of an XHTML file; the file has unclosed tags, so a conforming browser will replace the partially loaded and rendered document with a "yellow screen of death". This is not what users or developers actually want. (This assumes the browser bends the rules to allow partial rendering in completely loaded and validated XHTML documents, which is something users and developers do actually want.)
pixelmonkey 7y ago
> The pursuit of the semantic web has changed in the era of HTML5, which represented a rejection of XHTML — to me, a seemingly bizarre rejection of having to write well-formed XML as somehow being unreasonably burdensome. This is a classic "worse is better" situation. HTML5 may be "worse" than XHTML, from the standpoint of extensibility, namespacing, code cleanliness, and so on. But HTML5 is simpler to write for people who knew HTML4, and easier to get right using the one ubiquitous web development practice: staring at the rendered result in your browser, which every web developer has installed. So it's "better", and ends up winning.
jefftk 7y ago
A lot of issues with this post, but I'll just take two: > rather than articulating particular requirements and principles but not how they need be met, the WHATWG specifications tend to be written in a highly algorithmic and prescriptive style; they read like a web browser's source, if web browsers were written in natural language. It turns out that if you want to have pages work the same in every browser you need to have every browser doing the same thing when it interprets the pages. > The pursuit of the semantic web has changed in the era of HTML5, which represented a rejection of XHTML — to me, a seemingly bizarre rejection of having to write well-formed XML as somehow being unreasonably burdensome. In practice, people won't write valid XML. We had a lot of cargo-culting, people putting self-closing tags into HTML, but people weren't using XML editors. And without an editor that understands XML it definitely is unreasonably burdensome to create XML. What we saw instead was that even most "XHTML" documents were not valid XHTML and were served with an HTML content type. If you had served them instead with an XHTML content type the browser would have simply refused to render them. Both of these were recognitions that the previous approach wasn't working, and that if the spec was to achieve its goals we needed to try something different. Under WHATWG the spec has moved from "yes, the spec says this but it doesn't matter" to "the spec describes what the browsers do, and the browsers treat cases where they violate the spec as bugs". Sites now really do work the same across browsers, and WHATWG deserves a lot of credit for that.
- klez 7y ago
  > It turns out that if you want to have pages work the same in every browser you need to have every browser doing the same thing when it interprets the pages Yes, but the change was that first browsers adapted to the standard, now the standard adapts to the browsers. That's the big change.
  - jefftk 7y ago
    No, it used to be that the spec ignored the browsers and the browsers ignored the spec.
    - klez 7y ago
sgeisler 7y ago
I once searched for a way to send PUT requests using HTML forms because I despise using JS for core functionality but still wanted to build a nice REST API. Somehow I stumbled across XForms which was part of XHTML2 and supports PUT and DELETE only to find out that no browser supports it. Now I hope that the form extensions proposal [1] will gain some traction. [1] http://cameronjones.github.io/form-http-extensions/index.html http://cameronjones.github.io/form-http-extensions/index.htm...
- hlandau 7y ago
  The most common "solution" for this is to add middleware on the server-side which accepts a form parameter "_method" which supercedes the real HTTP method. I believe Rails uses this.
  - sgeisler 7y ago
    I'm aware of this workaround, but it's still a sad state of affairs, especially since POSTs have to be handled with more care because they aren't idempotent. So the browser will warn the user if they really want to resend the query if something goes wrong the first time.
why-oh-why 7y ago
This was not avoidable. Had the XHTML2 standard been adopted by many, browsers would have still had to support all the other non-X HTML documents, which would have never disappeared. HTML5, with the exception of the new elements, just formalized the existing web parsing strategies for better cross compatibility. As a web user, I don’t miss the days of XHTML sites randomly completely breaking because some tag wasn’t closed. As a developer, I only miss XHTML2’s support for `href` on any element.
- ChrisSD 7y ago
  > As a web user, I don’t miss the days of XHTML sites randomly completely breaking because some tag wasn’t closed. Ironically that was a very rare event in practice. For it to even possibly happen, three things had to come together which were still uncommon even at XHTML's height: 1. The page had to be written as XHTML 2. The page had to be served as XHTML 3. The page had to be parsed as XHTML Usually at least two of those things weren't happening.
  - Vinnl 7y ago
    The second didn't happen precisely because people wanted to avoid the sites completely breaking. So it didn't happen because people avoided XML, in practice.
    - ChrisSD 7y ago
      That was my point. The "days of XHTML" barely existed outside the minds of a relatively small number of developers.
      - zmix 7y ago
        It doesn't make much sense to state things, I can't back up with references (I do not remember where I read it), but a few months ago I read, that by 2006 (or 2008) 60% of all web pages were XHTML. Now, whether that means, that they have been served with the right media-type, I do not remember, but what I know, is that "nerdy" places, and that includes Steam, HumbleBundle.com and GOG.com, were all running on XHTML. So, it was not just a bunch "the minds of a relatively small number of developers".
nl 7y ago
For those who agree with this: The reason HTML5 became what it is is because many people wanted to see the open web thrive as a competitor to closed, controlled eco-systems like the mobile application development platforms. Just 10 years ago this was a mainstream view - there were groups who were fighting to give browsers web cam access so they could be used as video-messaging platforms, groups fighting to give location access so we could write location aware documents and apps etc etc. I still believe this was the right decision.
- klez 7y ago
  If you view this in the context of needing separate models for documents and application, it means that you wouldn't need all that substrate of APIs for documents (i.e, why would you need a webcam API or even AJAX to render a blog article?). So in that context I do agree with the article.
  - nl 7y ago
    So.. don't use those APIs? One of the reasond a platform succeeds is because it can be many things to different people. I completely rejected the idea that there should be separated document and application models. Instead I think there are capabilities which should be layered to add abilities.
  - nl 7y ago
    i.e, why would you need a webcam API or even AJAX to render a blog article? This seems like a lack of imagination. The modern scientific publication Distill.pub makes heavy use of AJAX (eg https://distill.pub/2019/activation-atlas/ https://distill.pub/2019/activation-atlas/) and it's easy to imagine it using a webcam (eg, to demonstrate semantic segmentation)
diskmuncher 7y ago
I guess no one would object if you want to write an SPA using HTML5 and ES2020 that retrieves an XML semantic Web document and displays it in all kinds of CSS glory.
thosakwe 7y ago
I'm a bit conflicted. I like the idea of Web browsers as an application platform, though it borders on "reinventing the operating system." The File API, Notifications API, MediaSession, etc. all make it possible to essentially have cross-platform desktop applications that users don't need to manually install. I also don't, and never really cared much for "semantic hypertext," linked data, XHTML, XHTML2, RDF, nor is my browser usage predominantly about just sharing/receiving information. That being said, there's so much involved in writing a Web browser that writing one from scratch would take years. There are only a few active implementations, and I don't expect that change for a long time, if ever (at least not without a lot of funding). So I can understand the author's viewpoint.
- james-skemp 7y ago
  > nor is my browser usage predominantly about just sharing/receiving information. What do you use the browser for then? Do you primarily play games/music/movies? You mention applications in your comment; if that's not sharing/receiving information, what are you doing in them?
  - thosakwe 7y ago
    Yes, primarily music, media, social media, mostly interactive experience. I should have been a bit more clear about "sharing/receiving information," or rather, reworded it as "viewing static documents."
commandlinefan 7y ago
> If it’s an article I simply leave And many times that choice is made for you: there’s a link to a Vulture.com post on HN right now (about Disney archiving the Fox catalogue) and every time I try to read it, Chrome crashes trying to keep up with the volumes of JavaScript they add, ostensibly to keep advertisers happy.
- acdha 7y ago
  Are you running Chrome on an old phone, or perhaps with some extension which injects a lot of code? Looking at the page, it's certainly showing why ad blockers are popular but it doesn't crash or use unusual amounts of memory on either desktop or mobile Chrome: https://webpagetest.org/result/191027_BF_57a6cd57fc6fe629628f8551448417fb/ https://webpagetest.org/result/191027_BF_57a6cd57fc6fe629628... https://webpagetest.org/result/191027_2G_fba74afe0c488b99e53f92d73883c9fd/ https://webpagetest.org/result/191027_2G_fba74afe0c488b99e53...
jgalt212 7y ago
If semantic won out, there'd be less need for sophisticated search engines to make sense of all this stuff. In fact, I'd go one further: If gopher had taken up multimedia quicker and then beat out the web, there would be no Google today. These sort of things are not inherent to the web. People and entities want to transmit data in the format(s) that are easiest for them. It's up to the aggregators to make sense of it all.
- makecheck 7y ago
  A perfectly-marked-up HTML document only solves the problem for text expressed in HTML. It doesn’t solve any other format that people publish (even today we have links to PDF and Word and Excel, etc.). And of course there is meaningful information in formats that are not documents at all, like images. Some of those images are pictures of text that we might want to read. It requires some investment to come up with tools for analyzing files. I’m wondering if the tools would have been as sophisticated if documents had lowered their barriers. For example, how do you justify developing a machine-learning model to look for more, if it seems all your documents are already semantically tagged with the details that were important to somebody?
perlgeek 7y ago
Hey, I actually wrote an application that produced strict xhtml2, and served it with a application/xml+xhtml content type (iirc). It was a page that displayed IRC logs, with linkable anchors for each line, automatically breaking words that were too long for the browser, turning text into links by regex, interpreting terminal colors etc. Each time I had a tiny cross-site scripting bug in there (some part wasn't XML-escaped properly), some data would eventually trigger it (you wouldn't believe the amount of encoding junk on IRC), the browser would simply refuse to render anything at all. Inconvenient for my users, but it made sure such things didn't slip by unnoticed. --- This was a side project, done for fun, and a few friends that used my site. If I had been trying to make money from it, the first thing I would've done is to switch to something less strict, so that tiny errors wouldn't stop rendering the whole page.
- gwbas1c 7y ago
  Around 2010 I did some web programming. XHTML was so much easier to parse and render from code because I could use some very powerful XML libraries. HTML is different enough from pure XML that it requires a different parser. It was very nice to load an XML document and look for tags in a specific namespace instead of using a specialized HTML templating engine.
gfodor 7y ago
Oddly enough I just wrote an article about this as it relates to predicting the arrival of the 3D ‘metaverse’: https://github.com/mozilla/hubs-cloud/wiki/The-Web-Emergent-Metaverse https://github.com/mozilla/hubs-cloud/wiki/The-Web-Emergent-...
em-bee 7y ago
i have been creating websites since the early 90s, and every single one of them was an application. html was always generated dynamically, and never static. any static html documents were embedded with a dynamically generated navigation. the whole idea of a web of semantic hypertext was never a reality. that idea died with gopher. (anyone remember that?) why? because gopher had a builtin navigation system that allowed you to manage directories and document structures that didn't belong to the documents themselves. semantic hypertext within gopher would have worked well. as would have applications. but without gopher we were forced to reinvent that navigation and squeeze it into our documents, overloading them with stuff that didn't belong inside. think of a library with books. what the semantic hypertext promised was to make all those books into interactive texts where you can easily jump from one reference to another. but those books still need a library to live in. what the web ended up doing was to remove the library completely, forcing me to reinvent the library within the book. suddenly the semantic document that i want to send you not only contains references relevant to its context, but it has to include the whole navigation for my library, because there is no way to do that externally. with that navigation included, you are no longer getting a semantic hypertext, but an application. now, we get to write that application in javascript and actually run it on your device, instead faking it on the server. but on the flip side, on the server i can now finally go back to serving static documents. i can finally serve semantic hypertext documents as they were meant to be served because i can separate the application from the content, and i can treat the content as static as it was meant to be treated. i am not reinventing navigation logic in javascript. browsers never had navigation logic in the first place. gopher had that. i always had to re-invent navigation logic for every site i built and was forced to embed that into html dynamically so that site visitors could find their way.
zelly 7y ago
The horrible "be liberal in what you accept, be conservative in what you do" meme is the cause of this. At some point it was decided that it would be too rude to emit a compiler error on someone's junk HTML, so browsers just added hacks to make it work anyway. It has to be backwards compatible too; don't dare break behavior of an old tag that someone out there depends on. There's not much point in switching to XHTML2 with sane versioning, namespacing and extensibility if it's also going to be hacked around because no one wants their input rejected. It's hacks all the way down, by design, forever.
darepublic 7y ago
I got on board the js train as a young developer just at the right time, when the term AJAX was something of a buzzword. Now my fellow developers give me dirty looks when I suggest our largely static site can do without redux, or that someone would conceive of building a simple accordion component in anything less than React.
- acemarke 7y ago
  fwiw, I _maintain_ Redux, and I completely agree that it would be unnecessary for that kind of site :)
thayne 7y ago
I think both applications and media would benefit from a split of html into seperate language for defining app-like sites, and traditional content pages. Html and the dom APIs are currently strange mix of content orinted semantic elements and app oriented (often non-semantic) elements. Not to mention that the default flow layout does more harm than good for most applications.
- zmix 7y ago
  > I think both applications and media would benefit > from a split of html into seperate language for > defining app-like sites, and traditional content pages. This! I would go a step further, even. The "web-applifier" community should just leave the classic web and do their own: * protocol (I am sure, HTTP is not ideal for serving apps) * GUI description language (document markup language for UI design, really?) * runtime (let them have WebAssembly and whatever they need) * each app then could have their own window, making it look like a traditional app
  - thayne 7y ago
    so... like Java swing or Adobe Air? I don't know all the reasons technologies those failed to deliver, but I do think that being able to deploy from the same platform that users use to discover the app (that is, the browser) as well as almost effortless instant updates has a lot to be said for it.
- Mikhail_Edoshin 7y ago
  I think this was the original vision of XML: eXtensible markup language. With globally unique names XML was meant to produce a whole world of languages that could've been developed independently and mixed together in the same manner as Unix command-line tools. E.g. XSLT is a language for a XSLT processor; XSL-FO is a language for XSL-FO processor and so on. In this schema XHTML would've been a language for the browser that would co-exist with the rest of the ecosystem.

179 points by tannhaeuser 7y ago

One of the things I hate most about HTML 5 is that documents don't need to be well-formed XML, and are even encouraged not to be - `<hr>` instead of `<hr/>` etc, thus excluding XML processing tools from being able to work with HTML documents. Then one needs to support tag-soup / follow the HTML5 parsing guidelines to the letter when the whole mess could have easily been avoided. This affects text editor plugins etc. where one might want to utilise a single plugin/codebase and use XPath to traverse both XML and HTML documents easily

tannhaeuser 7y ago
I don't quite understand the XML fetishism. HTML is originally based on SGML, and SGML is every bit as structured as XML by definition, since XML is specified as a proper subset of XML. From the XML spec: > The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. The "generic" part refers to XML being canonical, fully-tagged markup not requiring vocabulary-specific markup declarations for tag omission/inference, empty elements and enumerated attributes like is necessary for HTML and other SGML vocabularies making use of these features. That XML has failed on the web doesn't mean one has to give up structured documents. In fact, HTML can be converted easily into XHTML using SGML [1]. If anything, markup geeks should embrace SGML (an ISO standard no less) to discover the power of a true text authoring format. For example, SGML supports Wiki syntaxes (short references) such as markdown. [1]: http://sgmljs.net/docs/parsing-html-tutorial/parsing-html-tutorial.html http://sgmljs.net/docs/parsing-html-tutorial/parsing-html-tu...
- bhaak 7y ago
  SGML is much more complicated than XML. Look at this "<p<a href="/">first part of the text</> second part". This is a valid document fragment in HTML 4.01 because HTML is authored in SGML. Writing a correct XML parser is much easier than writing a correct SGML parser, and what's more important, it's much easier to recognize errors. I agree with OP that HTML5 should have been XML from the start. Nowadays, you hardly write any HTML by hand and even if you do, it's easy to write syntactically correct XML. It's true that you can convert any HTML into XML with ease but it's still a stupid, unnecessary step.
  - tannhaeuser 7y ago
    > HTML5 should have been XML from the start The point is that this hasn't happened; neither back in XML's heyday, and much less today. Now you can bemoan XML's demise until the end of time, or you can fallback to XML's big sister SGML. As I said, SGML has lots of features over XML that are in fact desirable for an authoring format, such as Wiki syntaxes, type-safe/injection-free templating, stylesheets, etc. on top of being able to parse HTML. Many of these features are being reinvented in modern file-based CMSs and static site generators, so there's definitely a use case for this. Whereas editing XML (a delivery rather then authoring format) by hand is quite cumbersome, verbose and redundant, yet still doesn't help at all in how text content is actually created on the web.
    - dragonwriter 7y ago
      > Now you can bemoan XML's demise until the end of time XML, while not the main format for modern HTML, isn't dead, so why would one bemoan it's demise? In fact, it's quite widely used.
    - bhaak 7y ago
      Is SGML even still used? The only usecase I remember besides HTML is DocBook and that of course also has a XML variant for a long time. SGML is needlessly complex as an authoring format. Even HTML was considered too complex and that's why we got lightweight markup languages like MarkDown and AsciiDoc. I would be very surprised if we ever turn back to something like SGML. Especially as there are well designed LML as AsciiDoc or reStructuredText.
      - incompatible 7y ago
        SGML was in fact designed to be typed by hand, as an evolution of earlier mainframe markup languages at IBM. The idiosyncratic shortcut features are supposed to reduce the number of keystrokes needed for entering text.
      - tannhaeuser 7y ago
        To give you an idea of what SGML is capable of, see my tutorial at [1]. It implements a lightweight content app where markdown syntax is parsed and transformed into HTML via SGML short references, then gets HTML5 sectioning elements inferred (eg. the HTML5 outlining algorithm is implemented in SGML), then gets rendered as a page with a table of content nav-list linking to full body text, and with HTML boilerplate added, all without procedural code. [1]: http://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html http://sgmljs.net/docs/producing-html-tutorial/producing-htm...
- zokier 7y ago
  HTML was based on SGML, but HTML 5 is explicitly not SGML anymore and specification calls the format "inspired by SGML". So to be fully conformant you need a custom processor instead of being able to use standard tools.
  - tannhaeuser 7y ago
    HTML5 doesn't cease to be based on SGML by a browser cartel with the express intent to transform the web into JavaScript-heavy web apps declaring so. WHATWG isn't an accredited standards body so what they declare a "standard" or "conformant" means shit. Especially if they don't bother to actually publish a standard that doesn't change all the time. Their "living standard" thing is at best a collaborative Wiki space of sorts where (a closed group of) "browser vendors" attempt to agree on how to do things, and is falling apart lately. WHATWG's "standard" has witnessed the web becoming a Chrome monopoly, and Opera and MS to cease browser development altogether. SGML is the only game in town able to parse (a significant part of) HTML based on an actual standard, and is also the only realistic perspective for folks interested in the web as a standardized communication medium going forward.
    - ChrisSD 7y ago
      HTML was "based on" SGML only in the sense that it borrowed a lot from SGML. However in practice it was never an application of SGML. HTML4 tried its best to move developers to SGML based HTML but devs ignored it. HTML5 recognises that there was this gulf between the specification and the actual usage and sided with real world usage.
- alkonaut 7y ago
  Every platform has xml parsers and serializers. To generate html5 tag soup you need bespoke tools. Xml is also structurally so much simpler than xml. Making an editor able to auto indent xml is simpler than making it auto indent html.
FlorianRappl 7y ago
Even if `<hr />` (or others, e.g., `<img />`) would be required XML processing would not work. HTML (prio to HTML5) was full of quirks (e.g., table handling, formatting elements, ...), which cannot be expressed by a DTD that is used from XML. As a result, the DOM as seen from an XML POV could always be different from the real DOM even if the source could be parsed. HTML5 just standardized all these quirks, leading to a uniform parsing model instead of an even bigger x-browser mess.
makecheck 7y ago
I wouldn’t say “easily” avoided. You can’t ignore the billions of web pages that would have already existed in a format that was non-compliant with XML at the time. With so much “prior art”, there is simply no way that any browser will ever be able to throw out its fuzzy/imprecise parser, which means that support for well-formed XML requires them to maintain two readers: precise and imprecise. As far as XML “tools”, I am shocked at how even now I encounter real XML parsers that don’t necessarily reject malformed data files but do atrocious things with them (like silently pretend that certain tags were not even in the file). Thus, I end up using extra steps like a linter as a front-end sanity check. And while this example is a pure-data application, a linter is also a sensible front-end sanity check for HTML. XML isn’t going to win over HTML if it requires the same steps to clean up imperfections in the process.

superkuh 7y ago

That last paragraph absolutely nails it. Trying to re-implement the operating system as the browser is mutually exclusive with it being a good browser or standard for webpages. > If anyone constructed a PDF, which was itself blank but, via embedded JavaScript, loaded parts of itself from a remote server, people would rightly balk and wonder what on earth the creator of this PDF was thinking — yet this is precisely the design of many “websites”. To put it simply, websites and webapps are not the same thing, nor should they be. Yet the conflation of a platform for hypertext and a platform for applications has confused thinking, and led developers with prodigious aptitude for JavaScript to mistakenly see mere websites of text as a like nail to their applications hammer.

andylynch 7y ago
I’ve seen PDFs like these- it’s one way for publishers of (costly!) industry research reports to allow limited downloads and still track who’s reading them (the kind where a copy is listed at 5000 USD for non subscribers). And they are horrible to use, but do serve a purpose.
- lucasverra 7y ago
  what is interesting to notice is that is the research industry that gave birth to the web that this article rightfully wants to differentiate from document/application web
nitwit005 7y ago
It's worth remembering that, because there were no Javascript or HTML APIs for many things people felt their pages needed, a huge portion of the web was loading up flash, silverlight, or java applets. Now, maybe they never should have allowed Flash and friends, but the genie was well out of the bottle. You could either have HTML and JS based functionality, or the plugins.
- skunkpocalypse 7y ago
  WHATWG should have published a standard to replace Flash -- all the same goals as Flash, but a clean-slate standards-driven design. Instead they infected the HTML standard with everything Flash was being used for.

ealexhudson 7y ago

One benefit of XHTML not mentioned is that, as an XML spec, it can be embedded into other markups. OpenDocument / OASIS ODF for example, uses it extensively - the written documents are basically just HTML, which for many applications is much more accessible than the OpenXML equivalent. A lot of people used to emit XHTML with invalid string builders rather than XML serialisers though. Much XHTML was ruinously broken.

pgcj_poster 7y ago

> This is unsurprising given the total willingness and business incentive of major players such as Google to drive the applications use case and their comparative disinterest in the semantic hypertext use case Indeed, I am consistently surprised at the document-display features that are still missing from web browsers that are increasingly preoccupied with serving as application runtimes. The web was originally envisioned as a platform for scientists to share documents, but thanks to Google dropping MathML, there's still no cross-browser, non-kludge way to display math. Browsers still can't justify text properly. Even with hyphenation (which iirc is still a problem in Chrome), the greedy algorithm used for splitting text across lines still results in too much space between words when justified. There seems to be a complete lack of interest in Paged Media support, so if you want your web-page to be printable with nice formatting, you basically need to provide it as a PDF. I've gotten to the point where I'm often happier to read something in-browser as a PDF than as a web-page. Sure, it can't reflow properly, but at least it won't have a 2-inch sticky header and make XHR requests to 10 different domains. My vision-impaired father reports that his text-to-speech software now works better with PDFs than with real web-pages. This is insanity.

ahartmetz 7y ago
Also there is no way to include a file... Let's say you have a menu at the top of your website. You can't use frames because frames are bad mkay, and you can't include it. So you have to copy-paste it into every page manually, using some build system or even using some DHTML technology. Chrome and only Chrome has an include extension, but for security reasons (something about cross-site foo), you can't use it when testing an HTML file on your disk, because you need a hostname to check the same origin policy. You need to put it into a local webserver, which, fortunately, is fairly easy with Python.
- wodenokoto 7y ago
  Yeah, I never understood why there wasn't an <include> element in HTML, that would just paste the content of the linked document. Why wasn't such an element added in the late 90's or early 2000? In the early days, when dynamic webpages were processed by something called CGI and even when we started using PHP, this was like 90% of the use case for doing a dynamic webpage. The last 10% might have been some sort of counter.

dustingetz 7y ago

semantic web can only happen if paired with a new business model that is not advertising and e-commerce. Also, to get alignment from coders they need to fall into the pit of success. So it needs to be a new thing, separate and distinct from HTML.

ainar-g 7y ago

Thank you for posting this! Now I know that I'm not the only “grumpy old man” who smells the fishy part of the “Modern Web”. With that said, I would love the author to go on and elaborate on other advantages of XHTML2, such as possible integrations with XForms (including more inputs and sending requests without page reloading and without JavaScript), XFrames, the single header element <h>, every element as a hyperlink, etc. Then there are MathML and XSLT. If XHTML2 became a reality, we would probably see XSLT 2.0 more actively adopted by the browser vendors, which is a good thing in my book.

techdragon 7y ago
XForms is one of the things I wish would be more widespread, it’s such a good idea in principle. I think it just gets tarred with the “XML is bad” brush and ignored.
- ainar-g 7y ago
  Someone should write an article and call it something like “‘XML Considered Harmful’ Considered Harmful”. By no means is XML a very nice one to work with (manually). But at some point during late 1990s it had a real chance of becoming the document and data mark-up language, with standards allowing you to do pretty much anything with it. And a bunch of WYSIWYG tools for those who are allergic to plain text and scriptable editors. And I think it would be a slightly better world.
  - acdha 7y ago
    I wish the XML community had given proper priority to usability along with quality tooling and examples. There was a solid decade where people would work on a spec which sounded cool but effectively never shipped from the perspective of working developers or did so with enough bugs/inconsistent support/poor performance/bad UX that it was a net cost. As a simple example, you still can’t use XPath 2 portably because libxml2 never implemented it – absolutely nothing that the XML standards community was working on had even 5% of the value that would have come from fixing that or countless similar problems which had a constant pressure to stop using XML. The same was true of good documentation and examples: the assumption was that other people would take time to learn these convoluted specs but most of them started using JSON instead because they could ship so much faster.

scandox 7y ago

> The number of web browsers capable of consuming plain (X)HTML massively exceeds the number of web browser engines capable of consuming the modern application platform, a number which stands now at approximately two.

saagarjha 7y ago
WebKit, Gecko, Blink?

roca 7y ago

This piece gets many things wrong --- or at least fails to present both sides of the argument. WHATWG did not "usurp" the W3C. The W3C abandoned HTML development by focusing on XHTML2, incompatible with HTML. This left an opening for someone to propose backwards-compatible extensions of HTML, since the W3C was explicitly not interested in that. WHATWG was formed to do this and produced HTML5. HTML5 was adopted by industry, XHTML2 was not. In an attempt to stay relevant, the W3C tried to stage a hostile takeover of HTML5. That attempt failed because the W3C had blown their credibility by that point. However there were still some advantages to having a W3C-approved HTML spec, so an agreement was reached where the W3C could approve the specs produced by WHATWG. There are technical reasons why HTML <object> was not suitable for audio and video elements. For example, media elements need to expose media-specific JS APIs (e.g. seek()), but the MIME type of an <object> can change over time due to URL loading and DOM attribute changes, which would mean that the interface exposed by the element would need to change unpredictably over time, which would be a nightmare for developers. Also, there were very nasty legacy browser compatibility constraints around (mis)use of <object>. The author misunderstands, or misrepresents, the WHATWG's spec design philosophy. Unlike the W3C, the WHATWG treated compatibility with existing Web content as essential. That means the WHATWG specifies existing browser behaviour where there is significant existing Web content that requires it. The W3C, on the other hand, tended to assume that Web developers pay attention to specs and that writing down conformance requirements would magically cause all Web content to be updated to satisfy them. Those assumptions are not true. (The idea that Web developers would migrate to XHTML2 because the W3C proclaimed it as the future was in the same vein.) XML syntax for HTML failed for various reasons but not because of the WHATWG or browsers, which always supported XML syntax for HTML. One major problem is ensuring that dynamically generated XML pages are always valid XML. It is very easy to have bugs so that under some conditions (e.g. malicious user input) the server outputs invalid XML and produces a "yellow screen of death". Common examples of those bugs were bugs that allowed the Unicode 0xFFFE or 0xFFFF code points to slip into the XML output, which are not allowed in valid XML. A similar problem is when users interrupt a partial download of an XHTML file; the file has unclosed tags, so a conforming browser will replace the partially loaded and rendered document with a "yellow screen of death". This is not what users or developers actually want. (This assumes the browser bends the rules to allow partial rendering in completely loaded and validated XHTML documents, which is something users and developers do actually want.)

pixelmonkey 7y ago

> The pursuit of the semantic web has changed in the era of HTML5, which represented a rejection of XHTML — to me, a seemingly bizarre rejection of having to write well-formed XML as somehow being unreasonably burdensome. This is a classic "worse is better" situation. HTML5 may be "worse" than XHTML, from the standpoint of extensibility, namespacing, code cleanliness, and so on. But HTML5 is simpler to write for people who knew HTML4, and easier to get right using the one ubiquitous web development practice: staring at the rendered result in your browser, which every web developer has installed. So it's "better", and ends up winning.

jefftk 7y ago

A lot of issues with this post, but I'll just take two: > rather than articulating particular requirements and principles but not how they need be met, the WHATWG specifications tend to be written in a highly algorithmic and prescriptive style; they read like a web browser's source, if web browsers were written in natural language. It turns out that if you want to have pages work the same in every browser you need to have every browser doing the same thing when it interprets the pages. > The pursuit of the semantic web has changed in the era of HTML5, which represented a rejection of XHTML — to me, a seemingly bizarre rejection of having to write well-formed XML as somehow being unreasonably burdensome. In practice, people won't write valid XML. We had a lot of cargo-culting, people putting self-closing tags into HTML, but people weren't using XML editors. And without an editor that understands XML it definitely is unreasonably burdensome to create XML. What we saw instead was that even most "XHTML" documents were not valid XHTML and were served with an HTML content type. If you had served them instead with an XHTML content type the browser would have simply refused to render them. Both of these were recognitions that the previous approach wasn't working, and that if the spec was to achieve its goals we needed to try something different. Under WHATWG the spec has moved from "yes, the spec says this but it doesn't matter" to "the spec describes what the browsers do, and the browsers treat cases where they violate the spec as bugs". Sites now really do work the same across browsers, and WHATWG deserves a lot of credit for that.

klez 7y ago
> It turns out that if you want to have pages work the same in every browser you need to have every browser doing the same thing when it interprets the pages Yes, but the change was that first browsers adapted to the standard, now the standard adapts to the browsers. That's the big change.
- jefftk 7y ago
  No, it used to be that the spec ignored the browsers and the browsers ignored the spec.
  - klez 7y ago

sgeisler 7y ago

I once searched for a way to send PUT requests using HTML forms because I despise using JS for core functionality but still wanted to build a nice REST API. Somehow I stumbled across XForms which was part of XHTML2 and supports PUT and DELETE only to find out that no browser supports it. Now I hope that the form extensions proposal [1] will gain some traction. [1] http://cameronjones.github.io/form-http-extensions/index.html http://cameronjones.github.io/form-http-extensions/index.htm...

hlandau 7y ago
The most common "solution" for this is to add middleware on the server-side which accepts a form parameter "_method" which supercedes the real HTTP method. I believe Rails uses this.
- sgeisler 7y ago
  I'm aware of this workaround, but it's still a sad state of affairs, especially since POSTs have to be handled with more care because they aren't idempotent. So the browser will warn the user if they really want to resend the query if something goes wrong the first time.

why-oh-why 7y ago

This was not avoidable. Had the XHTML2 standard been adopted by many, browsers would have still had to support all the other non-X HTML documents, which would have never disappeared. HTML5, with the exception of the new elements, just formalized the existing web parsing strategies for better cross compatibility. As a web user, I don’t miss the days of XHTML sites randomly completely breaking because some tag wasn’t closed. As a developer, I only miss XHTML2’s support for `href` on any element.

ChrisSD 7y ago
> As a web user, I don’t miss the days of XHTML sites randomly completely breaking because some tag wasn’t closed. Ironically that was a very rare event in practice. For it to even possibly happen, three things had to come together which were still uncommon even at XHTML's height: 1. The page had to be written as XHTML 2. The page had to be served as XHTML 3. The page had to be parsed as XHTML Usually at least two of those things weren't happening.
- Vinnl 7y ago
  The second didn't happen precisely because people wanted to avoid the sites completely breaking. So it didn't happen because people avoided XML, in practice.
  - ChrisSD 7y ago
    That was my point. The "days of XHTML" barely existed outside the minds of a relatively small number of developers.
    - zmix 7y ago
      It doesn't make much sense to state things, I can't back up with references (I do not remember where I read it), but a few months ago I read, that by 2006 (or 2008) 60% of all web pages were XHTML. Now, whether that means, that they have been served with the right media-type, I do not remember, but what I know, is that "nerdy" places, and that includes Steam, HumbleBundle.com and GOG.com, were all running on XHTML. So, it was not just a bunch "the minds of a relatively small number of developers".

nl 7y ago

For those who agree with this: The reason HTML5 became what it is is because many people wanted to see the open web thrive as a competitor to closed, controlled eco-systems like the mobile application development platforms. Just 10 years ago this was a mainstream view - there were groups who were fighting to give browsers web cam access so they could be used as video-messaging platforms, groups fighting to give location access so we could write location aware documents and apps etc etc. I still believe this was the right decision.

klez 7y ago
If you view this in the context of needing separate models for documents and application, it means that you wouldn't need all that substrate of APIs for documents (i.e, why would you need a webcam API or even AJAX to render a blog article?). So in that context I do agree with the article.
- nl 7y ago
  So.. don't use those APIs? One of the reasond a platform succeeds is because it can be many things to different people. I completely rejected the idea that there should be separated document and application models. Instead I think there are capabilities which should be layered to add abilities.
- nl 7y ago
  i.e, why would you need a webcam API or even AJAX to render a blog article? This seems like a lack of imagination. The modern scientific publication Distill.pub makes heavy use of AJAX (eg https://distill.pub/2019/activation-atlas/ https://distill.pub/2019/activation-atlas/) and it's easy to imagine it using a webcam (eg, to demonstrate semantic segmentation)

diskmuncher 7y ago

I guess no one would object if you want to write an SPA using HTML5 and ES2020 that retrieves an XML semantic Web document and displays it in all kinds of CSS glory.

thosakwe 7y ago

I'm a bit conflicted. I like the idea of Web browsers as an application platform, though it borders on "reinventing the operating system." The File API, Notifications API, MediaSession, etc. all make it possible to essentially have cross-platform desktop applications that users don't need to manually install. I also don't, and never really cared much for "semantic hypertext," linked data, XHTML, XHTML2, RDF, nor is my browser usage predominantly about just sharing/receiving information. That being said, there's so much involved in writing a Web browser that writing one from scratch would take years. There are only a few active implementations, and I don't expect that change for a long time, if ever (at least not without a lot of funding). So I can understand the author's viewpoint.

james-skemp 7y ago
> nor is my browser usage predominantly about just sharing/receiving information. What do you use the browser for then? Do you primarily play games/music/movies? You mention applications in your comment; if that's not sharing/receiving information, what are you doing in them?
- thosakwe 7y ago
  Yes, primarily music, media, social media, mostly interactive experience. I should have been a bit more clear about "sharing/receiving information," or rather, reworded it as "viewing static documents."

commandlinefan 7y ago

> If it’s an article I simply leave And many times that choice is made for you: there’s a link to a Vulture.com post on HN right now (about Disney archiving the Fox catalogue) and every time I try to read it, Chrome crashes trying to keep up with the volumes of JavaScript they add, ostensibly to keep advertisers happy.

acdha 7y ago
Are you running Chrome on an old phone, or perhaps with some extension which injects a lot of code? Looking at the page, it's certainly showing why ad blockers are popular but it doesn't crash or use unusual amounts of memory on either desktop or mobile Chrome: https://webpagetest.org/result/191027_BF_57a6cd57fc6fe629628f8551448417fb/ https://webpagetest.org/result/191027_BF_57a6cd57fc6fe629628... https://webpagetest.org/result/191027_2G_fba74afe0c488b99e53f92d73883c9fd/ https://webpagetest.org/result/191027_2G_fba74afe0c488b99e53...

jgalt212 7y ago

If semantic won out, there'd be less need for sophisticated search engines to make sense of all this stuff. In fact, I'd go one further: If gopher had taken up multimedia quicker and then beat out the web, there would be no Google today. These sort of things are not inherent to the web. People and entities want to transmit data in the format(s) that are easiest for them. It's up to the aggregators to make sense of it all.

makecheck 7y ago
A perfectly-marked-up HTML document only solves the problem for text expressed in HTML. It doesn’t solve any other format that people publish (even today we have links to PDF and Word and Excel, etc.). And of course there is meaningful information in formats that are not documents at all, like images. Some of those images are pictures of text that we might want to read. It requires some investment to come up with tools for analyzing files. I’m wondering if the tools would have been as sophisticated if documents had lowered their barriers. For example, how do you justify developing a machine-learning model to look for more, if it seems all your documents are already semantically tagged with the details that were important to somebody?

perlgeek 7y ago

Hey, I actually wrote an application that produced strict xhtml2, and served it with a application/xml+xhtml content type (iirc). It was a page that displayed IRC logs, with linkable anchors for each line, automatically breaking words that were too long for the browser, turning text into links by regex, interpreting terminal colors etc. Each time I had a tiny cross-site scripting bug in there (some part wasn't XML-escaped properly), some data would eventually trigger it (you wouldn't believe the amount of encoding junk on IRC), the browser would simply refuse to render anything at all. Inconvenient for my users, but it made sure such things didn't slip by unnoticed. --- This was a side project, done for fun, and a few friends that used my site. If I had been trying to make money from it, the first thing I would've done is to switch to something less strict, so that tiny errors wouldn't stop rendering the whole page.

gwbas1c 7y ago
Around 2010 I did some web programming. XHTML was so much easier to parse and render from code because I could use some very powerful XML libraries. HTML is different enough from pure XML that it requires a different parser. It was very nice to load an XML document and look for tags in a specific namespace instead of using a specialized HTML templating engine.

gfodor 7y ago

Oddly enough I just wrote an article about this as it relates to predicting the arrival of the 3D ‘metaverse’: https://github.com/mozilla/hubs-cloud/wiki/The-Web-Emergent-Metaverse https://github.com/mozilla/hubs-cloud/wiki/The-Web-Emergent-...

em-bee 7y ago

i have been creating websites since the early 90s, and every single one of them was an application. html was always generated dynamically, and never static. any static html documents were embedded with a dynamically generated navigation. the whole idea of a web of semantic hypertext was never a reality. that idea died with gopher. (anyone remember that?) why? because gopher had a builtin navigation system that allowed you to manage directories and document structures that didn't belong to the documents themselves. semantic hypertext within gopher would have worked well. as would have applications. but without gopher we were forced to reinvent that navigation and squeeze it into our documents, overloading them with stuff that didn't belong inside. think of a library with books. what the semantic hypertext promised was to make all those books into interactive texts where you can easily jump from one reference to another. but those books still need a library to live in. what the web ended up doing was to remove the library completely, forcing me to reinvent the library within the book. suddenly the semantic document that i want to send you not only contains references relevant to its context, but it has to include the whole navigation for my library, because there is no way to do that externally. with that navigation included, you are no longer getting a semantic hypertext, but an application. now, we get to write that application in javascript and actually run it on your device, instead faking it on the server. but on the flip side, on the server i can now finally go back to serving static documents. i can finally serve semantic hypertext documents as they were meant to be served because i can separate the application from the content, and i can treat the content as static as it was meant to be treated. i am not reinventing navigation logic in javascript. browsers never had navigation logic in the first place. gopher had that. i always had to re-invent navigation logic for every site i built and was forced to embed that into html dynamically so that site visitors could find their way.

zelly 7y ago

The horrible "be liberal in what you accept, be conservative in what you do" meme is the cause of this. At some point it was decided that it would be too rude to emit a compiler error on someone's junk HTML, so browsers just added hacks to make it work anyway. It has to be backwards compatible too; don't dare break behavior of an old tag that someone out there depends on. There's not much point in switching to XHTML2 with sane versioning, namespacing and extensibility if it's also going to be hacked around because no one wants their input rejected. It's hacks all the way down, by design, forever.

darepublic 7y ago

I got on board the js train as a young developer just at the right time, when the term AJAX was something of a buzzword. Now my fellow developers give me dirty looks when I suggest our largely static site can do without redux, or that someone would conceive of building a simple accordion component in anything less than React.

acemarke 7y ago
fwiw, I _maintain_ Redux, and I completely agree that it would be unnecessary for that kind of site :)

thayne 7y ago

I think both applications and media would benefit from a split of html into seperate language for defining app-like sites, and traditional content pages. Html and the dom APIs are currently strange mix of content orinted semantic elements and app oriented (often non-semantic) elements. Not to mention that the default flow layout does more harm than good for most applications.

zmix 7y ago
> I think both applications and media would benefit > from a split of html into seperate language for > defining app-like sites, and traditional content pages. This! I would go a step further, even. The "web-applifier" community should just leave the classic web and do their own: * protocol (I am sure, HTTP is not ideal for serving apps) * GUI description language (document markup language for UI design, really?) * runtime (let them have WebAssembly and whatever they need) * each app then could have their own window, making it look like a traditional app
- thayne 7y ago
  so... like Java swing or Adobe Air? I don't know all the reasons technologies those failed to deliver, but I do think that being able to deploy from the same platform that users use to discover the app (that is, the browser) as well as almost effortless instant updates has a lot to be said for it.
Mikhail_Edoshin 7y ago
I think this was the original vision of XML: eXtensible markup language. With globally unique names XML was meant to produce a whole world of languages that could've been developed independently and mixed together in the same manner as Unix command-line tools. E.g. XSLT is a language for a XSLT processor; XSL-FO is a language for XSL-FO processor and so on. In this schema XHTML would've been a language for the browser that would co-exist with the rest of the ecosystem.