W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2015

Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github

From: Andrea Rendine <master.skywalker.88@gmail.com>
Date: Wed, 25 Mar 2015 01:49:24 +0100
Message-ID: <CAGxST9ndaY8ZaLBBx=DgNoPfp3r_8xrb0A98YWHQL1M697-Wdg@mail.gmail.com>
To: "Michael A. Peters" <mpeters@domblogger.net>
Cc: Bobby Mozumder <mozumder@futureclaw.com>, WHATWG <whatwg@whatwg.org>
For the first time in my life I support JavaScript. But I want to see where
this idea will go.
Here other 2 virtual cents: please, if it ends up as a way to improve the
template element somehow compatibly with the current standard, and if it
reveals to be viable, try turning it into a proposal for an HTML5.x feature
instead of brand new stuff.

2015-03-25 0:50 GMT+01:00 Michael A. Peters <mpeters@domblogger.net>:

> I see JavaScript as a useful tool that is seriously abused by many devs,
> I'm against this. But if you do it, make damn sure it has proper CSP
> support.
> On March 24, 2015 2:18:53 AM PDT, Bobby Mozumder <mozumder@futureclaw.com>
> wrote:
> >https://github.com/mozumder/HTML6
> >
> >I’ll be updating that Github with more ideas and refinement about the
> >proposal with occasional feedback into this list.  Since this is
> >getting some attention it’s probably better to place the ideas in a
> >setting that can be updated/modified than to discuss it informally via
> >email over here.  This is still at the concept phase and I’ll be
> >looking at feedback from other people as well as other frameworks to
> >see the good they offered as well as what caused them to fail.
> >
> >In this version, a key change is that I added an MREF property to <A>
> >elements to separate the canonical URL from an API URL, and a RECEIVER
> >property to specify where the API data loads:
> >
> >       <A href=“http://www.mywebsite.com/article-2.html"
> >mref=“http://api.mywebsite.com/article-2" receiver="MyArticleData">
> >
> >The MREF will maintain backwards compatibility.  You can use the same
> >web page in an older browser and it operates fine, it just won’t load
> >API endpoints, but will reload full page from the HREF.  And previously
> >I had a MODEL property in place of RECEIVER, but that's the overall
> >model’s outlet for all elements, not a receiver model, which can be
> >different.  Adding a MODEL property would load the model’s properties
> >into the HREF and/or <A> element.
> >
> >I also changed the fixtures in the example from XML to JSON.  I always
> >thought XML was more readable when mixed with HTML, but it looks like
> >people prefer reading JSON?
> >
> >Meanwhile, it looks like the people most into Javascript are against
> >this, and the people that prefer to avoid Javascript like this.
> >
> >I get that most people here are in the “Javascript everywhere!” camp
> >but there definitely is a large class of people out there that prefer
> >to minimize their use of Javascript whenever possible and just want to
> >deal with the declarative HTML system.  These are content managers, and
> >Javascript components are largely in the UI design domain, not the
> >content domain that many web developers are coming from. How many UI
> >design experts are out there?  And how many of them like working with
> >Javascript, instead of Swift or something else?  You’re competing
> >against that.
> >
> >Also I feel you shouldn’t have to prototype new HTML elements as
> >Javascript components to advance HTML.  That’s a huge barrier to its
> >development, as now you need to do that first.  Very few people will do
> >so for a standards body.  The components they make are going to be very
> >specific to their needs.  Plus, browser makers aren’t going to write
> >them, so you just forced them to wait for someone else to design these
> >components first, when they already know the problems their users are
> >experiencing and can fix them already.  And if your site can do it with
> >a custom component then why bother putting it into the standard?
> >
> >Finally, aren’t people already doing this sort of prototyping anyways
> >with the Javascript frameworks?  At a high-level, they’re all basically
> >prototyping an entire MVC use model, with just implementation
> >differences between them.  Isn’t that enough to cause HTML to be
> >updated to fit this MVC design pattern?  It’s a basic issue in the
> >design of the web.
> >
> >-bobby
> >---
> >Bobby Mozumder
> >Editor-in-Chief
> >FutureClaw Magazine
> >mozumder@futureclaw.com <mailto:mozumder@futureclaw.com>
> >+1-240-745-5287
> >www.futureclaw.com <http://www.futureclaw.com/>
> >twitter.com/futureclaw <https://www.twitter.com/futureclaw>
> >www.linkedin.com/in/mozumder <http://www.linkedin.com/in/mozumder>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
Received on Wednesday, 25 March 2015 00:49:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:29 UTC