Re: [whatwg] Some Clarification on CML Proposal

[Jacob Villarreal]

I think I got it straightened out.  The type scripts handle the batch file 
formats, being .frm/.fld/.mnu/.smn, for multi-source appliance.    The subtype 
scripts handle the attributes with respect to types.  The 'link' type script 
redirects link paths to the user agent.  So CML script updates on browsers is 
what is needed to implement CML.Jacob 

On Thursday, October 6, 2016 9:42 AM, Jacob Villarreal  
wrote:
 

 I find it somewhat strange that we are not able to synch up on this proposal.  
It's kind of funny, but there isn't much to these new tags I mentioned.  
They're used like any regular html tags, like , for example, but .  So the source tag would retrieve the 
action_page.php file by means of the source path, and render it at the pixel 
coordinate specified, on the web page.  So there are only two main tags for the 
whole CML language, being , and , and one subtype tag, 
being .  So the attributes within source/destination perform 
retrieval/storage operations, while the attribute tag performs attribute 
operations with respect to the type attribute found in the source/destination 
tags.  So the attribute tag is always used in connection with either the 
source, or the destination tags individually.  As far as CSS, and Javascript 
coding, it's much more antiquated than the formatting/scripting possibilities 
that CML presents.  Static formatting on multiple pages, like what CSS does, 
can be done more efficiently, by applying one simple line of code to all of the 
targeted content on the page.  For example:

This would send all of the settings for the objects between the destination 
tags to a single file for appliance of those settings on other pages, with only 
two simple lines of code.  That's alot more efficient than html, and CSS.
It's not a big deal, seriously, you don't have to worry about it.  It was just 
something I came up with after having been agitated by the trouble I had with 
html.  I couldn't get anything to work.  That's why I would like to get these 
tags implemented, so I can get started doing much more than what html, CSS, and 
JavaScript have to offer.
Thanks,Jacob 

On Thursday, October 6, 2016 9:14 AM, Jacob Villarreal  
wrote:
 

 Roger,You wrote:How is this any different from PHP, ASP, JSP, .Net, 
ColdFusion, etc?  You could implement your CML on the backend and have it 
'output' XML/HTML+JavaScript+CSS for delivery to user agents with compatibility 
with everything out there today.
In response:I've tried a little bit of PHP, and just seen some samples of ASP, 
JSP, and ColdFusion.  But in case you didn't notice CML only consists of two 
tags.  Compare that to PHP, which is very similar to C+ programming language.  
I'm not sure if you were complementing or what, but it's true CML would be 
compatible with pretty much anything out there, including 
XML/HTML+JavaScript+CSS.  In fact, CSS is accomplished by simply appending 
different sources to be rendered on the page in a layered format.  As for 
example:
line 1: +line 2: +
line 3: 

Tabs would be image objects with linkage to lines within a single cascade 
record.  I know you think it sounds like batch programming, but it's really not 
any different from standard html, in that respect, other than the simplicity, 
and scalability. 
You wrote:If you want to try to replace HTML, JavaScript, and CSS so that every 
user agent needs to understand CML natively - that's just not going to happen.
In response:Very funny, but CML is so simple, it would only take you around 
5-10 minutes to learn it completely.
You wrote:There are many server-side options and it really sounds like that's 
where CML would fit.  Your developers would write in CML, and the 'engine' 
would render that into the appropriate content for delivery to UAs.
In response:I don't know why everyone keeps referring to server-side 
infrastructure in response to CML.  When you access html files located on an 
Microsoft IIS server, you access folders located either on the server, or on a 
remote server/database.  CML would access the .frm/.mnu files, for example from 
the same server's folders, or from a remote server/database.  The difference is 
in the backend, being on the unix side, I believe, which runs the scripts for 
html.  So I was wondering if the browsers translate the html code, or if the 
internet servers require a script update with the appropriate implementations 
to run on the .frm/.mnu file extensions in order to apply the rules with 
respect to line text in those files.
So I don't think we're synched up with it too well.  I guess I would like to 
know whether the browser's code applies the html, or if the internet servers 
handle the translation for rendering of site content onto the web page.  If the 
server side handles the processing of html code, it might require a new 
protocol, or internet information server script.  If the browsers handle the 
processing of html code, then the browsers would need 

Re: [whatwg] Some Clarification on CML Proposal

[Jacob Villarreal]

I find it somewhat strange that we are not able to synch up on this proposal.  
It's kind of funny, but there isn't much to these new tags I mentioned.  
They're used like any regular html tags, like , for example, but .  So the source tag would retrieve the 
action_page.php file by means of the source path, and render it at the pixel 
coordinate specified, on the web page.  So there are only two main tags for the 
whole CML language, being , and , and one subtype tag, 
being .  So the attributes within source/destination perform 
retrieval/storage operations, while the attribute tag performs attribute 
operations with respect to the type attribute found in the source/destination 
tags.  So the attribute tag is always used in connection with either the 
source, or the destination tags individually.  As far as CSS, and Javascript 
coding, it's much more antiquated than the formatting/scripting possibilities 
that CML presents.  Static formatting on multiple pages, like what CSS does, 
can be done more efficiently, by applying one simple line of code to all of the 
targeted content on the page.  For example:

This would send all of the settings for the objects between the destination 
tags to a single file for appliance of those settings on other pages, with only 
two simple lines of code.  That's alot more efficient than html, and CSS.
It's not a big deal, seriously, you don't have to worry about it.  It was just 
something I came up with after having been agitated by the trouble I had with 
html.  I couldn't get anything to work.  That's why I would like to get these 
tags implemented, so I can get started doing much more than what html, CSS, and 
JavaScript have to offer.
Thanks,Jacob 

On Thursday, October 6, 2016 9:14 AM, Jacob Villarreal  
wrote:
 

 Roger,You wrote:How is this any different from PHP, ASP, JSP, .Net, 
ColdFusion, etc?  You could implement your CML on the backend and have it 
'output' XML/HTML+JavaScript+CSS for delivery to user agents with compatibility 
with everything out there today.
In response:I've tried a little bit of PHP, and just seen some samples of ASP, 
JSP, and ColdFusion.  But in case you didn't notice CML only consists of two 
tags.  Compare that to PHP, which is very similar to C+ programming language.  
I'm not sure if you were complementing or what, but it's true CML would be 
compatible with pretty much anything out there, including 
XML/HTML+JavaScript+CSS.  In fact, CSS is accomplished by simply appending 
different sources to be rendered on the page in a layered format.  As for 
example:
line 1: +line 2: +
line 3: 

Tabs would be image objects with linkage to lines within a single cascade 
record.  I know you think it sounds like batch programming, but it's really not 
any different from standard html, in that respect, other than the simplicity, 
and scalability. 
You wrote:If you want to try to replace HTML, JavaScript, and CSS so that every 
user agent needs to understand CML natively - that's just not going to happen.
In response:Very funny, but CML is so simple, it would only take you around 
5-10 minutes to learn it completely.
You wrote:There are many server-side options and it really sounds like that's 
where CML would fit.  Your developers would write in CML, and the 'engine' 
would render that into the appropriate content for delivery to UAs.
In response:I don't know why everyone keeps referring to server-side 
infrastructure in response to CML.  When you access html files located on an 
Microsoft IIS server, you access folders located either on the server, or on a 
remote server/database.  CML would access the .frm/.mnu files, for example from 
the same server's folders, or from a remote server/database.  The difference is 
in the backend, being on the unix side, I believe, which runs the scripts for 
html.  So I was wondering if the browsers translate the html code, or if the 
internet servers require a script update with the appropriate implementations 
to run on the .frm/.mnu file extensions in order to apply the rules with 
respect to line text in those files.
So I don't think we're synched up with it too well.  I guess I would like to 
know whether the browser's code applies the html, or if the internet servers 
handle the translation for rendering of site content onto the web page.  If the 
server side handles the processing of html code, it might require a new 
protocol, or internet information server script.  If the browsers handle the 
processing of html code, then the browsers would need the update to be able to 
run CML.  I just thought it would require an entirely new specification in 
order to implement it for the general public.
You wrote:
Personally I don't see value in this proposal.
In response:I'm confident that CML would replace html entirely, though, by 
popular franchise, haha.  I'm beginning to get the idea that I would have to 
develop my own open source website, and driver/script update for browsers, like 

Re: [whatwg] Some Clarification on CML Proposal

[Jacob Villarreal]

Roger,You wrote:How is this any different from PHP, ASP, JSP, .Net, ColdFusion, 
etc?  You could implement your CML on the backend and have it 'output' 
XML/HTML+JavaScript+CSS for delivery to user agents with compatibility with 
everything out there today.
In response:I've tried a little bit of PHP, and just seen some samples of ASP, 
JSP, and ColdFusion.  But in case you didn't notice CML only consists of two 
tags.  Compare that to PHP, which is very similar to C+ programming language.  
I'm not sure if you were complementing or what, but it's true CML would be 
compatible with pretty much anything out there, including 
XML/HTML+JavaScript+CSS.  In fact, CSS is accomplished by simply appending 
different sources to be rendered on the page in a layered format.  As for 
example:
line 1: +line 2: +
line 3: 

Tabs would be image objects with linkage to lines within a single cascade 
record.  I know you think it sounds like batch programming, but it's really not 
any different from standard html, in that respect, other than the simplicity, 
and scalability. 
You wrote:If you want to try to replace HTML, JavaScript, and CSS so that every 
user agent needs to understand CML natively - that's just not going to happen.
In response:Very funny, but CML is so simple, it would only take you around 
5-10 minutes to learn it completely.
You wrote:There are many server-side options and it really sounds like that's 
where CML would fit.  Your developers would write in CML, and the 'engine' 
would render that into the appropriate content for delivery to UAs.
In response:I don't know why everyone keeps referring to server-side 
infrastructure in response to CML.  When you access html files located on an 
Microsoft IIS server, you access folders located either on the server, or on a 
remote server/database.  CML would access the .frm/.mnu files, for example from 
the same server's folders, or from a remote server/database.  The difference is 
in the backend, being on the unix side, I believe, which runs the scripts for 
html.  So I was wondering if the browsers translate the html code, or if the 
internet servers require a script update with the appropriate implementations 
to run on the .frm/.mnu file extensions in order to apply the rules with 
respect to line text in those files.
So I don't think we're synched up with it too well.  I guess I would like to 
know whether the browser's code applies the html, or if the internet servers 
handle the translation for rendering of site content onto the web page.  If the 
server side handles the processing of html code, it might require a new 
protocol, or internet information server script.  If the browsers handle the 
processing of html code, then the browsers would need the update to be able to 
run CML.  I just thought it would require an entirely new specification in 
order to implement it for the general public.
You wrote:
Personally I don't see value in this proposal.
In response:I'm confident that CML would replace html entirely, though, by 
popular franchise, haha.  I'm beginning to get the idea that I would have to 
develop my own open source website, and driver/script update for browsers, like 
with Flash updates.
Didn't mean to take up too much of your time.
Thanks anyway,Jacob 

On Thursday, October 6, 2016 8:02 AM, Roger Hågensen 
 wrote:
 

 On 2016-10-06 14:15, MegaZone wrote:
> How is this any different from PHP, ASP, JSP, .Net, ColdFusion, etc?  You
> could implement your CML on the backend and have it 'output'
> XML/HTML+JavaScript+CSS for delivery to user agents with compatibility with
> everything out there today.
>...
> There are many server-side options and it really sounds like that's where
> CML would fit.  Your developers would write in CML, and the 'engine' would
> render that into the appropriate content for delivery to UAs.

Yeah! For example, I'm working on a offline CMS that actually uses 
include/declaration files for all the components of a static site. The 
CMS will grab all that apply templates and "render" the finished html, 
PHP is actually used to power this CMS.

> Personally I don't see value in this proposal.
I have to agree, I almost feel like I'm being trolled at this point.
Unless a post or a "diagram" shows up that makes me go "Ah! Now I see!" 
I'm not going to bother responding to any further posts on this subject.


-- 
Roger Hågensen, Freelancer, http://skuldwyrm.no/


   

Re: [whatwg] Some Clarification on CML Proposal

[Roger Hågensen]

On 2016-10-06 14:15, MegaZone wrote:

How is this any different from PHP, ASP, JSP, .Net, ColdFusion, etc?  You
could implement your CML on the backend and have it 'output'
XML/HTML+JavaScript+CSS for delivery to user agents with compatibility with
everything out there today.
...
There are many server-side options and it really sounds like that's where
CML would fit.  Your developers would write in CML, and the 'engine' would
render that into the appropriate content for delivery to UAs.


Yeah! For example, I'm working on a offline CMS that actually uses 
include/declaration files for all the components of a static site. The 
CMS will grab all that apply templates and "render" the finished html, 
PHP is actually used to power this CMS.



Personally I don't see value in this proposal.

I have to agree, I almost feel like I'm being trolled at this point.
Unless a post or a "diagram" shows up that makes me go "Ah! Now I see!" 
I'm not going to bother responding to any further posts on this subject.



--
Roger Hågensen, Freelancer, http://skuldwyrm.no/

Re: [whatwg] Some Clarification on CML Proposal

[Roger Hågensen]

On 2016-10-06 03:45, Jacob Villarreal wrote:
 > Hi,Thanks for responding. I don't think you have the right picture

I'm pretty sure I don't have the right picture (or at least your picture).

 > I was actually proposing a new markup language referred to as 
content markup language. The hypertext part of it isn't that important. 
CML would has the linking capability, it's really nothing. The batch 
infrastructure I was talking about is as simple as text batch files 
containing the source path information of multiple object source files, 
such as bitmaps, jpegs, text files, apps, etc... I think all that is 
required by the HTML team is to create a batch file for every appliance 
that is needed with respect to the two tags, multiple type attributes, 
and subattributes, and the line sequencing shouldn't be too much of a 
problem either.


"all that is required", I think the emphasis here is on "all" as it 
sounds like a full rewrite.


 > I think this solution would completely phase out HTML all together,
 > You shouldn't be so concerned about all the technical html bullshit, 
there are no headers, and footers, only page coordinates, and source files.


You obviously have a dislike for HTML for some reason.

 > I just thought a high def bitmap solution might work well for field 
objects. Basically, taking a bitmap object, and applying a border, text 
space, etc.., for use as the actual graphical object for the input field


This sounds like a graphical background template of some sorts.
Have you actually looked at what you can do these days with CSS3?

 > So I thought the html team might just set it up to work that way. I 
think it's a worthwhile option in the www world. Like I said, I don't 
have much experience doing html


Apparently you have some programming or database experience, but with 
the things you are suggesting it's far more "just add a few things" to 
the existing browsers.


What you are talking about would require a new browser engine. Usability 
(those who are blind or have weak sight) would go out the window. The 
overhead would be immense with everything as bitmaps. (text compresses 
extremely well by comparison). Responsive web design would no longer work.


I suspect what you want already exists but you are unable to see/find 
the way to do it. I'm pretty sure the tools required to do what you want 
already exists.


It sounds like you are trying to invent include files of some sorts 
(similar to .h in C).
Also your focus on bitmaps and coordinates, you do know that CSS allow 
you to define fixed X and Y positions?


 > structuring the mapping with one folder with all of it's objects, 
per every page on the site.  So the objects, whether they be text, or 
image objects are called up from the root of the page for the most part. 
 As far as I know, the header attributes are used on text for font, and 
size, etc..  CML would use the same attribute function on text anyway, 
but you have the option of using text images as content as well.


I don't think yo have any idea of what HTML is/does.
HTML handles the structural and semantic part of a web page, CSS the 
graphical and styling and look, and Javascript the scripting.


 > it's just a more innovative URL solution than html.  Personally, I 
think html is kind of boring in comparison


How innovative this is (I find it just confusing myself) is 
questionable, and your statement about HTML being boring is, well I 
doubt that any language be it markup up scripting or programming is 
anything but boring. They tried to make programming fun once and the 
result was Point'n'Click programming, that never really took off.


 > ...real-time data from ticker data being sent to the form, and store 
it in real-time in the ticker_data.rec destination record as text by 
line sequentially.  The data can then be accessed in runtime 
sequentially ... real-time output to a web app.


This would make local (file://) apps impossible, you seem to describe a 
system that fetched data in real time from a database server.
If this was a stockmarket monitor or sports monitor or airport monitor 
on a wall then I might understand what you are trying to do but even 
then the current HTML + CSS + Javascript solution would be way more 
efficient (and if using Websocket any latency is basically gone, only 
limited by LAN latency).


 > I'm trying to get some information on how to implement some new 
tags/attributes on the backend.


This is far more than just "adding some new tags", you want to add tags 
to discard HTML and CSS and Javascript.


 > correction on the code above
I can't help but feel that your "code" is little more than a variant of 
a link tag.


I'm not trying to be mean or anything, I just can't see what you are 
envisioning.




--
Roger Hågensen, Freelancer, http://skuldwyrm.no/

Re: [whatwg] Some Clarification on CML Proposal

[Roger Hågensen]

On 2016-10-06 04:42, Jacob Villarreal wrote:

Roger,
I thought I should send you the pdf diagram anyway.  I've attached it 
to this email.  Hope it gets through to you.

Jacob


That was little more than a PDF with bullet points.
It certainly was not a diagram, this is a (example) of a kind of diagram 
http://www.conceptdraw.com/solution-park/resource/images/solutions/fishbone-diagram/Business-Productivity-Ishikawa-Diagram-Factors-Reducing-Competitiveness-Sample24.png




--
Roger Hågensen, Freelancer,http://skuldwyrm.no/

Re: [whatwg] Some Clarification on CML Proposal

[Roger Hågensen]

On 2016-10-06 04:42, Jacob Villarreal wrote:

Roger,
I thought I should send you the pdf diagram anyway.  I've attached it 
to this email.  Hope it gets through to you.

Jacob


That was little more than a PDF with bullet points.
It certainly was not a diagram, this is a (example) of a kind of diagram 
http://www.conceptdraw.com/solution-park/resource/images/solutions/fishbone-diagram/Business-Productivity-Ishikawa-Diagram-Factors-Reducing-Competitiveness-Sample24.png




--
Roger Hågensen, Freelancer, http://skuldwyrm.no/

Re: [whatwg] Some Clarification on CML Proposal

[MegaZone]

On Thu, Oct 6, 2016 at 7:42 AM, Jacob Villarreal  wrote:

> Sorry, correction on the code above:
>  record:path/ticker_data.rec/+1>or, record:path/ticker_data.rec/29>
> Thanks.
>

How is this any different from PHP, ASP, JSP, .Net, ColdFusion, etc?  You
could implement your CML on the backend and have it 'output'
XML/HTML+JavaScript+CSS for delivery to user agents with compatibility with
everything out there today.

If you want to try to replace HTML, JavaScript, and CSS so that every user
agent needs to understand CML natively - that's just not going to happen.

There are many server-side options and it really sounds like that's where
CML would fit.  Your developers would write in CML, and the 'engine' would
render that into the appropriate content for delivery to UAs.

Personally I don't see value in this proposal.

-- 
-MegaZone / Geek, Gweep, Technophile, me. / Hail Eris, All Hail Discordia
Personal: Google+  /
Facebook  / Twitter
 / LinkedIn
 / LiveJournal
 / Web  /
Email 
Editor, Gizmo Lovers: Blog  / Google+
 / Facebook
 / Twitter
 / Email 
"A little nonsense now and then, is relished by the wisest men" 432-363-4296

Re: [whatwg] Some Clarification on CML Proposal

[Jacob Villarreal]

Sorry, correction on the code above:
or,
Thanks. 

On Thursday, October 6, 2016 4:56 AM, Jacob Villarreal  
wrote:
 

 Hey Roger,So what's the difference in retrieving an image file by means of 
html, from a database/folder, in contrast with retrieving an image file from a 
CML tag which calls it up from a database/folder?  What I thought might work, 
is structuring the mapping with one folder with all of it's objects, per every 
page on the site.  So the objects, whether they be text, or image objects are 
called up from the root of the page for the most part.  As far as I know, the 
header attributes are used on text for font, and size, etc..  CML would use the 
same attribute function on text anyway, but you have the option of using text 
images as content as well.  I don't think there are any overhead issues with 
CML.  If you analyze it, you might figure that it's the same as far as overhead 
is concerned, but it's just a more innovative URL solution than html.  
Personally, I think html is kind of boring in comparison.  I think CML is alot 
easier to use, and has alot more capability.  I haven't really gone over all of 
the possibilities, but I've figured web developers can develop really 
sophisticated web apps with it.  Like, for example:
or,

This simple code would take the real-time data from ticker data being sent to 
the form, and store it in real-time in the ticker_data.rec destination record 
as text by line sequentially.  The data can then be accessed in runtime 
sequentially with a +1, or by specific line (as with '29'), for real-time 
output to a web app.  I think it's pretty neat.  Let me know what you think.  
Maybe we can work on it to get it implemented.Later,Jacob 

On Thursday, October 6, 2016 4:26 AM, Shane Hudson 
 wrote:
 

 It sounds like you want to use a massive image map for entire websites? There 
are many accessibility (not to mention performance) issues with doing that.
On 6 Oct 2016 2:45 a.m., "Jacob Villarreal"  wrote:

Hi,Thanks for responding.  I don't think you have the right picture as to what 
I was proposing.  I'll try to clear it up a bit.  I was actually proposing a 
new markup language referred to as content markup language.  The hypertext part 
of it isn't that important.  CML would has the linking capability, it's really 
nothing.  The batch infrastructure I was talking about is as simple as text 
batch files containing the source path information of multiple object source 
files, such as bitmaps, jpegs, text files, apps, etc...  I think all that is 
required by the HTML team is to create a batch file for every appliance that is 
needed with respect to the two tags, multiple type attributes, and 
subattributes, and the line sequencing shouldn't be too much of a problem 
either.  I think this solution would completely phase out HTML all together, as 
it can pretty much do anything a web developer would need, even cold fusion 
class web applications.  You shouldn't be so concerned about all the technical 
html bullshit, there are no headers, and footers, only page coordinates, and 
source files.  As far as the digital container part of it, there isn't any 
container process involved, I just thought a high def bitmap solution might 
work well for field objects.  Basically, taking a bitmap object, and applying a 
border, text space, etc.., for use as the actual graphical object for the input 
field, for example.  So I figured that the standard field/table graphics that 
are produced by html are produced as bitmap objects, basically, and that a 
bitmap image could theoretically be used as a field object within a form 
graphically, and with the input text space applied.  So I thought the html team 
might just set it up to work that way.  I think it's a worthwhile option in the 
www world.  Like I said, I don't have much experience doing html, but please 
let me know what you think.  I wouldn't mind working with someone on this to 
get it deployed, if possible.  I can send a pdf diagram to give you a better 
picture of the whole thing, if you like.  Just let me know.Later,Jacob

    On Wednesday, October 5, 2016 6:04 PM, Roger Hågensen 
 wrote:


 On 2016-10-05 08:17, Jacob Villarreal wrote:
 > I was proposing a really simple markup language.  I call it content
markup language (CML).

You do realize that HTML stands for Hyper Text Markup Language right?
Adding a markup language to a markup language is illogical, it is better
to improve the existing markup language or create a new markup language
instead.

 > It implements a simple object-oriented content markup infrastructure
which treats every page element as an object.

This sounds like it might be better served by Javascript which is object
oriented.

 > It consists of a simple batch html infrastructure with only four
batch file types for forms, fields, menus, and submenus
(.frm/.fld/.mnu/.smn).   All text objects 

Re: [whatwg] Some Clarification on CML Proposal

[Jacob Villarreal]

Hey Roger,So what's the difference in retrieving an image file by means of 
html, from a database/folder, in contrast with retrieving an image file from a 
CML tag which calls it up from a database/folder?  What I thought might work, 
is structuring the mapping with one folder with all of it's objects, per every 
page on the site.  So the objects, whether they be text, or image objects are 
called up from the root of the page for the most part.  As far as I know, the 
header attributes are used on text for font, and size, etc..  CML would use the 
same attribute function on text anyway, but you have the option of using text 
images as content as well.  I don't think there are any overhead issues with 
CML.  If you analyze it, you might figure that it's the same as far as overhead 
is concerned, but it's just a more innovative URL solution than html.  
Personally, I think html is kind of boring in comparison.  I think CML is alot 
easier to use, and has alot more capability.  I haven't really gone over all of 
the possibilities, but I've figured web developers can develop really 
sophisticated web apps with it.  Like, for example:
or,

This simple code would take the real-time data from ticker data being sent to 
the form, and store it in real-time in the ticker_data.rec destination record 
as text by line sequentially.  The data can then be accessed in runtime 
sequentially with a +1, or by specific line (as with '29'), for real-time 
output to a web app.  I think it's pretty neat.  Let me know what you think.  
Maybe we can work on it to get it implemented.Later,Jacob 

On Thursday, October 6, 2016 4:26 AM, Shane Hudson 
 wrote:
 

 It sounds like you want to use a massive image map for entire websites? There 
are many accessibility (not to mention performance) issues with doing that.
On 6 Oct 2016 2:45 a.m., "Jacob Villarreal"  wrote:

Hi,Thanks for responding.  I don't think you have the right picture as to what 
I was proposing.  I'll try to clear it up a bit.  I was actually proposing a 
new markup language referred to as content markup language.  The hypertext part 
of it isn't that important.  CML would has the linking capability, it's really 
nothing.  The batch infrastructure I was talking about is as simple as text 
batch files containing the source path information of multiple object source 
files, such as bitmaps, jpegs, text files, apps, etc...  I think all that is 
required by the HTML team is to create a batch file for every appliance that is 
needed with respect to the two tags, multiple type attributes, and 
subattributes, and the line sequencing shouldn't be too much of a problem 
either.  I think this solution would completely phase out HTML all together, as 
it can pretty much do anything a web developer would need, even cold fusion 
class web applications.  You shouldn't be so concerned about all the technical 
html bullshit, there are no headers, and footers, only page coordinates, and 
source files.  As far as the digital container part of it, there isn't any 
container process involved, I just thought a high def bitmap solution might 
work well for field objects.  Basically, taking a bitmap object, and applying a 
border, text space, etc.., for use as the actual graphical object for the input 
field, for example.  So I figured that the standard field/table graphics that 
are produced by html are produced as bitmap objects, basically, and that a 
bitmap image could theoretically be used as a field object within a form 
graphically, and with the input text space applied.  So I thought the html team 
might just set it up to work that way.  I think it's a worthwhile option in the 
www world.  Like I said, I don't have much experience doing html, but please 
let me know what you think.  I wouldn't mind working with someone on this to 
get it deployed, if possible.  I can send a pdf diagram to give you a better 
picture of the whole thing, if you like.  Just let me know.Later,Jacob

    On Wednesday, October 5, 2016 6:04 PM, Roger Hågensen 
 wrote:


 On 2016-10-05 08:17, Jacob Villarreal wrote:
 > I was proposing a really simple markup language.  I call it content
markup language (CML).

You do realize that HTML stands for Hyper Text Markup Language right?
Adding a markup language to a markup language is illogical, it is better
to improve the existing markup language or create a new markup language
instead.

 > It implements a simple object-oriented content markup infrastructure
which treats every page element as an object.

This sounds like it might be better served by Javascript which is object
oriented.

 > It consists of a simple batch html infrastructure with only four
batch file types for forms, fields, menus, and submenus
(.frm/.fld/.mnu/.smn).   All text objects would be text data.  All
other objects would be treated in the standard manner, but would be
applied at the corresponding page coordinate. ... 

Re: [whatwg] Some Clarification on CML Proposal

[Jacob Villarreal]

Hi,Thanks for responding.  I don't think you have the right picture as to what 
I was proposing.  I'll try to clear it up a bit.  I was actually proposing a 
new markup language referred to as content markup language.  The hypertext part 
of it isn't that important.  CML would has the linking capability, it's really 
nothing.  The batch infrastructure I was talking about is as simple as text 
batch files containing the source path information of multiple object source 
files, such as bitmaps, jpegs, text files, apps, etc...  I think all that is 
required by the HTML team is to create a batch file for every appliance that is 
needed with respect to the two tags, multiple type attributes, and 
subattributes, and the line sequencing shouldn't be too much of a problem 
either.  I think this solution would completely phase out HTML all together, as 
it can pretty much do anything a web developer would need, even cold fusion 
class web applications.  You shouldn't be so concerned about all the technical 
html bullshit, there are no headers, and footers, only page coordinates, and 
source files.  As far as the digital container part of it, there isn't any 
container process involved, I just thought a high def bitmap solution might 
work well for field objects.  Basically, taking a bitmap object, and applying a 
border, text space, etc.., for use as the actual graphical object for the input 
field, for example.  So I figured that the standard field/table graphics that 
are produced by html are produced as bitmap objects, basically, and that a 
bitmap image could theoretically be used as a field object within a form 
graphically, and with the input text space applied.  So I thought the html team 
might just set it up to work that way.  I think it's a worthwhile option in the 
www world.  Like I said, I don't have much experience doing html, but please 
let me know what you think.  I wouldn't mind working with someone on this to 
get it deployed, if possible.  I can send a pdf diagram to give you a better 
picture of the whole thing, if you like.  Just let me know.Later,Jacob 

On Wednesday, October 5, 2016 6:04 PM, Roger Hågensen 
 wrote:
 

 On 2016-10-05 08:17, Jacob Villarreal wrote:
 > I was proposing a really simple markup language.  I call it content 
markup language (CML).

You do realize that HTML stands for Hyper Text Markup Language right? 
Adding a markup language to a markup language is illogical, it is better 
to improve the existing markup language or create a new markup language 
instead.

 > It implements a simple object-oriented content markup infrastructure 
which treats every page element as an object.

This sounds like it might be better served by Javascript which is object 
oriented.

 > It consists of a simple batch html infrastructure with only four 
batch file types for forms, fields, menus, and submenus 
(.frm/.fld/.mnu/.smn).   All text objects would be text data.  All 
other objects would be treated in the standard manner, but would be 
applied at the corresponding page coordinate. ... the table, and field 
html elements are bitmap objects ...

This sounds overtly complicated. Also if things are purely bitmaps then 
that would cause issues with screen readers, there are enough issues 
with tables as it is, if they become bitmaps they'll be a huge pain in 
the ass (more than currently).

By the sound of it these file types are container formats, why would you 
put a PNG image file inside a container file? Server side filetype 
negotiation would need to be redesigned to handle this as well.

Perhaps HTML imports is what could be the solution you are seeking (or 
needing), it's still a draft though
http://w3c.github.io/webcomponents/spec/imports/
But Mozilla has decided to not support it (that was in 2014 though).

But there is also Javascript imports
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/import
"The import statement is used to import functions, objects or primitives 
that have been exported from an external module, another script, etc."
And sounds closer to some of the stuff you mentioned by the sound of it.
Chrome an Firefox should support import, and Edge is in the process of 
adding modules.
https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond/#PQc593TJJwqRbpO4.97
But the specs are still not complete yet as far as I can tell.

A "modular" web page where a header and footer and menu and other parts 
can reside in different files without the need for server side scripting 
is very close.

In the meantime have you tried iframe with the seamless attribute and 
some javascript?



-- 
Roger Hågensen, Freelancer, http://skuldwyrm.no/


   

Re: [whatwg] Some Clarification on CML Proposal

[Roger Hågensen]

On 2016-10-05 08:17, Jacob Villarreal wrote:
> I was proposing a really simple markup language.  I call it content 
markup language (CML).


You do realize that HTML stands for Hyper Text Markup Language right? 
Adding a markup language to a markup language is illogical, it is better 
to improve the existing markup language or create a new markup language 
instead.


> It implements a simple object-oriented content markup infrastructure 
which treats every page element as an object.


This sounds like it might be better served by Javascript which is object 
oriented.


> It consists of a simple batch html infrastructure with only four 
batch file types for forms, fields, menus, and submenus 
(.frm/.fld/.mnu/.smn).   All text objects would be text data.  All 
other objects would be treated in the standard manner, but would be 
applied at the corresponding page coordinate. ... the table, and field 
html elements are bitmap objects ...


This sounds overtly complicated. Also if things are purely bitmaps then 
that would cause issues with screen readers, there are enough issues 
with tables as it is, if they become bitmaps they'll be a huge pain in 
the ass (more than currently).


By the sound of it these file types are container formats, why would you 
put a PNG image file inside a container file? Server side filetype 
negotiation would need to be redesigned to handle this as well.


Perhaps HTML imports is what could be the solution you are seeking (or 
needing), it's still a draft though

http://w3c.github.io/webcomponents/spec/imports/
But Mozilla has decided to not support it (that was in 2014 though).

But there is also Javascript imports
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/import
"The import statement is used to import functions, objects or primitives 
that have been exported from an external module, another script, etc."

And sounds closer to some of the stuff you mentioned by the sound of it.
Chrome an Firefox should support import, and Edge is in the process of 
adding modules.

https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond/#PQc593TJJwqRbpO4.97
But the specs are still not complete yet as far as I can tell.

A "modular" web page where a header and footer and menu and other parts 
can reside in different files without the need for server side scripting 
is very close.


In the meantime have you tried iframe with the seamless attribute and 
some javascript?




--
Roger Hågensen, Freelancer, http://skuldwyrm.no/