- From: Michael A. Peters <mpeters@domblogger.net>
- Date: Tue, 24 Mar 2015 16:50:48 -0700
- To: Bobby Mozumder <mozumder@futureclaw.com>,WHATWG <whatwg@whatwg.org>
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:26:01 UTC