Re: [whatwg] HTML6 proposal for single-page apps without Javascript

> Static (first-page) content is loaded from that URL, while dynamic
content is loaded from the MREF attribute’s API endpoint.  This HREF URL
would appear in the URL bar, as it does now, and you can copy & paste the
HREF URL
Apart from the fact that your message does not address any of the issues
previously mentioned, do you mean that HREF would behave as pushState, so
that URI keeps track of content navigation instead of page navigation? In a
previous post you mentioned HREF as legacy requirement, if I'm not wrong.
However, without a mechanism similar to pushState, you can't produce a
representation of how the page appears for the user. You'd end up with the
very same caveats offered by iframe navigation, without the additional
layer of security offered by <iframe>.

Can you see that? You think you're facing brand-new use cases, while what
you offer is a too complex solution to easy troubles. You could offer a
proposal such as "native pushState", instead of all the stuff about server
call at runtime.

2015-03-31 3:42 GMT+02:00 Bobby Mozumder <mozumder@futureclaw.com>:

> On Mar 30, 2015, at 6:40 AM, Martin Janecke <whatwg.org@prlbr.com> wrote:
>
> The shorter load time comes at a price. For example, these pages are
> difficult to archive by sites like the Internet Archive or WebCite. It's
> much more difficult to process these pages with bots – instead of a simple
> script reading a text file bots need to be half a webbrowser to make sense
> of them. In my perception, these sites are inherently less accessible
> because they dissociate a resource from its URI.
>
> Furthermore, my user experience suffers on these sites quite often. In
> your example https://builtwith.angularjs.org , when I navigate to "page
> 2" using the page navigation bar at the bottom, and then hit my browser's
> back button, I don't get back to "page 1", but to where I was before
> accessing builtwith.angularjs.org. That's unexpected and a bad user
> experience. I can't rely on the browser's user interface with those sites,
> but have to learn each site's individual user interface.
>
>
> In my proposal you still keep canonical URLs in the HREF attribute.
> Static (first-page) content is loaded from that URL, while dynamic content
> is loaded from the MREF attribute’s API endpoint.  This HREF URL would
> appear in the URL bar, as it does now, and you can copy & paste the HREF
> URL to save it or share it with someone over email or something if you
> wish.  So, the UX problems you describe wouldn’t occur in this proposal.
>
> Why does the web have to load full pages? That’s clunky and not app-like.
>
>
> You don't have to reload CSS, JavaScript, fonts or presentational images..
> These are cached. You only have to load a page with content and some
> structural HTML markup. That may not be app-like, but it's fine in my
> opinion, and prevents the bad user experience surprises I discussed above.
>
>
> The full-page refresh is definitely not fine.  Designers go through all
> sorts of pains to avoid it.  XMLHttpRequest exists because of it.  Not sure
> why you would find any interface UX problems acceptable?  That should be
> the highest priority, over anything else.
>
> -bobby
> ---
> Bobby Mozumder
> *Editor-in-Chief*
> FutureClaw Magazine
> mozumder@futureclaw.com
> +1-240-745-5287
> www.futureclaw.com
> twitter.com/futureclaw <https://www.twitter.com/futureclaw>
> www.linkedin.com/in/mozumder
>
>