I'm a little curious about how the editing of Google Docs works. How did they implement an editor within the DOM? It does not really looks like a form with a textarea, but rather a normal document body with an additional cursor. I guess it is some javascript technique behind.
Is there any free library that I can use for achieving this kind of functionality, or how can I implement it myself?
2019 Update
I'm pretty certain the answer below was accurate at time of writing in 2010 but has been substantially inaccurate for several years. Here's an answer of mine to a similar question in 2012 that may be more accurate, although still possibly not massively helpful.
How does Google Docs achieve content editing?
Original answer
It uses editing functionality built into all modern desktop browsers, accessed at document level via setting the designMode property of the document to "on", or at an element level by adding a contenteditable attribute with value "true" (also triggered by setting the contentEditable property of an element to the string "true").
A very common strategy for editing a piece of content in a web page is to include an iframe whose document has designMode turned on.
Coupled with this is document.execCommand, which in an editable document can be used to apply various kinds of formatting. For example:
document.execCommand("bold", false, null);
... will toggle whether the selected text is bold. There is a pool of common commands between browsers but there are some discrepancies as to exactly how some are implemented. More info can be found here at MSDN for IE and here at MDC for Firefox. Can't seem to find documentation for WebKit.
Since mid-2010 Google Docs seems to completely having switched away from relying on the browser for editing mode.
Instead they built their own text/HTML editor using JavaScript and DOM.
They explain it in a lengthy blog posting on how they implemented the functions.
Having searched for 3rd-party vendors offering similar concepts, I found no one so far. Would have been a great for iOS since they seem to not support the contentEditable attribute until iOS 5 (and even then, there are issues)
For mee it looks like any HTML editor. They just coded their own JavaScript HTML editor. Even the HTML edit view doesn't have any magic.
A good and free HTML editor is TinyMCE but there are many others out there, even some very powerfull proprietary like CuteEditor which is available for PHP and ASP.NET.
BTW: The content of the document (in Google Docs) is placed in an iframe, just as it is in CuteEditor (and probably also in TinyMCE).
As other people have said, google is very uptight about what information they share. However, they have posted a lengthy blog idea about how they built their own word processing system FROM SCRATCH. Building this, would require you to have your own experience team with several days needed to complete it.
Link to lengthy blog is here:
https://drive.googleblog.com/2010/05/whats-different-about-new-google-docs.html
Essentially, they capture where your cursor is, place a div that looks like a line, and manually insert a letter at the place your cursor is
Related
It's really hard to understand how Tinymce can be considered as WYSIWYG, because I cannot get what I see (visually exactly). So it is more likely "what you see is just what you see".
Currently I use getContent() to get the HTML. But it lacks embedded style and if we show that output html in some container, the visual rendering will look different.
I've tried implementing my own solution to help embed the current style (based on getComputedStyle) to each element. But that's not very efficient (many redundant styles can be included) and not always works (such as for embedded video, I'm not so sure why the <video> is not kept with getContent() and all <video>s disappear in the final output html).
The Tinymce team has done a lot of works, but really not sure why they did not even think about this feature? We need the exact HTML that renders what you see in the editor. We can sanitize the HTML after that by ourselves.
Here is a demo helping you imagine better what's so bothersome with this WYSISWYG editor:
https://jsfiddle.net/L83u5v0n/1/
Clicking on the Show HTML button shows this:
So you can clearly see it's just more likely to be WYSIWYS rather than WYSIWYG. Is there a solution to get the exact output HTML based on some hidden feature of Tinymce that I've not known of? If it's based on some custom script using getComputedStyle then really I do not need it (actually my solution is fairly good).
This is a function of demos that are set up to look good in the editor versus real world usage. The intention of the content_css configuration is to provide the CSS that will be used to render the content.
If you apply the content CSS elements to the page then "Show HTML" works perfectly.
https://jsfiddle.net/xzh8utbp/
Alternatively, delete the content_css configuration (but that won't quite work in your example because JSFiddle adds CSS to the result window).
Note that I've added mce-content-body to the view div because it turns out our codepen demo CSS leverages it. Normally that wouldn't be required, but then I don't think normal integrations use our codepen CSS.
I'm learning web design, and there is no better method than redoing others work. So I'm reading other pages code, but it's so hard to find the jQuery, Javascript or modernizer or ... code responsible for the effect.
I'm using firebug, also used firequery, but the problem is they give me the event but not the code and a big tree of DOM, I don't know where even I look into it.
I really don't care which event is triggered, but I do care how the code is written. If I find the code so I can understand the event is on click or on focus...
Or let's say a website has a some javascript file, linked to a website. when I load the webpage i get a webpage consist of DOM and external/internal script. When I see a cool effect and want to read the code, I run firebug, inspect element to find the element. After that I don't know what to do? I can't search for selector or event in the script because maybe the developer of the site used different selector that I'm searching. Sometimes I find the code, but it's so jammed, not in human readable form, I don't know how to change the code to something indent and neat
The problem becomes more dramatic when the website using other java framework than jQuery.
I've searched a lot, used many tools, but couldn't find anything useful, please with your advice light my way to learn web developing
edit:--
I found a way but I'm sure there should be a better way outside
first in chrome I inspect the element to find the corresponding element, then i right click and check all the break point on it(if it doesn't work i do the same for parent element)
after that i play with that element to trigger the function and it break
usually the function that called the method is down in the callstack
also for reading
also for reading the script i use pretty print of chrome, i used some online prettyfier but most of them has limitation in number of character, for a long script none of the google first page resault is good enough. so the only good option here is for now is chrome, anyone have any other method?
It is difficult to learn how to do things just from inspecting it, as many effects may be implemented entirely in JavaScript, which may be deep, hidden away in a source file.
You mention that the code is not in human readable form, beautifying it may help:
https://stackoverflow.com/a/6318092/1061602
Most 'visual' effects should be able to be viewable from the CSS, e.g. JQuery Mobile's buttons, it is possible to see how the different classes are combined, ui-shadow, ui-btn, ui-disabled etc
Otherwise, searching for selectors is pretty much all you can do. Personally, if I am learning, looking at too much code at one time can be overwhelming. Also a lot of the UI effects may be difficult to trace.
My advice is, perhaps a better way around it would be to try and describe one single effect that you require, and then search on Google or Stack Overflow for guidance on how to create that effect.
The usual documentation sources will be useful:
http://www.w3schools.com/css3/default.asp
http://api.jquery.com/
Happy learning!
I'm working on an ASP.NET MVC project which uses the MarkdownDeep Editor to add a rich editor on top of a basic markdown input textbox (very similar to the Stackoverflow editor window).
Generally it works great. However, in certain scenarios, I would like to disable the preview window. This is automatically generated below the textarea by MDD. Can this be disabled?
Just to be clear, I know I can use CSS to hide the preview. But on some devices it's slow and makes typing painful. I want to entirely turn off that feature. I don't see anything in the docs other than how to customize the preview.
Any ideas?
In the docs it specifically mentions that it is recommended that you have the div preview already in your document because it will be created if it isn't found and consequently, could could a visible page refresh if any re-layout has to occur.
Note: the associated divs are all optional and if missing, the plugin will create them. However... you might experience the page jumping around during load if you do this. ie: it's recommended to explicitly include them.
Thus from the sounds of this, and that there doesn't appear to be any option to turn it off in the API page I would say no, it's not possible.
I am a little confused here: if you don't want the preview, use a regular text area instead of mdd_editor... So, under the scenarios where you don't need the previews, instantiate a plain vanilla editor. What am I missing here?
I know this is old, but I was looking for something else on mdd. I recently had this same requirement.
Just comment out the code
// Update the DOM
if (this.m_divHtml)
this.m_divHtml.innerHTML=output;
in MarkdownDeepEditor.js
I have a question about Javascript widgets. The widget I am working on simply embeds content on a page instead of using iframes. So far it looks good. But there are cases where some users layouts are messing up the widget. For example, the widget might require a width of 300px to appear. But the parent div is set to 250px and hence the right part of the widget is cut off.
I was wondering what sort of precautions should be taken to prevent this? I was talking to the product manager who mentioned he wanted me to check the parent div elements and get the size and then show an alternate message if their size is not accurate. But again, since this is Javascript and the widget is supported in many diff browsers(including IE6), I am wondering how fail-safe this method would be? What if I need to iterate the DOM all the way up before getting a valid size? I am also worried about performance here. This extra checks would slow down the delivery of my widget content to "good users" since I am adding a layer of complexity to all users. I don't want to penalize good users just because of the few errant ones.
I am not using any sort of JS library here, so any solution should not suggest the use of one. Also, the reason for not using a library was simply not to add extra weight to the page load to deliver a widget. I understand that "jquery" for example is small, but in my case, even 24k compressed seems like an overkill for a widget delivery that contains no core code for the widget.
Has anyone dealt with such issues before? What are your solutions to these?
There are reliable ways of determining the size of an element using JavaScript. You're quite right that you may need to iterate up the tree in some cases, but the answer you get will ultimately be quite valid.
Although you don't want to directly include any library code in this project, you may consider looking at how the major libraries implement their "what's the width of this element" functions to drive your own implementation.
Beware of quirks mode too.
I'd check to see of the page has Jquery, if not load it into the page using no-conflict mode. Then use jQuery to examine the page.
See: How to embed Javascript widget that depends on jQuery into an unknown environment
Uhm I'm not sure if anyone has encountered this problem
a brief description is on IE6 any <select> objects get displayed over any other item, even div's... meaning if you have a fancy javascript effect that displays a div that's supposed to be on top of everything (e.g: lightbox, multibox etc..) onclick of a certain element and that div overlaps a <select> your div get's to be displayed as if it's under the <select> [on this case a max and minimum z-index doesn't work ]
I've tried googling and found the iframe shim solution
but I wanted some pretty clean alternatives
or better yet has anyone found a better solution?
since the method using iframes uses around 130mb of ram might slow down poor people's machines
You don't have to hide every select using a loop. All you need is a CSS rule like:
* html .hideSelects select { visibility: hidden; }
And the following JavaScript:
//hide:
document.body.className +=' hideSelects'
//show:
document.body.className = document.body.className.replace(' hideSelects', '');
(Or, you can use your favourite addClass / removeClass implementation).
There is a plugin for jquery called bgiframe that makes the iframe method quite easy to implement.
Personally, as a web developer, I'm to the point where I no longer care about the user experience in IE6. I'll make it render as close to "correct" as possible, and make sure it's functional, but as far as speed goes, too bad. They can upgrade. IE7 (though still quite slow, compared to every other browser) has been out for 2 years (almost to the day!). IE8 is going to be out shortly. Firefox is available for every platform. Safari is also an option (and super fast). Opera is available for most/every platform.
IE6 was released in over 7 years ago. IMHO, there is no reason to still be using it, other than lazy users and incompetent IT departments (or if you're a web developer).
in case anyone is interested, here's some IE shimming code.
* html .shimmed {
_azimuth: expression(
this.shimmed = this.shimmed || 'shimmed:'+this.insertAdjacentHTML('beforeBegin','<iframe style="filter:progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=0);position:absolute;top:0px;left:0px;width:100%;height:100%" frameBorder=0 scrolling=no src="javascript:false;document.write('+"''"+');"></iframe>'),
'inherit');
}
ref: this gist by subtleGradient and this post by Zach Leatherman
Prior to IE7 the drop down list was a "windowed" control meaning that it was rendered as a control directly by Windows rather than the browser synthesizing it. As such, it wasn't possible for it to support z-indexing against other synthesized controls.
In order to appear over a DDL, you must use another windowed control, like IFRAME. You can also use a little known IE-only feature called window.createPopup() which essentially makes a chromeless popup. It has limitations, like unstoppable click-out, but they are actually kinda helpful if you are building a hover menu system.
The simplest and most elegant solution to that annoying IE bug is found at: http://docs.jquery.com/Plugins/bgiframe using jQuery.
I reached that conclusion after trying for 2 days to make it work with WebSphere Portal / Portal Applications where everything is dynamic, including the fly-over menu.
There's also the activex method, which I'm starting to explore. It requires creating conditional code to use an activex control instead of a select box for ie6. There's a demo script showing the technique, which is discussed in more detail here.
Update: it appears that MS Office is required for the active-x control to be on the user's machine. In theory, it might be possible to include that somewhere, somehow, but that's getting a lot messier.
I know many people suggested their own tips, but in my case, I just simply hide select using jquery like the below.
$(':date').dateinput({
format: 'dd/mm/yyyy',
onBeforeShow: function(event) {
$('select').hide();
},
onHide: function(event) {
$('select').show();
}
});