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
mozum...@futureclaw.com <mailto:mozum...@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>

Reply via email to