HTML6 proposal for single-page apps without JavaScript | Hacker News Reader

HTML6 proposal for single-page apps without JavaScript

lists.w3.org

187 pointsmatthewmacleod166 comments

This proposal is trying to take a common web design pattern, MVC, and make it part of the official spec. HTML is a _markup language_, it's ridiculous to use it as anything but a semantic language.

Here's my HTML6 proposal: There’s a standard design pattern emerging via cascading style sheets, where content is styled directly via CSS. Everyone’s into it because the layout looks so much nicer.

Since this is so common now, can we implement this directly in the browsers via HTML so users can directly style their content without CSS? I propose adding a tag, so people can style their fonts, a <blink> tag so things can blink, and a fun <marquee> tag so content can scroll.

> HTML is a _markup language_, it's ridiculous to use it as anything but a semantic language.

So which is it? A semantic language or a markup (syntax) language?

Why does it have to stay that way? (Even if the proposal is a bad one.)

It should stay close to what it is because it's fairly good at its job. To make it more than that would be to generalize it away from its job into some new job. This violates single responsibility. We've already learned our lesson with that and HTML; thus was born CSS.

Making a web standard for single page apps doesn't really seem necessary. Applications are by their nature different than web sites. A web site is a collection of content displayed largely as pages that are designated by a URI. An application is an abstraction over the page model that minimizes the transparent page/resource model with an opaque process flow model. HTML, as it stands, can be the V in MVC in either. Making it take on the M or C gains us little and stands to lose us much.

> HTML is a _markup language_

It might have been designed as a language for web based documents. Though this is not what the web is used for today, consumers want applications not documents. And we are already hacking away on top of those documents to give them that (despite the web not being intended as such).

> It might have been designed as a language for web based documents. Though this is not what the web is used for today, consumers want applications not documents.

They want applications and documents, or I do anyway. I spend more of my time online reading stuff than using GMail or whatever.

Consumers are given applications not documents.

Don't speak ill of people with or <center> infatuation as HN is built on these tags. At the time of writing this comment, there's around 300 tags on the page and over 100 <center> ones

So, basically watch what you say buddy :)

, I don't think there's an excuse. we know for sure that it is not out of incompetence but it was probably easier to write at the time and nobody bothered to fix it because it doesn't really matter.

For the <center>, it is probably not the case here as this is just a text based site but sometimes it is easier to center an image by that tag when your site is partitioned in many margins it is not as easy to center some stuff, or you might just prefer to add a tag.

I also like , it really makes more sense to me and easier to write. It doesn't really break anything either.

I wonder how many there are, like me, think that <center> and are actually really nice things to have?

Not many but they're deprecated/obsolete for a reason, don't you think?

Perhaps not many in the design community or front end devs, but I'd wager there are plenty of developers who love because it's what they've always used to do simple layouts so they can get back to the back end.

br is neither deprecated nor obsolete

HECK YEE! I even put classes in my tags so I can get at them and decide when and how they display!

HECK YES! I even put classes in my tags so I can get at them and decide when and how they display!

There's nothing wrong with font tags on HN. You might not realize that the pages served on this site are machine-generated!

I agree. Its just they could add a class to css, and instead of setting font tag to each element, just add the class. But of course, since they are generated in a loop anyway, there's no practical difference.

Just clicked "view source" on this page out of curiosity. I feel like I just traveled back in time to 1996.

hacker news is predominantly pre-CSS style code, e.g. the only CSS seems to be basic fonts and the upvote arrow, both of which the site would barely be different if run without CSS. Here's their only stylesheet: https://news.ycombinator.com/news.css?vaRvmIYYFOCsNxY80y43

Lots and lots of very bad ideas here -- backwards-incompatibility with previous versions of HTML is always a good litmus test that a proposal hasn't been thought through, as is "hey let's restructure everything around this one currently-fashionable design pattern". (I kind of love how he just casually embeds a SQL interpreter in the browser, too, that's a nice finishing touch.)

But the main thing is that this doesn't solve any problem that exists. We can already do everything his proposal would enable; all this does is make it more inflexible.

There's an "upvote" button, just to the left of the comment above.

You shouldn't use the upvote button for agreement.

On the other hand "+1" and "I agree" and "Well said!" clutter the forum.

How do we solve this?

Honest question: If not for showing agreement, what is the reason for the upvote button?

I thought it meant "nice contribution to the conversation". It's easy to come to this conclusion when you think down-vote means "you're not contributing". I up-voted many comments I totally disagree and down-voted many I agree (because they were unrelated to the discussion). Am I a minority?

Well, the HN guidelines[1] do not mention any rule as what constitutes 'right' voting criteria. As a regular HN user of over 6 years it feels even surreal to be in a discussion about the basic features of this wonderful platform. It's never wrong to question the basic premises of life, though(;

I do believe we have the a similar kind of understanding for when to up-vote. What is a 'nice contribution to the conversation' other than arguments or facts that 'I do agree with' in them being a nice contribution to the conversation.

I fear we would have to have a meta-discussion on the concepts of good and bad and how they are flawed in that there are no montains without valleys^^

1. https://news.ycombinator.com/newsguidelines.html

what's wrong with upvoting with agreement?

Upvoting based on "this comment brings up good points and arguments" rather than "this comment says things that I think are true" helps fight against the community becoming an echo chamber.

We downvote despite "good points and arguments".

The community is in many ways already an echo-chamber; that battle was lost a few years ago. Don't let it bug you.

Isn't "good" just as subjective as "things I think are true"?

The problem isn't subjectivity, it's groupthink. "Good but wrong" posts are better than "bad but correct".

Exactly. It's not that interesting to be in a forum where people are only awarded for being in line with the popular opinion. The alternative is to award constructive contributions.

Add a separate +1/thumbs-up button next to the arrow. It doesn't really need to do anything more than show that people are in agreement (better even if it can do it without showing numbers).

The line between "upvote for good point" and "upvote for agreement" can be blurry, same for downvoting.

In either case, both are accepted uses. PG has said as much:

https://news.ycombinator.com/item?id=117171

Interesting. I guess I was a bit too quick with my previous comment then.

However to me it feels a bit like discouraging alternative opinions, when they are hidden/greyed out.

Is this commonly accepted then?

pg himself has (unfortunately) stated that the downvote button is usable to signal disagreement.

It makes sense, then, that the upvote button be used for agreement.

-1

+1 I agree.

There isn't if you have already upvoted.

I agree, I think there are real problems in modern web development, but they aren't in replacing javascript; they should be focusing on ideas like the shadow Dom that make things that weren't possible possible iMO, and leave these kinds of improvements to userspace frameworks built on their new features.

Absolutely agree. I got that about 3 seconds into reading this. For example, I'm close to releasing a SPA application platform. Yes, that is "application" twice. This proposal doesn't square at all with what this next generation application platform is all about.

I visited the author's site in the signature (futureclaw), and it's not exactly a slick experience. Front page doesn't let me use space to scroll it; 'more fashion' page looks janky and out of order, and has a wide scrollbar that requires mouse work; click through to Coach Men's Fall 2015 and we have a page that takes forever to load, a scrollbar on the left which does nothing when it's moved; and now I notice a side-scroll at the very bottom, which scrolls me through all the pages I've visited so far (the previous issue is actually the scrollbar for the 'previous page'), including a large thumbnail page I never visited; a side-scrollbar in the middle of the page to scroll through the model's pictures, but no other controls visible...

This is definitely not the site I'd have in my signature when talking about the emerging trend of single-page apps and proposing a new standard. It's such a non-standard site, and feels clunky and clumsy.

I'm not necessarily opposed to something along these lines, except that it's basically already been tried: XSLT was essentially the inverse of this, where data endpoints were annotated with some static rendering descriptors. To me the XSLT approach seems cleaner, in that the URLs the browser is visiting are for the raw data itself, the URL scheme between machine and human is identical, and so on. XSLT also encouraged producing network-friendly compound representations for data, rather than the typical small collection of pure CRUD endpoints over fixed structures (/users/1, /comments/1231, etc.), since XSLT had limited ability to trigger loading external data without falling back to Javascript hacks or similar.

But I imagine the tragic flaw in both the data binding proposal here and how XSLT worked is massively increased complexity for fairly little gain - and I think that's why XSLT has died a gentle death over the past decade.

Still, both ideas appeal to me from the perspective of escaping horrendous chunks of procedural macros being shipped with data just to make it render on the client.

Yep. I used to love XSLT -- working in it finally forced me to understand recursion at, like, a deep cellular level -- but the whole time I was using it I knew it was a doomed language (because most people don't want to have to understand recursion at a deep cellular level just to be able to lay out a damn web page.)

Yet, alongside XHTML it would allow to move HTML to a proper layout engine like most native GUIs have, instead of the hack-a-mole we have to deal with.

XSLT is still good to learn -- I think it's conceptually sound, but its implementations are often terrible. I think the big pain points for most people are how finicky XML is in general, but also that any libs you use to generate your XML and translate it require an absurd amount of configuration. Years ago, I saw all the weaknesses in mixed PHP/html for building pages, but all the server-side templating languages looked terrible (still do). I fell in love with the idea that was championed back in the late 90s, where you use your application to build XML, which only describes your data. You'd then have some XSLT on your web server (or in-browser) that would transform the XML into your document.

Nowadays, this isn't that different of an approach from using my server-side PHP/python/node/Go to generate JSON, then building my DOM based on client-side templates; since I use ReactJS, my transforms are even still XML. A lot of the best-practices I learned from XSLT transferred over nicely too, e.g. avoiding control logic (<xsl:if>) in favour of <xsl:apply-templates>, since good javascript client-side templates should avoid branching control logic in favour of just Array.prototype.map() wherever you can.

I think the real key isn't about understanding recursion, though you will gradually gain an appreciation for it, but understanding composition. Templating is too often done in the style common among poor developers, where they think about building a whole "page", instead of defining the components of that page. XSLT, in theory, would've been great for that, it's just a pain in the butt to actually implement.

tl;dr if there is a need for this proposal, it would be better met by cleaning out all the cruft from XSLT, and building implementations that don't require such arcane syntax nobody can use it.

Agreed re composition -- the sign that the language had finally 'clicked' was when you started seeing lots of little xsl:templates instead of one gigantic mass of if statements.

I don't really agree that cruft or configuration difficulties were the problem, though. Verbose, sure, fine, but otherwise spare to a fault.

I suspect it's more that it demanded understanding of fairly sophisticated coding concepts to be at all useful, but was too often perceived as "front end" tech, or as just another markup language -- so ended up being dropped in the laps of too many designers-with-a-few-javascript-recipes-under-their-belts who simply weren't equipped to cope with it.

I spent a while running XSLT training sessions for a corporate client; 95% of my trainees would just reel away in disgust and confusion the instant they learned they wouldn't be able to, say, increment a variable. (The remaining handful would be all OMG THIS IS WHAT I HAVE BEEN WAITING FOR MY WHOLE LIFE. It got to be a little game of mine to try to predict ahead of time who would be which.)

Maybe it was just ahead of its time; the average front-end web developer is a lot more sophisticated these days than we were back then. (yes yes get off my lawn I have clouds to shout at)

Count me among those reeling in disgust: XML is unpleasant to work with, XSLT just adds layers of complexity on top of that.

I wrote transforms for the few cases where I needed straight XML-to-XML conversions, but anything of complexity I retreated to a "real" language. It's obviously a personal choice, but I find working in XSL/XML like running through mud.

The success of JSON is due in part to the low signal-to-noise inherent in XML, and maybe XSL's low popularity is likely due to the necessary complexity of dealing with unnecessarily noisy data. I sometimes daydream about a present where YAML got there first.

XSLT is conceptually sound indeed, a transformation of tree structures. But the requirements and real-world usage cases thrown at it are often terribly suited for it.

Real applications just don't fall neatly into tree transformations. I inherited a financial reporting web app using XSLT as the rendering mechanism. Requirements included things like running totals (state!), suppressing leading values when repeated between rows (also state), alternating row colors, external dependencies such as numeric formatting based on user's locale settings. A stateless tree transformation doesn't express that elegantly, so you end up with fantastically complicated and ugly XPath hacks. A running total would come from something like "sum all my parent's children with an index less than mine". Then that breaks when something comes up to introduce a need for another layer beneath that parent.

XSLT is purely functional. <xsl:if>template</xsl:if> isn't even control logic, it is functional evaluation, the same as Lisp's (if x template nil). <xsl:for-each> also isn't an imperative loop (it's map) even though it looks imperative and most enterprise programmers trained on imperative languages think it is and use it as such. So it's no surprise that XSLT in the wild ends up as a messy ball of mud.

Most templating languages have this problem, including PHP/HTML. The messy nature of real requirements isn't unique to XSLT. But XSLT manifests it most dramatically since it lacks a stateful and imperative framework to fall back on.

Just in case you're using XSL still, you could use <xsl:key/> to let you quickly do subtotals by summing the node set of items that match whatever grouping level you're on when you emit the last item in the group.

  <xsl:key name="items-by-order" match="item" use="../@orderid"/>

  ...snip...

  <!-- Union current item node with last item node of the order - if it's the same, the count will be one -->
  <xsl:if test="count(. | key('items-by-order', ../@orderid)[last()]) = 1">
    <xsl:value-of select="sum(key('items-by-order', ../@orderid))"/>
  </xsl:if>

Running totals would be similar, except that your apply-templates for the item group would include a select that restricts the available nodes to the key() function's result, and you would sum current node with preceding nodes.

I built a whole website based on spitting out XML and using XSLT on either the server or (optionally; hidden behind a flag) in the browser to transform the XML to HTML.

It gave us 90% of our API "for free": On any page you could add an argument to the URL to spit out the XML data for the page, and others to get the items on the page as ATOM or RDF.

The developers hated the constraints it placed on them. But it was exactly because of the things the developers were prone to doing that was the reason for structuring it that way in the first place.

I used to despise XSLT. Actually, I still do. As a front-end developer I found it absolutely horrid to work with. I jumped ship on that as soon as possible.

But if you like it, that's cool.

XSLT is a good idea, everything else about it is just tragic, especially the language to the point I would support Nuremberg style Trials for this kind of events in computer history.

XSLT is a good idea with terrible implementation IMO. There's language called cduce. I'm not sure if it alive but it was interesting alternative implementation, though it was too much academical to be practical. But there could be usable language for trees transformation. Overall this idea is much better than current state of things.

> XSLT has died a gentle death

Maybe it is not because that XSLT is complex, but because XML has failed to become a language for the web. JSON has come to be the preferred choice.

Which brings me to JSON and complexity: The complexity of retrieving data has been paved over multiple times using libraries. This has encouraged people to skip XML and go directly to JSON. If retrieval of XML data, or better yet JSON data, were to become simpler, I think more people would structure their webpages to use these types of resources. In the end, it would be a victory for both open Web and open applications.

And that brings me to my last point: Dynamic elements. This web ain't succeeding without variable based dynamics. These pathways for dynamic behaviors have to be baked into browsers from the start. Then let JS abuse that dynamic just like JQuery abuses attributes, styles, and content.

I think before someone goes putting JSON in even more places we should agree on a format for serializing dates, personally.

XSLT was an interesting language that unfortunately tried to solve the wrong problem. What we needed was AWK for the DOM. Instead we got a vision where XML would be used to transform other forms XML into yet OTHER forms of XML, and the result was a mess.

I think there's still a place for an "AWK for the DOM". The XML extensions to gawk are interesting, but not really what I'm talking about; it works at a lower level (more like an "AWK for SAX"). jQuery comes closer to what I'm talking about, but I still wouldn't really call it a clean match.

That's a good idea - keep XPath but lose the XML based syntax.

Edit: In fact, lose the XML completely and go with JSON and JSONPath.

The use of XMLHttpRequest to fetch JSON has come to dominate to the point that people seem to forget that it had any other use, but it is worth occasionally reminding people that the original purpose was to fetch HTML, which the browser turned into DOM nodes via its fast parsing path, which could then be added to the page via DOM manipulation.

I fully realize this is not what the linked page is proposing, but it is not clear to me that using that wouldn't be a better idea, leaving the selection of templating to the user. Template languages, while smaller than programming languages, share their characteristic that there isn't obvious One Solution That Solves Everything. You can optimize them for different use cases and it is not clear to me that we can or should privilege one over the others. Given how rapidly the web is heading away from an overprivileged programming language being the only choice, this seems like going the wrong direction.

(Also, if your template language is slowing your server down, fix that. That's a problem with your implementation language, not the fundamental concept.)

Uh, the original purpose of XMLHttpRequest was to fetch XML, as its name implies.

AJAX stands for Asynchronous JavaScript And XML

I'm not able to substantiate this with links, but I believe the idea was that the "XML" in question was going to be XHTML most likely, rather than generic "XML", though it did support the generic XML use case. I could be wrong, if the original Outlook web interface this was supported for really did return XML that was not XHTML at some point.

It was a crazy time. XHTML was still "inevitable", and people were pretty sloppy with the terms.

Wrong.

It was called "XMLHTTP", created by Microsoft for Outlook Web Access 2000. Mozilla implemented it as XMLHttpRequest JavaScript object in Gecko.

The main reason of XHR/AJAX was XML, but Text and HTML are supported too.

See Wikipedia for the correct history:

http://en.wikipedia.org/wiki/XMLHttpRequest

Microsoft never implemented the XHTML standards in Internet Explorer. IE cannot open files with .xhtml file extension and with .htm(l) extension the page is rendered with HTML quirksmode.

Any idea what the MSDN tree view used in the 1998 timeframe? I know it loaded the contents on demand when you expand3d a node and I remember it doing so using an automation object with CreateObject.

MSDN used HTML4 frames for a long time (afaik until ca. 2006). The left side bar (left frame) with the tree was a Java applet and with the relauch in 2000 a DHTML page. The tree was expanded using DHTML (a marketing term that describes HTML with heavy Javascript usage). Javascript was used to change the visibility of DOM nodes (tree). That data of the TOC tree was loaded as XML (XMLHTTP).

Article that explains the MSDN server backend (1999): https://web.archive.org/web/19990505061257/http://msdn.micro...

Before that relaunch in 2000, the MSDN library used (MS) Java for the left side bar (TOC tree): https://web.archive.org/web/19990423231040/http://msdn.micro...

The DHTML version of MSN library (2000): https://web.archive.org/web/20000510200809/http://msdn.micro... , the 2001 version works: https://web.archive.org/web/20011108064645/http://msdn.micro...

XML toc tree data: https://web.archive.org/web/*/http://msdn.microsoft.com/libr... (sadly not archived)

XHTML is XML

Theoretically, yes! In practice it isn't, because people are sloppy.

Other members are worried this is just shifting complexity for no real value. A mistake they did in the past.

https://lists.w3.org/Archives/Public/public-whatwg-archive/2...

My opinion too.

These single-page apps are becoming pervasive but they are also fundamentally breaking the internet. Here are some common ways in which they are broken:

1. History is screwed up. You wanted a back button that took you back to the content you were looking at? Sucks to be you. The content you were looking at was dynamically loaded after ten different buttons you clicked, and now that the page is loaded fresh those button clicks are gone. Good luck finding it again. This especially goes for any of those infinite scroll websites: those should die.

2. Tabs don't work. Hey this link looks interesting, I'll open it in a new tab to look at later. Oh wait that was actually a JavaScript link and what often ends up happening is you end up with a blank page, or the same one page app loaded with it's initial content.

3. Save page doesn't work. You can save the page and pull it up and everything works because the JavaScript fetches the content. But there's one problem: I was saving that page to view on the bus where I have spotty internet if any. Sucks to be me.

4. Accessibility is broken. Oh, you're blind? Arthritic and have trouble using a mouse? Well, sorry, we had to size things in a certain way to make the animations work and tab order was too hard to get working, so I guess you can't use my website. Sucks to be you!

5. Security is broken. If you app loads content from a server that isn't yours, you can no longer verify security.

There are solutions to all of these problems but they're very difficult and 90% of one page apps don't solve these problems because they don't care.

I'm not against one page apps on principal, but a one page app standard that doesn't address these concerns is only going to make them worse. Unless we can solve these issues I'm against any one page app standard.

I agree with you in principle that if apps don't meet 1, 2, 4 & 5 they shouldn't see light of day but I think your points are largely spurious or handled by any semi-competent dev.

1 & 2 are a basic feature of JS MVC frameworks. I get that some people still probably mess this up, but there's no excuse to do so at this point. 3. Irrelevant/FUD? No normal user 'saves' web-pages, unless it's something like a receipt, which any sane dev would make a separate html page and not part of the app. 4. is totally false as screen-readers support JavaScript. 5. is false/strawman as any half-sane SPA developer still authenticates using a regular back-end framework and I've no idea what 'If you app loads content from a server that isn't yours' has to do with single-page apps.

> 1 & 2 are a basic feature of JS MVC frameworks. I get that some people still probably mess this up, but there's no excuse to do so at this point.

I'm not sure what it would even mean for this to not be broken in a one-page app. If you're displaying more than one conceptually grouped set of content on one page, you're breaking the web's concept of a page: a page is one conceptually grouped set of content. JS MVC frameworks allow you to back and forward between "pages" within a page using the hashed href trick, but they can't keep your scroll location without rendering the page to determine layout, unless there's some magic I'm not aware of.

> 3. Irrelevant/FUD? No normal user 'saves' web-pages, unless it's something like a receipt, which any sane dev would make a separate html page and not part of the app.

I love when people tell me that nobody does what I do all the time. And it's not just me: a lot of people save pages for later reading, especially in academia.

> 4. is totally false as screen-readers support JavaScript.

Yes, screen readers support JavaScript, but JavaScript rarely supports screen readers. It's clear you've never actually attempted to browse the web using a screen reader.

> 5. is false/strawman as any half-sane SPA developer still authenticates using a regular back-end framework and I've no idea what 'If you app loads content from a server that isn't yours' has to do with single-page apps.

JavaScript security is a fucking joke. I'm not sure what you think authentication does when your JavaScript is running in the same namespace as all the other JavaScript in a page and malicious code needs simply to tell authenticated code what to do to spoof an identity. A server can do nothing to provide security when the requests from a browser are coming from an authenticated user (but are actually made by malicious JavaScript in the page).

Plenty of apps include advertisements from arbitrary sources, hence loading content from a server that isn't yours.

I totally agree. It's too bad a compromise. If you want Google to crawl your site it should be server-generated HTML. If you want apps, make actual desktop/mobile applications.

Honestly, looks too complicated. I'm doing AJAX without custom JavaScript right now. The way it looks:

You submit the form, it loads the result in the background and replaces content of Y div with content of whatever has id="y" on the new page.

splice-result-into takes any CSS selector as its parameter, so you can apply this to multiple elements at once.

The entire library is around 100 lines of code with no dependencies. 100% backwards compatible, degradable and easy to add to existing multipage apps. It could easily be implemented as a standard HTML feature.

This is why you don't let "Editor-In-Chief" do web development. Sounds to me like someone's too lazy to learn JavaScript. When will people stop trying to make HTML into an all-in-one product? It was built to be simple, to provide markup and that's it. That's the magic behind the troika of HTML-JS-CSS. They all deal with individual, meaningful functions to make a site work. Blending function with markup is just bad coding. Thumbs down.

Have seen several tries on this approach:

- Angular seems to provide something similar already with its ng-* attributes and directives.

- JavaServer Faces also do the same thing, where a server-side controller is bound to HTML or UI widgets (and skip writing CSS and JS because they're pre-styled, pre-programmed).

This works for simple stuff, but for much more complex stuff (multiple view interactions, custom views), this becomes a pain to write because you start to create workarounds for things it wasn't prepared to do.

Also, while I'm no expert, but let's just leave HTML, CSS and JS as is. You can always create a framework that provides you that same functionality. In fact, Angular has directives, React has JSX, Ember has components. Several other frameworks do it as well.

Reminds me of E4X, where they tried to bake in XML syntax into JS. This time, it's behavior and logic into the markup. Nope.

“<A href="sql:select from *”>"

An anti-pattern if I've ever seen one.

Yeh my thought when I seen that was "...what could possibly go wrong..."

I really don't like this proposal. For me, HTML is the markup for the design of the page, while JavaScript makes up the logic. While some frameworks break this, they are strictly opt-in, and they still offer a bit of separation of duties. I'd rather see the HTML standard stay markup-focus for now.

I wish strict XHTML was taken more seriously.

HTML is the structure, CSS is the look, and JavaScript is the logic. With a strict XHTML style you can further enforce this by removing former standards which don't follow that design (e.g. OnClick="" etc).

HTML5 is alright, but I'd like to see a strict HTML5 which bans a ton of classic HTML4.1 elements completely and also follows XHTML's much more logical style (and bans things like which make no sense).

I understand why they went the way they did (backwards compatibility mostly), but feel like the web would be in a better place ten years from now if a strict spec for at least HTML was commonly used.

Strictness accomplishes nothing whatsoever. If you remove presentational elements, people just abuse semantic elements.

I would make parsers and generators much easier to write.

But there are millions of pages that will never be updated and if a browser can't render them people are going to blame the browser, not the use of deprecated HTML elements (an issue they won't even have awareness of).

That's just a generic argument for no new HTML ever.

No it isn't; it's an argument against breaking changes.

> Strictness accomplishes nothing whatsoever.

Sure it does, it means it is impossible to mix logic or styling into your HTML inline. That makes HTML more maintainable and teaching it easier (less is always easier to teach than more).

What semantic elements are you worried about them abusing? I cannot think of a semantic element which replaces defunct presentational elements without any CSS (which would makes the entire argument redundant).

<del>

em and strong would be removed in a strict HTML5 standard. All stylised elements would. Span wouldn't as span doesn't impose styling directly.

and are semantic, not stylistic.

Strictly speaking, HTML5 did eliminate all presentational elements; formerly presentation HTML4.1 elements retained in HTML5 were redefined as semantic elements.

Many elements (even ones that were always, even before HTML5, semantic rather than presentational, e.g., <a href="...">...</a>) have common default presentation effects in most browsers, but that doesn't make them any less semantic.

I suppose you could strictly separating presentation from semantic by requiring conforming user-agents to apply no styling differences to any element other than that that provided by CSS (e.g., every element would have the same default presentation.) But its debatable whether that gets you anything useful other than purity for the sake of abstract theory.

I don't want to be flippant here, but anyone who thinks you can build a high-quality UI with a solely declarative system hasn't built very many UIs.

This is interesting, but like others I think HTML should be kept strictly for templating, and this adds an unnecessary amount of logic. It might be tempting to see this as removing complication, but in actuality it will probably add to it by reducing separation of concerns.

I think it would be good for less ambitious projects, but in the end it would cripple the building of more ambitious ones. If we already have Angular/React/Components/Whatever, shouldn't we just keep working on them and leave the HTML spec unpolluted?

HTML does not do templating, either.

I'm just going to leave this here:

https://html.spec.whatwg.org/multipage/scripting.html#the-te...

That's really just an alias'd script tag. You are still using javascript to actually do the templating.

Too bad, this is already implemented as a standard (cough-cough Mozilla) as part of Web Components.

http://www.html5rocks.com/en/tutorials/webcomponents/imports...

Reading the comments I felt many people thought this is an official recommendation. It's the mailing list folks, the same place where somebody suggested to replace JavaScript with AS3 because it would solve every problem of mankind.

That was my initial thought. Also you can basically declare any custom tags ( with dash in the name [1] ). Which with some good javascript could accomplish easily ( and I would say in more clean way ) what it's being offered by the OP.

If he likes this kind of writing his AJAX implementation he can easily do so by doing his own framework.

I think HTML5 is doing pretty, pretty good and it's underestimated in what it can be achieved.

[1] http://www.html5rocks.com/en/tutorials/webcomponents/custome...

Instead, why don't we eliminate the need for Apps in a browser to require HTML. Right now, our large scale app has one div inside the <body>. It's just an anchor for our SPA built in React js. We should push for browsers that can launch from a .js file, rather than requiring html. Have a base UI.kit that can even keep css, or use javascript to stylize. I'd like the 'base' UI to be as skeleton and simple as possible. We can keep the <html> style markup, but with javascript first. Similar to what JSX does with React. This would also fix the DOM problem we are currently stuck with. This is a rough, quick typeup, thoughts though?

EDIT: and most importantly, get multi-threaded javascrip in the browser. Running the UI, events, and logic all on separate threads. Many observe patterns would most likely be used.

> Instead, why don't we eliminate the need for Apps in a browser to require HTML.

Accessibility.

A canvas accessibility api would be great.

Touche, love the user name. Yes, right now it would seem impossible and browsers would have to support backwards compatibility. What I'm saying is let browsers still support regular html sites. In addition though, be able to specify a 'javascript app'. I see no limiting reason in modern browsers why this would be an issue. At some point, the web has to move forward and say, 'sorry, if you are not running JS, we can't really support you'. Yes, I know the backlash that would come, but we've got to move forward, maybe there is a better way? I'm not sure.

(My project does not require supporting anything below IE 11, it's the greatest blessing, ever.)

All major native UI toolkits support accessibility as required by many governments.

Single page apps seem like a hack to make browser apps feel like they are closer to native apps. Because most SPAs have a set flow, it seems like we should be able to use prefetching to tell the browser what is most likely to happen next. For example, if you are on a list, then you can tell the browser to prefetch the details.

What I feel like is missing from this equation is a nice transition between pages. How nice would it be to have something like this:

<a href="details.html" transition="slide-left">Details</a>

If the browser prefetched the details and handled the transition, I would see no need for an SPA. We would get the benefits without having to implement a hack.

So if you have a list of 100 links you are going to prefetch all 100?

No, that is not really the use of prefetch. It is for more predictable flows.

And today you can use that markup and shim the transition you want with js - and still gracefully downgrade.

But wouldn't having it in the HTML mean you don't need the js? And then it wouldn't need to downgrade in modern browsers at all.

If you want to change the HTML spec and have something happen, you'd have to upgrade the browsers before anything happens... rel-links do work today, but transitions don't automatically work, and UI/UX (using the "forward"-arrow to go to "next" etc) is inconsistent or non-existent. But you can write some js to make them all work. And your HTML can be semantic and nice, and you can still get advanced features.

I couldn't tell from your post, so just in case you weren't aware, browsers do support prefetching documents via link tags: http://www.w3.org/TR/html5/links.html#link-type-prefetch

Chuckles IE used to support this with something called Inter-Page Transitions [1] - every time I saw it it made me double-take.

  <META http-equiv="Page-Exit"

CONTENT="progid:DXImageTransform.Microsoft.Slide(Duration=2.500,slidestyle='HIDE')" />

That said, I wouldn't go down that road again. Better pre-fetching hints are good and HTML is a good place for a fallback (HTTP 2.0 provides better ways of doing it if you have control of the server), but page transitions are something better left to CSS, to my mind.

[1]: https://msdn.microsoft.com/en-us/library/ms532847%28v=vs.85%...

> Everyone’s into it because the responsiveness is so much better than loading a full page - 10-50ms with a clean API load vs. 300-1500ms for a full HTML page load.

Maybe if you start with an argument to support your claim, you want to have actual numbers. And those real numbers would tell a different story.

Great, now I need 3 years experience in it by the end of the month

No kidding. I just started learning Angular, and now this.

Fortunately, it sounds like it will die an unpopular death.

I see three problem here, none of which have anything to do with HTML as a markup language.

1. The amount of DOM manipulation required for a relatively advanced single page app is not very efficient, quick or performant.

2. Web apps don't work well without a reasonably up to date javascript engine - users may not even allow Javasacript to be run. This breaks alot of web apps.

3. There isn't an (easy) way to request parts of a resource easily using HTTP.

Luckily these issues have solutions:

1. Invest time in a new successor or radical improvement over the current DOM - think an asynchronous, thread safe API. Fix things that deal with HTML, don't try and make HTML anything more than a markup language.

2. Either make your web apps fallback to HTML + CSS or start convincing people that using Javascript isn't a huge privacy issue. Fallbacks can be easy if you want them to be.

3. I'm sure there are way to request specific parts of a page (indeed, I coded such a way myself in PHP a few years ago), but someone needs to build an awesome abstraction over HTTP to make this easier.

> Either make your web apps fallback to HTML + CSS

So make two Web apps with the same functionality, basically?

Or make one app with an isomorphic base which gets progressively enhanced when JavaScript runs on the client.

Yes, but if you're doing a true "SPA" then "progressive enhancement" really does just mean having two versions of everything.

Not any more - once you can prerender the "SPA" on the server and use the same codebase to rehydrate it on the client and take over - which you can do today with React and soon with Ember - then with the right setup the "progressive enhancement" bit can be "am I on the client now? let's do some extra stuff" implemented as part of the same component.

e.g. here's a form that uses the same React component to render on the server, to handle regular form submissions and render redisplay when invalid and to progressively enhance with live validation and ajax form submission when JavaScript is available on the client: https://isomorphic-lab.herokuapp.com/add-thing

I'm Sure a lot of single page app features have a simple fallback - things like tabs, sliders, carousels and most navigation can be done with just html + css.

I think we should keep HTML simple and enforce a strict separation between template and logic. However, I do like the idea of adding a native "model" attribute to the DOM element that can automatically get/parse json and update accordingly.

Have you ever used React? What do you think about the React/Flux methods of mixing template and logic?

Good point. I do use react and I find jsx to be very convenient. I guess the question is: would I want to write something similar to JSX and have the browser be able to interpret that natively. I honestly don't know.

Yeah, I'm ambivalent myself.

The main problem with W3 standards is that they assumed they knew what we'd want to do with them. No one predicted HTML would become the UI layer for complex replacements for desktop applications, so for a long time, it sucked at that job.

Now they're trying to rectify those mistakes, but I think they might be going too far in the other direction.

Instead, web standards need to be as simple, low-level, and generic as possible. The more HTML approaches an opinionated UI framework, the worse off we all are (in my opinion).

Model references are defined so that it can call any object, with the ability to define conditions to access objects, perhaps looping through lists of objects via SQL select statements and using TEMPLATE tags to create new DOM objects.

What - the - fuck

As someone who thinks about making a HTML/CSS/JS replacement at some point in the future, I look forward to these guys completely fucking up the standard.

I'm pretty sure this is similar to meteor js and transparent reactive programming, except just getting rid of the templates and using html instead. I don't think he realizes it that way, bc he keeps mentioning wanting to not have to use js.

I would be down to have a nice standard way of providing templates , adding onto html thus keeping it backwards compatible but that's it.

what he's proposing could be could be backwards compatible

I don't like this. I would like to see a standardized html way to load html partials into other html, similar to ng-include. I think that is clean. But to start mixing logic? How are you supposed to render a JSON array loaded via ajax? How do you put in authentication information or headers? How do you do error handling? This is the stuff that is handled by angular or ember or knockout or aurelia or etc.

I definitely don't like this proposal. SPA:s is under a heavily innovative period. Standardizing it will only slow downs its' development.

No one will force you to use it, browsers have always been reasonably backwards compatible, except regarding stuff like ActiveX, applets, and HSTS.

I always thought XSLT has some SQL-like capabilities and I have always been angry that one can't simply pass a parameter to the interpreter via link. The idea being that menus could become active just by having links specify an item selected when they are clicked on and reload the same page. It's one little tiny thing (passing the parameter) that could make dynamic static pages.

I'm very skeptical about this. HTML is a fixed language for reasons. It is not supposed to be able to parse a JSON file.

Am I mistaken, but this kinda looks like XForms. Why not just use XForms?

Edit: Obviously I understand that XForms isn't a viable option these days, but that is kinda my point. Why isn't XForms an option? Those reasons appear to apply to this proposal too...

Because XHTML was killed, when it could have become the XAML of the web, so the circle comes back to "another day another hack".

“All DSLs grow in complexity until they are Turing-Complete, then JWZ’s Law takes over.”

There are some dangerous thoughts in this thread, for example: https://lists.w3.org/Archives/Public/public-whatwg-archive/2...

"These javascript frameworks are all trying to do this, but none of them do it easily and they’re always being redesigned."

Things are being redesigned because there are flaws and limitations. Making something, and stamping it as "HTML6" doesn't automatically make it perfect. It would simply hinder the development further.

Yes we have to make the html and css more dynamic for single page application because it will take less time and single handed coded by the developers. So in this time we have to use frameworks that have some additional features that we dont use in our website or application we use some of them which is really suit to our need and there are lots of browser having compatibility issues if html and css become more dynamic and independent the compatibility issue will be solve and we dont need for extra time for using plugins and make them for our needs.

What happened to web components ? isn't supposed to solve these issues ?

I wonder the same. Isn't that the quasi standard way of doing this?

What is this moonspeak?

Modern web apps do so much more than what this proposal is trying to solve.

React + Relay/GraphQL is much more likely to be the next real big step forward on the horizon of web/app development.

Technically, I don't think it would be very useful except for apps that are simple state machines. If you want something Turing-complete, you might as well stick to JavaScript.

Has anyone looked at the source of his site? www.futureclaw.com

Goddamn, that's atrocious.

The worst site I saw in 2015, it's broken in IE11 and Firefox.

Or are all the double and triple scrollbars intentional? And the code, the "Editor-In-Chief" seem to be stuck the 1990s, with all CAPS HTML tags and HTML 2 style code.

Man, serioulsy? This is the worst site I've seen in a while!

HTML is like violence. If it doesn't work, use more.

It is pretty funny these years, cause app(qml, for example) really wants to be web, and web(single-page-app-like web) really wants to be app.

I'm sure no one wants to go down this path.

Why mess with the amazing separation of concern that exists between HTML, JavaScript and CSS.

Don't agree with this. I think improving Javascript's API for the DOM is a much better path forward.

A naive attempt to do the same we do now just waaaaaaay more inflexibly.

The author needs to watch this a meditate on why Alan Kay said what he said about the web architecture: http://youtu.be/oKg1hTOQXoY

It seems it is the same idea behind Polymer's core-ajax, what do you think?

https://www.polymer-project.org/0.5/docs/elements/core-ajax....

One of HTML's largest flaws is speed. Can't we work on making the DOM faster?

HTML's DOM isn't slow, it is the CSS which makes it slow. When you manipulate the DOM the vast majority of the time spent regenerating it is in CSS, the raw node tree itself is fairly cheap.

Thankfully this looks like it is never gonna happen, and is instead just a random suggestion posted to a newsgroup (which carries very little weight/credibility).

In my judgment this feature is highly redundant and unnecessarily complicated.

Among all the other reasons why this is bad, i think that guy never had heard about different environments (production, staging etc.) API URL's in mark-up, yeah

Why not DOM streaming or lazy DOM? We don’t need HTML6.

Nice, now it only needs some scripting language. I am sure you could invite something in a few days....

WTF?? Please please, just start over!

Its not completely to replace Javascript but basically a standard to load HTML like iframes except its not.

spa apps are more complex that the example. Sure it looks it could work but the amount of logic within an SPA is not just a simple click here , fetch json , replace html fragment. The title is a bit misleading. I don't think it's possible to do SPA without Javascript.

This must be a joke. Why force a design pattern on anyone who wants to create an SPA?

I don't like this proposal. An SPA is more than just getting json from a server.

As for a name... Single-Page Apps Without JavaScript = SPAWJS. Or just SPAWS.

Never too early to start work on something we'll see in a couple decades.

so...iframes?

... except instead of loading arbitrary url he actually proposes some structure. This could work for most websites depending on ajax to load their content. Say, instead of xml you get a language similar to django templates.

Too many new people creating web pages these days ignore the science behind it all.

Reply on news.ycombinator.com