Re: [whatwg] Some Clarification on CML Proposal

Sorry, correction on the code above:
<source port:[ticker_port]><destination record:path/ticker_data.rec/+1>or,<destination record:path/ticker_data.rec/29>
Thanks. 

    On Thursday, October 6, 2016 4:56 AM, Jacob Villarreal <jv1597@yahoo.com> 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:
<source form:path/ticker.frm:coord><destination record:path/ticker_data.rec/+1>or,<destination record:path/ticker_data.rec/29>

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 <successcircuit@gmail.com> 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" <jv1597@yahoo.com> 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 <rh_whatwg@skuldwyrm.no> 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/

Received on Thursday, 6 October 2016 11:45:59 UTC