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 <ngomp...@gmail.com>:
> 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 <mozum...@futureclaw.com> 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 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 [7]" mref="
http://api.mywebsite.com/article-2 [8]" 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 [9] <http://www.futureclaw.com/ [10]>
twitter.com/futureclaw <https://www.twitter.com/futureclaw [11]>
www.linkedin.com/in/mozumder [12] <http://www.linkedin.com/in/mozumder [12]>
>
> ---
>
> Delfi Ramirez
>
> My digital signature [1]
>
> +34 633 589231
> del...@segonquart.net [2]
>
> twitter: delfinramirez
>
> IRC: segonquart Skype: segonquart [3]
>
> http://segonquart.net [4]
>
> http://delfiramirez.info [5]
> -- 真実はいつも一つ！/ Always, there's only one truth!
Links:
------
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] skype:segonquart
[4] http://segonquart.net
[5] http://delfiramirez.info
[6] https://github.com/mozumder/HTML6
[7] http://www.mywebsite.com/article-2.html
[8] http://api.mywebsite.com/article-2
[9] http://www.futureclaw.com
[10] http://www.futureclaw.com/
[11] https://www.twitter.com/futureclaw
[12] http://www.linkedin.com/in/mozumder
