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

[Bobby Mozumder]

> On Mar 24, 2015, at 10:57 PM, Matthew Sotoudeh  wrote:
> 
> Hello!
> 
> By way of introduction, I'm an author who reads some of these mailing lists 
> but (almost) never replies.
> 
> 
> 
> This proposal is quite interesting, wanted to throw in my two cents as well:
> 
> 
> 
> 1. Would you consider writing a polyfill/Javascript framework for this? 
> It seems to me that the fundamentals of the proposal could be fairly 
> simply written into a small Javascript polyfill by intercepting a[mref] 
> clicks and filling up s. A working polyfill would give 
> people a chance to play around with the proposal, give you (and others 
> who like the idea) a working implementation of it in case it doesn't 
> become a standard, and provide an otherwise-necessary polyfill for older
> browsers if it does become a standard.

I see the other Javascript MVC frameworks as solving the same problem.  I’m 
also coming in from the author side and don’t really want to make another 
framework, but it is something I’m considering..

> 2. You've mentioned before that this would be more useful for beginners 
> (who only know HTML, not Javascript), but I don't necessarily agree. 
> With this proposal you would need to explain how the browser downloads 
> "JSON data" from the mref attribute's location, then somehow parses into
> a model, and then fills up and displays a template (making what the 
> page is actually showing extremely different from what they write in 
> their editor, not exactly intuitive). IMO the biggest hurdle for a 
> beginner to get over would be conceptually understanding the models and 
> templates, which HTML's declarative nature seems to make more difficult 
> to understand. I would prefer having a Javascript library where the user
> could write something along the lines of "link.onclick = 
> fillTemplate(loadData())", making what's actually happening when a user 
> clicks a link much clearer. The person would still need to understand 
> some Javascript, but not much more than what's necessary for the model 
> attributes in your proposal currently.

Writing HTML templates would still be a lot easier than writing Javascript, 
since people start with HTML first, and understand that before going into 
Javascript. And besides, you have to write templates anyways with any modern 
framework.  

Also, people find declarative concepts easier to understand than imperative 
languages.  Your “link.onClick = fillTemplate(loadData())” is an imperative 
script that authors have to figure out from infinite possibilities available in 
Javascript, which is disconnected from the structure of the HTML document.  You 
have to duplicate the “link” reference in your Javascript, and would mostly 
likely have to traverse the DOM hierarchy to find that link to assign the 
onClick.  

How would a author even know how to select the element to assign?  Do they have 
to make sure to include an ID tag to help search through the hierarchy?  So 
many problems there..

Compare your version to: 

http://api.mysite.com/article-1' receiver=“myArticle”>


where the elements and properties have clearly defined & fixed roles that 
assign actions.  And, they operate on those elements, because they were 
assigned right there. There’s no duplication of hierarchy.  You don’t have to 
go back through the document to find the elements again, because it was 
assigned when you built the document in the first place.

It’s just as how:



clearly defines a link that loads a new page action.

Assigning actions via Javascript just makes the system so much more complex.

With this proposal, it falls in line with the use model of static HTML pages, 
with the added benefits of dynamically loaded content without learning a 
separate Javascript framework.  (or trying to figure out which framework to 
use.)


> I'm also curious as to how many beginners would *want* to do a SPA with 
> templates and models like this, I would imagine that by the time you 
> have a real need to load data from a backend API into models and 
> templates without reloading the page that you'd have a workable 
> understanding of Javascript enough to use an existing MVC framework of 
> your choice.

For APIs, the “” definitions could be supplied by the API vendor.  I 
don’t list it in my example, but the model definitions could come in from an 
external source.

For example:



would load in model definitions (and possibly fixtures) from an API vendor.  

The web page's author would then just pick and choose model elements to put in 
their website’s template.

There are 75+ million Wordpress sites and 200+ million Tumblr pages that could 
benefit from this scenario, at the very least.

-bobby
---
Bobby Mozumder
Editor-in-Chief
FutureClaw Magazine
mozum...@futureclaw.com
+1-240-745-5287
www.futureclaw.com
twitter.com/futureclaw
www.linkedin.com/in/mozumder

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

[Bobby Mozumder]

> On Mar 25, 2015, at 3:39 AM, Janusz Majnert  wrote:
> 
> OK. This makes no sense for me.
> 
> So you propose that the server does simple translation of SQL from url to 
> actual query, but you don't see any security issue with this?
> If on the other hand you're proposing that the server validates the sql sent 
> by client, then the simplest (and proven) solution is to have an API entry 
> point that does the query that your client wants without any sql in the urls.


HI Janusz,

The proposal here makes no assumption about the server architecture and data 
that’s exposed by the server using the client’s SQL syntax.  The server is 
still responsible for securing its data, as always.

A server that receives a command like:

SELECT first_name, last_name FROM users;

May parse that and translate that into something usable.

But, if it receives an SQL command like:

DROP TABLE students;

A simple server framework might not even be able to parse it and just ignores 
it, while a more advanced server framework might try to authenticate and verify 
it. Meanwhile, for a local SQL database, like on a game on your mobile device, 
it might very well delete the table.  But for a remote server, anything could 
happen, depending on the server’s design.  

I’m not sure why people think they would connect to a remote SQL server with 
full privileges? I mean, they could if they wanted, but that most likely won’t 
happen.  There would likely be an app server in between the client and the 
database, like how things are now.

Right now, if an app server gets this request:

http://api.mywebsite.com/get_article?id=1234

It’ll happily oblige.

But if it receives an:

http://api.mywebsite.com/delete_article?id=1234 

The server still has to authenticate the request.  Server-side app designers 
still have to implement their security checks, like they would in a framework 
like Django:

from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret')
if user is not None:
# the password verified for the user
if user.is_active:
print("User is valid, active and authenticated")
else:
print("The password is valid, but the account has been 
disabled!")
else:
 # the authentication system was unable to verify the username 
and password
print("The username and password were incorrect.”)

A server-side app designer still has to write this kind of code.  This proposal 
doesn’t remove that requirement.

This proposal means to put the idea of using SQL syntax to get/set data.  As we 
build on it, there would be an ORM that we could standardize so that clients 
could use this SQL syntax.  

This basically somewhat standardizes the syntax for structured remote API data 
access.

-bobby
---
Bobby Mozumder
Editor-in-Chief
FutureClaw Magazine
mozum...@futureclaw.com 
+1-240-745-5287
www.futureclaw.com 
twitter.com/futureclaw 
www.linkedin.com/in/mozumder 

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

[Michael A. Peters]

On 03/25/2015 12:39 AM, Janusz Majnert wrote:



OK. This makes no sense for me.

So you propose that the server does simple translation of SQL from url
to actual query, but you don't see any security issue with this?
If on the other hand you're proposing that the server validates the sql
sent by client, then the simplest (and proven) solution is to have an
API entry point that does the query that your client wants without any
sql in the urls.


Yes I have to agree with that, input needs to be validated on the server 
and preferably bound to a prepared statement, and that is something 
easiest to do with post/get variables that server side languages already 
are equipped to do w/o exposing table / column structure - and easily 
allows for different caching engines to be used as needed to reduce load 
on the SQL server.

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

[Janusz Majnert]

On 24.03.2015 21:29, Bobby Mozumder wrote:

Also, I'm a little terrified of having SQL directly in the markup. There's
so much potential for that to go horribly wrong. Personally, I feel things
that involve data retrieval should be better handled by endpoints that
return HTML, XML, or JSON. Putting it in the user-accessible markup is
dangerous.


It’s just an URL syntax that now allows for SQL statements.  It’s not the 
actual connection to a database.  If you connect to a remote server, the server 
can decide to grant you whatever authorization it wishes, through OAuth tokens 
in the header, through the URL syntax, or whatever.  And, for local databases, 
you can have full control if you want.


Some of these things you're asking the browser to do, I don't think the
browser should be doing. Fundamentally, web sites are a client/server
model, and we shouldn't heap on too much into the client side. Part of the
problem with that is the computational complexity (which is a problem in
developing countries where low end devices are the norm). The other part is
that you are essentially trusting the user device to be secure, which is a
terrible idea no matter how you slice it.


I never said the client would be consider trusted.  Not sure where you got that?

Right now, if when you request data via an API endpoint URL, the remote web 
server transforms that into an SQL query.

This proposal lets you request data via an SQL syntax.  The remote web server 
would still need to transform that syntax into an SQL query that’s fit for the 
server.

For example:

SELECT first_name, last_name FROM users;

would be transformed into:

SELECT first_name, last_name FROM users WHERE manager="Boss Man";

And this proposal also eliminates the need for a transformative app server when 
accessing local databases.


OK. This makes no sense for me.

So you propose that the server does simple translation of SQL from url 
to actual query, but you don't see any security issue with this?
If on the other hand you're proposing that the server validates the sql 
sent by client, then the simplest (and proven) solution is to have an 
API entry point that does the query that your client wants without any 
sql in the urls.




Regards,
Janusz Majnert
Senior Software Engineer
Samsung R&D Institute Poland
Samsung Electronics

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

[Michael A. Peters]

On 03/24/2015 04:50 PM, Michael A. Peters wrote:

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.


I would like to clarify that when I say I am against this, I am not 
opposed to the function being there for those who would find it useful.


I can be overly critical, I am not opposed to this being part of a 
future HTML for those who do want it, especially if it makes it easier 
for this kind of web design to be done in an accessible way.

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

[Matthew Sotoudeh]

Hello!

By way of introduction, I'm an author who reads some of these mailing lists but 
(almost) never replies.



This proposal is quite interesting, wanted to throw in my two cents as well:



1. Would you consider writing a polyfill/Javascript framework for this? 
It seems to me that the fundamentals of the proposal could be fairly 
simply written into a small Javascript polyfill by intercepting a[mref] 
clicks and filling up s. A working polyfill would give 
people a chance to play around with the proposal, give you (and others 
who like the idea) a working implementation of it in case it doesn't 
become a standard, and provide an otherwise-necessary polyfill for older
 browsers if it does become a standard.



2. You've mentioned before that this would be more useful for beginners 
(who only know HTML, not Javascript), but I don't necessarily agree. 
With this proposal you would need to explain how the browser downloads 
"JSON data" from the mref attribute's location, then somehow parses into
 a model, and then fills up and displays a template (making what the 
page is actually showing extremely different from what they write in 
their editor, not exactly intuitive). IMO the biggest hurdle for a 
beginner to get over would be conceptually understanding the models and 
templates, which HTML's declarative nature seems to make more difficult 
to understand. I would prefer having a Javascript library where the user
 could write something along the lines of "link.onclick = 
fillTemplate(loadData())", making what's actually happening when a user 
clicks a link much clearer. The person would still need to understand 
some Javascript, but not much more than what's necessary for the model 
attributes in your proposal currently.



I'm also curious as to how many beginners would *want* to do a SPA with 
templates and models like this, I would imagine that by the time you 
have a real need to load data from a backend API into models and 
templates without reloading the page that you'd have a workable 
understanding of Javascript enough to use an existing MVC framework of 
your choice.



Thanks,

Matthew Sotoudeh

> From: mozum...@futureclaw.com
> Date: Tue, 24 Mar 2015 22:10:12 -0400
> To: del...@segonquart.net
> CC: wha...@whatwg.org; master.skywalker...@gmail.com
> Subject: Re: [whatwg] HTML6 single-page apps without Javascript proposal now  
> on Github
> 
> 
> > On Mar 24, 2015, at 9:51 PM, delfin  wrote:
> > 
> > 
> > 
> > Hi all: 
> > 
> > I agree with you all you have quoted, Rendine. 
> > 
> > * Neal : " a problem in developing countries where low end devices are
> > the norm", is _de facto_ THE norme , and was the need of web
> > (standards).
> > * HTML6, if ever, must accomplish and adopt the so called
> > _retro-conditions_, HTML version 5 has.
> > * This conditions are, for example, that one can and must be able to
> > navigate through the Internet pages using an aged and abandoned
> > computer.
> 
> I mentioned it in the original message with the MREF property, you can use 
> all of this on older browsers.
> 
> Older browsers will just ignore the  elements and MODEL properties of 
> elements, and will continue to function the same.  When you click on a link, 
> instead of fetching the API endpoint that the MREF points to, it uses the 
> canonical URL in the HREF property, like always.
> 
> This proposal should be backwards compatible on older browsers.  If it isn’t, 
> let me know.
> 
> -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>
> 
> 
  

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

[Bobby Mozumder]

> On Mar 24, 2015, at 9:51 PM, delfin  wrote:
> 
> 
> 
> Hi all: 
> 
> I agree with you all you have quoted, Rendine. 
> 
>   * Neal : " a problem in developing countries where low end devices are
> the norm", is _de facto_ THE norme , and was the need of web
> (standards).
>   * HTML6, if ever, must accomplish and adopt the so called
> _retro-conditions_, HTML version 5 has.
>   * This conditions are, for example, that one can and must be able to
> navigate through the Internet pages using an aged and abandoned
> computer.

I mentioned it in the original message with the MREF property, you can use all 
of this on older browsers.

Older browsers will just ignore the  elements and MODEL properties of 
elements, and will continue to function the same.  When you click on a link, 
instead of fetching the API endpoint that the MREF points to, it uses the 
canonical URL in the HREF property, like always.

This proposal should be backwards compatible on older browsers.  If it isn’t, 
let me know.

-bobby
---
Bobby Mozumder
Editor-in-Chief
FutureClaw Magazine
mozum...@futureclaw.com 
+1-240-745-5287
www.futureclaw.com 
twitter.com/futureclaw 
www.linkedin.com/in/mozumder 

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

[delfin]

 

Hi all: 

I agree with you all you have quoted, Rendine. 

* Neal : " a problem in developing countries where low end devices are
the norm", is _de facto_ THE norme , and was the need of web
(standards).
* HTML6, if ever, must accomplish and adopt the so called
_retro-conditions_, HTML version 5 has.
* This conditions are, for example, that one can and must be able to
navigate through the Internet pages using an aged and abandoned
computer.
* If this is not the scenario, I highly reccommmend to recover
Hypercard, and all that technology that floated round in the mid 90s.
* That was not the web build for.
* If we cannot collect data , storaged in tags and rendered (
visually, aurally or whatever ) then, I guess we are missing the pòint-
* I like the approach Mozunder offers, to avoid unnecesary code , when
you can, say, reform the DOM by tags.
* Accesibility and the Internet of things. HTML6 must be able "to let
a talk" between machines.
* Example: "Siri, please, place inside that component a form field
including two input tags ( name and password) and a button that says
'Send' "

Regards 

On 2015-03-24 13:19, Andrea Rendine wrote: 

> As an author I shall offer my 2 cents too.
> First off, I'm for native implementations and all that markup and CSS can
> do on _existing_ content.
> Thus said, I prefer having JS manipulating the content with AJAX than
> having the markup doing that.
> Apart from the concept that markup itself is being pushed too far, from an
> instrument capable of specifying properties for its content to something
> acting on its own, I think there's more potential for security issues than
> for genuine manipulation.
> Maybe things will move towards that end from now on, as websites have to
> look like web apps and this means that they have to be "apps executed on a
> browser platform", but I personally prefer an "ideal" model where
> - html provides static content, i.e. content which does not change when
> looking at the page structure itself
> - css provides ALL the graphic/presentational stuff and even some
> interface, (everyone can imagine what can be done with ":target" or
> ":checked" selectors...)
> - js provides dynamic content, i.e. whatever is to be considered part of
> the content itself when actions are executed or events are fired.
> Let's see what happens, then. This was just an idea.
> 
> 2015-03-24 13:07 GMT+01:00 Neal Gompa :
> I think I can firmly say that I'm not in the "JS all the things" camp. I do 
> see the reasoning behind this, but I'd like to point out that not everyone in 
> the world would like to use the MVC model. Personally, I don't mind it (since 
> it offers a logical separation of data, presentation, and operational logic), 
> but I know of those who hate it. Also, I'm a little terrified of having SQL 
> directly in the markup. There's so much potential for that to go horribly 
> wrong. Personally, I feel things that involve data retrieval should be better 
> handled by endpoints that return HTML, XML, or JSON. Putting it in the 
> user-accessible markup is dangerous. Some of these things you're asking the 
> browser to do, I don't think the browser should be doing. Fundamentally, web 
> sites are a client/server model, and we shouldn't heap on too much into the 
> client side. Part of the problem with that is the computational complexity 
> (which is a problem in developing countries where low end devices are the 
> norm).
The other part is that you are essentially trusting the user device to be 
secure, which is a terrible idea no matter how you slice it. The main reason 
that browsers get so much heaped onto it these days is because we've not really 
evolved the role of the server in website design. It's been the same for years, 
which is fine, except that it's clearly not good for the mobile world (as more 
complex processing moves from the server to client). I don't know the 
appropriate forum for discussing that particular issue, but I think we need to 
make the server side of this more intelligent, too. I think it makes sense to 
extend HTML to support "single document" website models like this, but I'm 
extremely wary of mandating the browser to process data directly. An individual 
developer can make that choice himself/herself, but I'd rather not mandate that 
workflow. Instead, enabling partial refreshing and using endpoints with URI 
request information to retrieve the desired portions of the page to
load up makes a lot of sense. But we also need this to be a linkable model. I'm 
not sure how you can make a desired "variant" of the page linkable from an 
external source (such as Wikipedia or a news organization site). On Tue, Mar 
24, 2015 at 5:18 AM, Bobby Mozumder  wrote: 
https://github.com/mozumder/HTML6 [6] 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 i

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

[Andrea Rendine]

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 :

> 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 
> 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 
> >elements to separate the canonical URL from an API URL, and a RECEIVER
> >property to specify where the API data loads:
> >
> >   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  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 
> >+1-240-745-5287
> >www.futureclaw.com 
> >twitter.com/futureclaw 
> >www.linkedin.com/in/mozumder 
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

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

[Michael A. Peters]

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  
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 
>elements to separate the canonical URL from an API URL, and a RECEIVER
>property to specify where the API data loads:
>
>   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  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 
>+1-240-745-5287
>www.futureclaw.com 
>twitter.com/futureclaw 
>www.linkedin.com/in/mozumder 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Bobby Mozumder]

> On Mar 24, 2015, at 4:15 PM, Andrea Rendine  
> wrote:
> 
> I don't want to openly oppose to this project, as I'm anyway curious about
> how it will be developed. It's only that I have seen a lot of elements used
> outside their proper dynamics.
> I don't see HTML as a templating language, but it's probably because I'm
> tied to current use cases, so I don't see any further.
> Anyway, yes, I write my pages so that their content is to remain when
> served to client. Of course I would add more to the preexisting content,
> given the circumstances, but not to change what's already there.
> Besides, I invite you to consider, throughout the development process, a
> possible role for  element. Instead of creating something
> completely new, some features could be added to make it more complex and
> more complete. It is now a container for markup that can be reused by
> script to show content. Why not making it able to load its own content,
> then?
> 


In the proposal I already do list using  elements to instantiate 
model objects.  This would make it the equivalent to blocks in traditional 
template languages.

See:  https://github.com/mozumder/html6#further-uses

Is that OK?  Any other options?

-bobby
---
Bobby Mozumder
Editor-in-Chief
FutureClaw Magazine
mozum...@futureclaw.com 
+1-240-745-5287
www.futureclaw.com 
twitter.com/futureclaw 
www.linkedin.com/in/mozumder 

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

[Bobby Mozumder]

> On Mar 24, 2015, at 8:07 AM, Neal Gompa  wrote:
> 
> I think I can firmly say that I'm not in the "JS all the things" camp. I do
> see the reasoning behind this, but I'd like to point out that not everyone
> in the world would like to use the MVC model. Personally, I don't mind it
> (since it offers a logical separation of data, presentation, and
> operational logic), but I know of those who hate it.

I’d like to hear the arguments against it, and in particular, how usability is 
better without it. I gave several reasons why these frameworks exist in order 
to fix whats wrong with the web.

> Also, I'm a little terrified of having SQL directly in the markup. There's
> so much potential for that to go horribly wrong. Personally, I feel things
> that involve data retrieval should be better handled by endpoints that
> return HTML, XML, or JSON. Putting it in the user-accessible markup is
> dangerous.

It’s just an URL syntax that now allows for SQL statements.  It’s not the 
actual connection to a database.  If you connect to a remote server, the server 
can decide to grant you whatever authorization it wishes, through OAuth tokens 
in the header, through the URL syntax, or whatever.  And, for local databases, 
you can have full control if you want.

> Some of these things you're asking the browser to do, I don't think the
> browser should be doing. Fundamentally, web sites are a client/server
> model, and we shouldn't heap on too much into the client side. Part of the
> problem with that is the computational complexity (which is a problem in
> developing countries where low end devices are the norm). The other part is
> that you are essentially trusting the user device to be secure, which is a
> terrible idea no matter how you slice it.

I never said the client would be consider trusted.  Not sure where you got that?

Right now, if when you request data via an API endpoint URL, the remote web 
server transforms that into an SQL query.

This proposal lets you request data via an SQL syntax.  The remote web server 
would still need to transform that syntax into an SQL query that’s fit for the 
server.

For example:

SELECT first_name, last_name FROM users;

would be transformed into:

SELECT first_name, last_name FROM users WHERE manager="Boss Man";

And this proposal also eliminates the need for a transformative app server when 
accessing local databases.

> The main reason that browsers get so much heaped onto it these days is
> because we've not really evolved the role of the server in website design.
> It's been the same for years, which is fine, except that it's clearly not
> good for the mobile world (as more complex processing moves from the server
> to client). I don't know the appropriate forum for discussing that
> particular issue, but I think we need to make the server side of this more
> intelligent, too.
> 
> I think it makes sense to extend HTML to support "single document" website
> models like this, but I'm extremely wary of mandating the browser to
> process data directly. An individual developer can make that choice
> himself/herself, but I'd rather not mandate that workflow. Instead,
> enabling partial refreshing and using endpoints with URI request
> information to retrieve the desired portions of the page to load up makes a
> lot of sense. But we also need this to be a linkable model. I'm not sure
> how you can make a desired "variant" of the page linkable from an external
> source (such as Wikipedia or a news organization site).

In the latest version (on the GitHub), I added an MREF property to links to 
separate the model API endpoint from the canonical URL:

http://www.mywebsite.com/article-2.html"; 
mref="http://api.mywebsite.com/article-2"; receiver=“myArticleData">

When you click on a link, the browser fetches JSON data from 
"http://api.mywebsite.com/article-2";.  It then loads that data into 
“myArticleData", and the URL bar becomes 
“http://www.mywebsite.com/article-2.html” in the pages domain.  The HREF URL is 
the canonical URL for this piece of data, like always, and this is what people 
can share and link to from external sites.

Does that work?  Any problems behind that?  

-bobby
---
Bobby Mozumder
Editor-in-Chief
FutureClaw Magazine
mozum...@futureclaw.com
+1-240-745-5287
www.futureclaw.com
twitter.com/futureclaw
www.linkedin.com/in/mozumder

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

[Nils Dagsson Moskopp]

Bobby Mozumder  writes:

> Besides, when was the last time you actually wrote a static HTML file?
> Does anyone do that?

I assume you asked a rhetorical question. Still, the answer is “Yes”.

> For every web site, people actually write templates, not HTML code.

This is provably false. Be careful with “all” quantifiers next time.

-- 
Nils Dagsson Moskopp // erlehmann

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

[Andrea Rendine]

I don't want to openly oppose to this project, as I'm anyway curious about
how it will be developed. It's only that I have seen a lot of elements used
outside their proper dynamics.
I don't see HTML as a templating language, but it's probably because I'm
tied to current use cases, so I don't see any further.
Anyway, yes, I write my pages so that their content is to remain when
served to client. Of course I would add more to the preexisting content,
given the circumstances, but not to change what's already there.
Besides, I invite you to consider, throughout the development process, a
possible role for  element. Instead of creating something
completely new, some features could be added to make it more complex and
more complete. It is now a container for markup that can be reused by
script to show content. Why not making it able to load its own content,
then?

2015-03-24 21:01 GMT+01:00 Bobby Mozumder :

>
> On Mar 24, 2015, at 8:19 AM, Andrea Rendine 
> wrote:
>
> As an author I shall offer my 2 cents too.
> First off, I'm for native implementations and all that markup and CSS can
> do on _existing_ content.
> Thus said, I prefer having JS manipulating the content with AJAX than
> having the markup doing that.
> Apart from the concept that markup itself is being pushed too far, from an
> instrument capable of specifying properties for its content to something
> acting on its own, I think there's more potential for security issues than
> for genuine manipulation.
> Maybe things will move towards that end from now on, as websites have to
> look like web apps and this means that they have to be "apps executed on a
> browser platform", but I personally prefer an "ideal" model where
> - html provides static content, i.e. content which does not change when
> looking at the page structure itself
> - css provides ALL the graphic/presentational stuff and even some
> interface, (everyone can imagine what can be done with ":target" or
> ":checked" selectors...)
> - js provides dynamic content, i.e. whatever is to be considered part of
> the content itself when actions are executed or events are fired.
> Let's see what happens, then. This was just an idea.
>
>
>
> In this proposal, HTML would turn into a templating language.  A template
> is a perfectly valid document specification.  You see document templates
> everywhere, at the office supply store, in Adobe inDesign, and so on.
>
> Besides, when was the last time you actually wrote a static HTML file?
> Does anyone do that?
>
> For every web site, people actually write templates, not HTML code.
>
> This proposal standardizes on the idea of using HTML for templates.
>
> -bobby
>
> ---
> Bobby Mozumder
> *Editor-in-Chief*
> FutureClaw Magazine
> mozum...@futureclaw.com
> +1-240-745-5287
> www.futureclaw.com
> twitter.com/futureclaw 
> www.linkedin.com/in/mozumder
>
>

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

[Bobby Mozumder]

> On Mar 24, 2015, at 8:19 AM, Andrea Rendine  
> wrote:
> 
> As an author I shall offer my 2 cents too.
> First off, I'm for native implementations and all that markup and CSS can
> do on _existing_ content.
> Thus said, I prefer having JS manipulating the content with AJAX than
> having the markup doing that.
> Apart from the concept that markup itself is being pushed too far, from an
> instrument capable of specifying properties for its content to something
> acting on its own, I think there's more potential for security issues than
> for genuine manipulation.
> Maybe things will move towards that end from now on, as websites have to
> look like web apps and this means that they have to be "apps executed on a
> browser platform", but I personally prefer an "ideal" model where
> - html provides static content, i.e. content which does not change when
> looking at the page structure itself
> - css provides ALL the graphic/presentational stuff and even some
> interface, (everyone can imagine what can be done with ":target" or
> ":checked" selectors...)
> - js provides dynamic content, i.e. whatever is to be considered part of
> the content itself when actions are executed or events are fired.
> Let's see what happens, then. This was just an idea.
> 


In this proposal, HTML would turn into a templating language.  A template is a 
perfectly valid document specification.  You see document templates everywhere, 
at the office supply store, in Adobe inDesign, and so on.  

Besides, when was the last time you actually wrote a static HTML file?  Does 
anyone do that?

For every web site, people actually write templates, not HTML code.

This proposal standardizes on the idea of using HTML for templates.

-bobby

---
Bobby Mozumder
Editor-in-Chief
FutureClaw Magazine
mozum...@futureclaw.com 
+1-240-745-5287
www.futureclaw.com 
twitter.com/futureclaw 
www.linkedin.com/in/mozumder 

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

[Andrea Rendine]

As an author I shall offer my 2 cents too.
First off, I'm for native implementations and all that markup and CSS can
do on _existing_ content.
Thus said, I prefer having JS manipulating the content with AJAX than
having the markup doing that.
Apart from the concept that markup itself is being pushed too far, from an
instrument capable of specifying properties for its content to something
acting on its own, I think there's more potential for security issues than
for genuine manipulation.
Maybe things will move towards that end from now on, as websites have to
look like web apps and this means that they have to be "apps executed on a
browser platform", but I personally prefer an "ideal" model where
 - html provides static content, i.e. content which does not change when
looking at the page structure itself
 - css provides ALL the graphic/presentational stuff and even some
interface, (everyone can imagine what can be done with ":target" or
":checked" selectors...)
 - js provides dynamic content, i.e. whatever is to be considered part of
the content itself when actions are executed or events are fired.
Let's see what happens, then. This was just an idea.

2015-03-24 13:07 GMT+01:00 Neal Gompa :

> I think I can firmly say that I'm not in the "JS all the things" camp. I do
> see the reasoning behind this, but I'd like to point out that not everyone
> in the world would like to use the MVC model. Personally, I don't mind it
> (since it offers a logical separation of data, presentation, and
> operational logic), but I know of those who hate it.
>
> Also, I'm a little terrified of having SQL directly in the markup. There's
> so much potential for that to go horribly wrong. Personally, I feel things
> that involve data retrieval should be better handled by endpoints that
> return HTML, XML, or JSON. Putting it in the user-accessible markup is
> dangerous.
>
> Some of these things you're asking the browser to do, I don't think the
> browser should be doing. Fundamentally, web sites are a client/server
> model, and we shouldn't heap on too much into the client side. Part of the
> problem with that is the computational complexity (which is a problem in
> developing countries where low end devices are the norm). The other part is
> that you are essentially trusting the user device to be secure, which is a
> terrible idea no matter how you slice it.
>
> The main reason that browsers get so much heaped onto it these days is
> because we've not really evolved the role of the server in website design.
> It's been the same for years, which is fine, except that it's clearly not
> good for the mobile world (as more complex processing moves from the server
> to client). I don't know the appropriate forum for discussing that
> particular issue, but I think we need to make the server side of this more
> intelligent, too.
>
> I think it makes sense to extend HTML to support "single document" website
> models like this, but I'm extremely wary of mandating the browser to
> process data directly. An individual developer can make that choice
> himself/herself, but I'd rather not mandate that workflow. Instead,
> enabling partial refreshing and using endpoints with URI request
> information to retrieve the desired portions of the page to load up makes a
> lot of sense. But we also need this to be a linkable model. I'm not sure
> how you can make a desired "variant" of the page linkable from an external
> source (such as Wikipedia or a news organization site).
>
>
>
> On Tue, Mar 24, 2015 at 5:18 AM, Bobby Mozumder 
> 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 
> > elements to separate the canonical URL from an API URL, and a RECEIVER
> > property to specify where the API data loads:
> >
> > 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 
> > element.
> >
> > I also changed the fixtures in the example from XML to JSON.  I alway

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

[Neal Gompa]

I think I can firmly say that I'm not in the "JS all the things" camp. I do
see the reasoning behind this, but I'd like to point out that not everyone
in the world would like to use the MVC model. Personally, I don't mind it
(since it offers a logical separation of data, presentation, and
operational logic), but I know of those who hate it.

Also, I'm a little terrified of having SQL directly in the markup. There's
so much potential for that to go horribly wrong. Personally, I feel things
that involve data retrieval should be better handled by endpoints that
return HTML, XML, or JSON. Putting it in the user-accessible markup is
dangerous.

Some of these things you're asking the browser to do, I don't think the
browser should be doing. Fundamentally, web sites are a client/server
model, and we shouldn't heap on too much into the client side. Part of the
problem with that is the computational complexity (which is a problem in
developing countries where low end devices are the norm). The other part is
that you are essentially trusting the user device to be secure, which is a
terrible idea no matter how you slice it.

The main reason that browsers get so much heaped onto it these days is
because we've not really evolved the role of the server in website design.
It's been the same for years, which is fine, except that it's clearly not
good for the mobile world (as more complex processing moves from the server
to client). I don't know the appropriate forum for discussing that
particular issue, but I think we need to make the server side of this more
intelligent, too.

I think it makes sense to extend HTML to support "single document" website
models like this, but I'm extremely wary of mandating the browser to
process data directly. An individual developer can make that choice
himself/herself, but I'd rather not mandate that workflow. Instead,
enabling partial refreshing and using endpoints with URI request
information to retrieve the desired portions of the page to load up makes a
lot of sense. But we also need this to be a linkable model. I'm not sure
how you can make a desired "variant" of the page linkable from an external
source (such as Wikipedia or a news organization site).



On Tue, Mar 24, 2015 at 5:18 AM, Bobby Mozumder 
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 
> elements to separate the canonical URL from an API URL, and a RECEIVER
> property to specify where the API data loads:
>
> 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 
> 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 a