Low level browser functions

did u check the tinyMCE examples page: http://www.tinymce.com/tryit/full.php

Yes, I've been ll over their pages.    As far as I can see their documentation just talks about what their software does.  My question is, what low-level functions are they relying on from the browser?   What low level functions are available from a browser?  Apparently the browser will send you an event object when you click that shows the XY values at the point you clicked and the HTML that created the element you clicked.  And I think it will set selected text to bold or italics for you.  What else will it do, and where is all this documented?

If TinyMCE is open source, there should be a document detailing the code for the API.

Cd&

Cd&,
Thanks for master link.  There are definitely some interesting sections there I'll have to go through.

If TinyMCE is open source, there should be a document detailing the code for the API.

As far as the events go, there doesn't seem to be much of an API.  It looks like TinyMCE just registers a handler, somehow, and then the browser calls it with the event all wrapped up: the xy clicked, the outerHTML for the element at that location, etc., etc.  It's the browser behavior that I'm interested in.Just exactly what services does a browser provide at this low level.

As far as editing the page, I saw something in the master document you referenced about "contenteditable." I think this has to be set to enable the browser to edit the page.  But I didn't see much more.  A search of the master document for "bold" for example came up empty.

Some of what the browser has to do to support an editor is operating system dependent.  The actual primitives being executed are not exposed for security reasons.  To access the code the browser has to have privilege to private code.  It already has that access and the pipes necessary. To render, it must have access to the O/S primitives.  At the very lowest level, making something display bold is a matter of setting or clearing bits. The XY co-ordinates actually have to get translated to addresses in the graphic array and that then has to be converted to signals for the display device.

The browser is 4 layers of abstraction away from the actual machine/device level code that causes a change in the display. At the primitive level all the hardware understands are binary toggles. How a given effect is implemented is dependent on the interfaces between the layers, and in the end the code is specific to the chipset the device is using.  Without the abstracted layers there would be no real security, and you would have to code a different page for every browser/os/device combination you wanted to support.

Cd&

I'm not interested in anything so low that it's OS dependent. My interest is what functions the generic browser exposes upward.  I was surprised when I saw the TinyMCE code getting click events  from the browser that not only specified the xy location of the click but also the HTML element at that location. So the HTML for a TinyMCE  image or button never has an  onclick=function() built into it, as normal HTML clickable elements have. The code just looks in the event object to see the element that was clicked and then jumps directly to the correct function for that element.  (Thinking more about it,  it was actually easy for the browser to know the element at the clicked xy since the browser put the element there  in the first place.)

 I'm looking for the kind of information I would need if I were writing my own rich text editor in JavaScript. What information will the browser give me about events, how do I register my handlers for those events, what can I ask the browser to do for me (change some selected text to bold, italic, etc. ), what else does it know how to do,  and how do I issue those commands to the browser.

This all must be documented somewhere.

The event model is documented in the W3C specs, but the  code to implement those specs is browser specific.  You would have to look at source code for the open source browsers, and see what sort of API support is available for closed browsers.

If you are going to try and duplicate the functionality of an RTE, you are embarking on a major project that will take perhaps as much as a year to support a range of browsers; with probably 5 or 6 weeks of research just to write the requirements and do a design.

If you are doing a scaled back RTE then the time required will reflect the amount of functionality you actually deliver.  If it is your intent to do this as a commercial product then you better have deep pockets because the marketing to get enough market share to show a profit will probably run run 7 figures.  It does not matter how good your pruduct is, the market is well established and the barriers to entry are formidable.

Cd&

BTW, if you are not prepared to learn and understand the primitives that are the underpinning of the browser functionality, you will not be successful developing anything competitive.  You will just have a slow toy.

Cd&

Thanks for the discussion.