WO2009124584A1

WO2009124584A1 - Browser based text and code processing

Info

Publication number: WO2009124584A1
Application number: PCT/EP2008/054182
Authority: WO
Inventors: Eike N. Ackermann
Original assignee: Ackermann Eike N
Priority date: 2008-04-07
Filing date: 2008-04-07
Publication date: 2009-10-15
Also published as: EP2277115A1

Abstract

The invention provides methods and apparatus, including computer program products, for editing an electronic document based on user input, the document being displayed in a web browser, the document comprising characters coded in a document description language, the method comprising the steps of: converting at least one character of the document into at least one element which is individually addressable in the document description language in the web browser; addressing the at least one element of the document; processing the at least one addressed element on the basis of the user input.

Description

Browser Based Text and Code Processing

BACKGROUND OF THE INVENTION

This application relates to browser based text and code processing, and in particular to methods for building a real-time WYSIWYG text and / or code editor for web pages coded in HTML, XHTML or any other web page description language.

STATE OF THE ART

Current WYSIWYG solutions for web documents mostly use a text input element like <textarea> styled according to the web page to capture user input. This approach gets quite close to the actual end result, but has limitations as the editable text has to be inside a text area, and is thereby limited to the text area itself.

Another approach is based on the use of browser specific "edit modes". This approach is limited as it is based on proprietary technology that varies from browser to browser and therefore is not cross browser compliant. Furthermore, as the browser is set to a specific mode the editing capabilities depend on the function delivered by the browser manufacturer. Further, the browser is either in code or in preview mode, limiting the user to see one mode at a time, but not both. If only parts of a web page should be edited, these parts would have to be in a separate window, or in an I-frame, which would cause the same limits as described above in connection with the text areas of the "edit modes".

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a method and system for ensuring real-time nearly 100% exact cross browser WYSIWYG functionality without installing software components on the client side.

In general, in one aspect, this invention provides methods and apparatus, including computer program products, for editing an electronic document based on user input, the document being displayed in a web browser, the document comprising characters coded in a document description language, the method comprising the steps of: - converting at least one character of the document into at least one element which is individually addressable in the document description language in the web browser; addressing the at least one element of the document; processing the at least one addressed element on the basis of the user input.

Advantageous implementations can include one or more of the following features.

The method may further comprise: Capturing at least one event on the basis of the user input, and associating the at least one event with the at least one addressed element. The user input may comprise at least one keyboard stroke operation, and processing the at least one addressed element is performed on the basis of the at least one associated event.

The user input may comprise at least one mouse operation, and addressing and processing the at least one element is performed based on the basis of the at least one mouse operation.

The method may further comprise generating position information for the at least one addressed element.

The at least one keyboard stroke operation may comprise at least one text cursor positioning operation, and the position information is associated to the position of the text cursor.

Hereby, the position information may be used to detect an adjacent character of the text cursor position in the electronic document.

The text cursor may be set to a new position based on the detected adjacent char- acter.

The at least one addressed element may be memorized as one of at least one an object and at least one element marked by an attribute.

The at least one memorized addressed element may be used to identify a text selection in the document, and to visualize the text selection in the web browser. A formatting operation may be applied to the identified text selection.

The document may be a web document.

The method may further comprise a step of transforming the document into a document which is coded in a web document description language, the transforming step being executed prior to the converting step.

The method may further comprise: displaying the document comprising the processed element in the browser.

The method may further comprise: after processing the addressed element, converting each element back to the original character.

The step of addressing may comprise a mouse click in the browser.

The step of addressing may comprise a key stroke in the browser.

The addressable element may comprise at least one predefined tag which is invisible for the browser in the web document description language.

The step of converting a character into an element may comprise wrapping around the character at least two predefined tags which are invisible for the browser, one of the predefined tags being placed before the character, and the other of the predefined tags being placed behind the character.

Each character which shall be processable may be converted into a respective element which is individually addressable in the document description language. The step of converting may comprise establishing, in the web document, an array structure which contains references to each element.

The web document may be located on a web server, and the operation may be received from a remote client.

The operation may be received from the same system where the web document is located.

The document may be coded in one of HTML, and XHTML.

In particular, the invention comprises also computer systems for performing the inventive methods.

Furthermore, the invention comprises computer-readable storage media comprising program code for performing the inventive methods, when loaded into a computer system.

One of the advantages of the present invention is that it provides real time WYSIWYG editing capabilities. A further embodiment of the invention provides real-time preview of changes in code and WYSIWYG at the same time. Moreover, the complete browser and website functionality remains available during editing. This is due to the fact that the editing and display are performed in one and the same browser window or area, i.e., without the need to provide additional editing areas or windows. Further, the ability to have more than one cursor is provided. Moreover, the inventive method is cross-browser compliant and capable of delivering standard compliant results.

BRIEF DESCRIPTION OF DRAWINGS Fig. Ia, b, c illustrate a tree structure of a web page according to the state of the art;

Fig. 2 illustrates the process of conversion characters to elements according to the present invention; Fig. 3 summarizes the process flow of the inventive method;

Fig. 4 illustrates the event handling according to the invention;

Fig. 5 illustrates the process flow of the function getSpanIndex();

Fig. 6a illustrates the process flow of the function fmdChar();

Fig. 6b illustrates the process flow of the function fmdCharAbove(); Fig. 6c illustrates the process flow of the function fmdCharBelow();

Fig. 7 illustrates the process flow of the function sync();

Fig. 8 illustrates the process flow of the function fader();

Fig. 9 illustrates the operation "clicking on a character";

Fig. 10a, b illustrates the operation "moving cursor one line up"; Fig. 11 illustrates text selection by mouse;

Fig. 12 illustrates the array corresponding to the operation of Fig. 11; and

Fig. 13 illustrates visual appearance of the operation of Fig. 11.

DETAILED DESCRIPTION

The present invention may be implemented using any programming language that provides methods for modifying web documents and for capturing mouse and key events, and is executable by a browser is suitable for the described invention. Current languages providing the desired method include amongst others JavaScript, JScript, VBScript etc. The functionality may both be provided based on a script or based on a plug-in. In this document we will assume implementation based on a script, as this avoids the need for installment of a plug-in on the client side.

Fig. Ia illustrates, as an example, a simple web document containing two para- graphs of text, that is a first paragraph which would appear as "abed", and a second paragraph which would be displayed in a browser as "ABCD" (refer to Fig. Ic). The respective prior art syntax in HTML would be abcd for the first paragraph, and ABCD for the second paragraph. Hereby, indicates the begin of a paragraph, and indicates the end of the paragraph. <body> indicates the begin of the content to be displayed. Fig. Ib illustrates a tree struc- ture which represents these paragraphs.

Fig. Ic illustrates the resulting display of the two paragraphs in a web browser.

Each paragraph may be addressed by referring to the tags. However, for a proper editing solution for a single character of each paragraph this is insufficient, as we need to know the exact position of at least one character, a mouse or text cursor within the paragraph.

In order make characters addressable, according to the invention in a first step, at least one of the characters on the document is converted into an element comprising tags like "". Other tags like , , etc., or custom tags can also be used, as far as they do not influence the visual appearance of the characters they comprise. As used herein, these tags may be referred to as character tags. Thus, the conversion is achieved by wrapping at least one character on the page that is not part of a tag, with character tags like the span tags, or the like.

In the following we will covert all characters to character tags as we consider this the best approach. Converting less than all characters is also possible.

Thus, the two exemplary paragraphs of Fig. Ia, b are converted in a structure as shown in Fig. 2. The tags have no style attached and are invisible to the user but addressable individually. This gives access to any character on the page, and thereby allows modification of all characters and texts the page contains. After having converted all characters into elements, in a second step an array is built denoted here as "allSpans" of all <spans> tags for future reference. In case of the two sample paragraphs given above, the array would contain the following: allSpans[O] refers to the span containing "a" allSpans[l] refers to the span containing "b" allSpans[2] refers to the span containing "c" allSpans[3] refers to the span containing "d" allSpans[4] refers to the span containing "A" allSpans[5] refers to the span containing "B" allSpans[6] refers to the span containing "C" allSpans[7] refers to the span containing "D".

As now each character has been made addressable individually via conversion into a respective element that contains the character, events relating to them can be detected via a global event handling function attached to the document. For example if the user clicks on the element containing the letter "a", the function will receive three events (mouse down, mouse up, click), and the ele- ments that were target of the events (in that case the span containing the letter "a").

The general process flow of the inventive method is illustrated in Fig. 3.

[Event handling] Event handling according to the invention is performed as illustrated in detail in Fig. 4. The purpose of the event handling function is to detect what action the user wants to be taken for what element(s). Therefore, the function determines the event source, and the event type. Examples for the sources of the events are the mouse, and the keyboard.

[Mouse events]

Three different types of mouse events are detected: "mouse down", "mouse up", and "mouse over".

"mouse down" is fired when the user presses the left mouse button down.

"mouse up" is fired when the user releases the left mouse button.

"mouse over" is fired when the user moves the mouse cursor over an element.

1. If the function detects a "mouse down" event it checks whether the event element is a element, a. If this is the case i. it saves the event element (will be called "source" in the following), ii. sets the variable down to indicate that the mouse button is down.

2. If the function determines a "mouse over" event it checks whether the event source element is a target element. a. If that is the case it checks whether the mouse button is down by reading the variable "down". i. Is "down" set to "true", the function moves the id "cursor" to the event source element, and ii. it checks whether the event source element now having the id cursor is different to the element saved as "start". iii. If that is the case we know that the user wants to select the text from the elements saved in "start" to the element having the id "cursor". The selection is set from the element saved as "start" until the element having the id "cursor".

3. If the user releases the mouse button, the function detects a "mouse up" event, sets the variable down to false and sets the id 'cursor' to the element.

[Key events]

4. If the function detects a key pressed event,

a. If the cursor is set: i. If a character key has been pressed, the according character is inserted before the cursor. ii. If no character key has been pressed the function checks whether backspaces has been pressed.

If that is the case it deletes the (character) element before the cursor by addressing the span having the index returned by the function fϊnd- Char("cursor","left"). iii. If BACKSPACE is not pressed the function checks whether the "del" key has been pressed.

If that is the case it sets the id cursor to the having the index returned by the function fϊnd- Char("cursor", "right") and deletes the span that had the id cursor before by referring to the span having the index returned by the function findChar("cursor","left") iv. If DEL has not been pressed the function checks whether return or enter have been pressed. 5 In that case the function starts a new block by splitting the current block at the cursors position, v. If ENTER or RETURN have not been pressed the function checks whether an ARROW key has been pressed.

In that case it determines whether the SHIFT key has 10 also been pressed. a. If the SHIFT key has been held, the user wants to select text. If start is not set

Start is set to the cursor position.

15 b. If the SHIFT key has not been held, the user wants move the cursor without selecting text Start is unset. c. If ARROW UP has been pressed

The id cursor is assigned to the span

20 having the index returned by the function fmdChar("cursor","up"). d. If ARROW DOWN has been pressed

The id cursor is assigned to the span having the index returned by the func- 25 tion fmdChar("cursor","down"). e. If ARROW LEFT has been pressed

The id cursor is assigned to the span having the index returned by the function fmdChar("cursor","left"). 30 f. If ARROW RIGHT has been pressed The id cursor is assigned to the span having the index returned by the function fmdChar("cursor","right"). g. If start is set

Sets the selection from start to cursor.

[getSpanlndex(searchld) function]

The function getSpanlndex(searchld) is described with reference to Fig. 5.

[Purpose]

The function "getSpanlndex" is used to search the global allSpans array for the span having the id passed to the function as "searchld" and return the corresponding index value.

For example, in order to find the index equaling the cursor "getSpanln- dex('cursor')" is called. In case the cursor was set before, the function returns the position of the cursor in the allSpans array. If not so, the function returns -1, indicating that no cursor was found.

[Technical description]

Find the corresponding index by id.

When the function is called it

1. Sets the variable "spansNo" to the number of items the allSpans array con- tains by reading the value of allSpans. length.

2. Sets "i" to zero. 3. Starts a loop.

4. If "i" is smaller than the number of items (spans) in the allSpans array a. If the attribute "id" of the span "allSpans[i]" does not equal "searchld". "i" is incremented by 1 and the loop continues at position 3 b. If the attribute "id" of the span "allSpans[i]^M equals "searchld"

The loop is stopped, as the "span" having the "id" specified in "searchld" has been found and "i" is returned.

5. If "i" is not smaller than the number of items in the "allSpans" array the loop is stopped, as there are no more items to search.

"Cursor" is set to "-1" to indicate that the span having the id specified in "searched" was found.

[Function findChar(searchID , direction)]

The function findChar(searched, direction) is described with reference to Fig. 6a. It returns the closest match the a specified direction relative to the span having the id passed to the function as "searchID" to a predefined range of precision.

The function is used to move the cursor by keystrokes. 1. Call the function getSpanlndex described before with 'cursor 'as searchld to get the index number of the current cursor and save it to the variable i.

2. Check whether i is bigger than - 1.

3. If that is the case the cursor has been set before.

3.1. If the direction is left 3.1.1. And i is bigger than 0, a element is existent at the left hand side.

3.1.1.1. The function return i- 1 as this is the index for the next span left hand side to the current cursor position.

3.2. If the direction is right 3.2.1. And I is smaller than the total number of spans, a is existent at the right hand side. 3.2.1.1. The function returns i+1 as this is the index for the next span right hand side to the current cursor position. 3.3. If the direction is neither left or right

3.3.1.1. Ifit is "up"

3.3.1.1.1. The function calls the function fϊnd-

CharAbove(i) and passes the Index saved in "i" to that function. 3.3.1.1.2. The value retuned by fmdCharAbove(i) is returned.

3.3.1.2. Ifit is "down"

3.3.1.2.1. The function calls the function fϊndCharBe- low(i) and passes the Index saved in "i" to that function. 3.3.1.2.2. The value retuned by fmdCharBelow (i) is returned.

[Function fmdCharAbove(i)]

The function fmdCharAbove(i) is described with reference to Fig. 6b. The func- tion fϊndCharAbove(i) is used to find the closest match to a predefined range of precision for the character in the line above the character in the allSpans Array having the index passed to the function as "i".

1. The left offset of the span having the index "i" is saved for future reference to the variable startLeft. 2. The top offset of the character having the index "i" in the allSpans Array is saved to the variable startTop for future reference.

3. It is checked whether "i" is bigger than zero meaning that there are characters existent in the allSpans Array before the current index. 3.1. If condition 3 is true, the value of "i" is decremented by one and thereby pointing to the character before in the allSpans Array.

3.2. If condition 3 is false there are no characters existent in the allSpans array before the current index. 3.2.1. In that case the function will return the current value of "i"

4. It is checked whether the variable "newLine" has been set.

4.1. If condition 4 is true the left offset of the character having the index "i" in the allSpans Array is compared to the left offset saved in the variable startLeft. 4.1.1. If the saved value is bigger than the current offset left no closer match will be found so the last index saved in the variable "lastl" is returned.

4.1.2. If the saved value is smaller than the current offset left a closer match could be found. 4.1.2.1. The current index is stored in the variable "lastl" for future reference.

4.1.2.2. It is checked whether the current offset top is different to the offset top value stored in newLine.

4.1.2.2.1. If true a the current character is in a new line, so the function will return the index number stored in "lastl" as the closest match.

4.1.2.2.2. If false closer matches are possible so the function start again at 3 and will repeat until the closest match has been found. 4.2. If condition 4 is false the offset top saved in the variable startTop is compared to offset top of the character having the index "i" in the allSpans Array. 4.2.1. If these two values differ the character having the index "i" is in a new line. The offset top value is saved to the variable newLineTop for future reference.

4.2.1.1.1. The function continues at 4.1.2.1. 4.2.2. If these two values do not differ the function starts again at

3.

[Function fϊndCharBelow(i)]

The function fϊndCharBelow(i) is described with reference to Fig. 6c. The function fϊndCharBelow is used to find the closest match to a predefined range of pre- cision for the character in the line below the character in the allSpans Array having the index passed to the function as "i".

1. The left offset of the span having the index "i" is saved for future reference to the variable startLeft.

2. The top offset of the character having the index "i" in the allSpans Array is saved to the variable startTop for future reference.

3. It is checked whether "i" is smaller than the number of index in the allSpans Array meaning that there are characters existent in the allSpans Array after the current index.

3.1. If condition 3 is true, the value of "i" is augmented by one and thereby pointing to the character after the current in the allSpans Array.

3.2. If condition 3 is false there are no characters existent in the allSpans array after the current index.

3.2.1. In that case the function will return the current value of "i" 4. It is checked whether the variable "newLine" has been set. 4.1. If condition 4 is true the left offset of the character having the index "i" in the allSpans Array is compared to the left offset saved in the variable startLeft.

4.1.1. If the saved value is smaller than the current offset left no closer match will be found so the last index saved in the variable lastl is returned.

4.1.2. If the saved value is bigger than the current offset left a closer match could be found.

4.1.2.1. The current index is stored in the variable "lastl" for future reference.

4.1.2.2.1. If true a the current character is in a new line, so the function will return the index number stored in lastl as the closest match.

4.1.2.2.2. If false closer matches are possible so the function start again at 3 and will repeat until the closest match has been found.

4.2. If condition 4 is false the offset top saved in the variable startTop is compared to offset top of the character having the index "i" in the all- Spans Array.

4.2.1. If these two values differ the character having the index "i" is in a new line. The offset top value is saved to the variable newLineTop for future reference. 4.2.1.1. The function continues at 4.1.2.1.

4.2.2. If these two values do not differ the function starts again at

3. [Code processing]

Core of the code processing method described here is the ability to have two synchronized cursors at the same time on the same screen.

[Two cursors]

As we are able to have text cursors without dependency on browser modes we can have more than one cursor at the same time. This means we can visualize user input at the same time in code view and in the original page context.

The method described here uses the previously described methods for cursor positioning and WYSIWYG functionality, with the exception that in code view not only the characters that are not part of a tag, but also the characters the tag itself consists of will be converted to spans and thereby made editable and visible. For code view a div element would be converted as follows:

«/span>div >«/span>/div<span»

On change the spans surrounding the letters the tag consists in will be stripped and written back to the WYSIWYG view and the other way around.

[Function sync()] To synchronize the two cursors the event handling method described before will be expanded by a function called here sync(). The program flow of this function is illustrated in Fig. 7. sync() will be called after each operation of the event handling and synchronize the WYSIWYG and code view on each event, providing real-time preview of changes made, both in WYSIWYG and in code. This means that when for example a key stroke occurs in the WYSIWYG part of the screen the corresponding character will be inserted both as described with reference to Fig. 2 in that part but also in the code part of the window.

The function determines whether code or WYSIWYG view is in focus. In case of WYSIWYG, it copies the HTML code from the code view to the WYSIWYG view, coverts the tags back to html tags by stripping the spans off, and renames the cursor in WYSIWYG to cursor2.

In Case of code view, it copies the HTML code from the WYSIWYG view to the code view, wraps each letter of html tags with spans and renames the cursor in code view to cursor2.

[CodeZoom]

As the element having the id "cursor" is the smallest element in the web page's structure, knowing that element gives the ability reduce or expand the part of the code displayed to the user in the code editing area.

The use of that ability will be demonstrated by starting with the following html tree structure:

<html>

abcd

ABCD

</div>

</body>

<body>

<div>

abcd

ABCD

</div>

</body> <html>

By reading out the innerHTML value of the "cursor'"s parent elements we would get the following results:

In order to allow the user to zoom in and out we will use a fader function as illustrated in Fig. 8.

A click on the strokes on the fader will write the according tagArray inner HTML to the code view and thereby only show the user the part of code he intents to edit.

In the following, an example is given of how the functions described above are working together. For example, to determine the starting point for text input, the mouse button events are read out in order to obtain the (character) that has got the event. The process flow for that is illustrated in Fig. 9.

In the example of Fig. 9, the user may have clicked onto character B on the browser screen, i.e., in the web page. Then, the "document" calls the function assigned to the event. Next, the called function identifies the span element that has got the event. The function sets the cursor to that by assigning the ID "cursor" to the span element.

In order to determine exactly where the user wants to start editing text, the approach described above is extended in the next step by finding out whether the user wants to start editing before or after the character he has clicked on. Here, is will be assumed that if the user has clicked on the left half of the character, he intends to start editing before the character, while if he has clicked on the right half of the character, he intends to start editing behind the character. Thus, it is necessary to detect whether the user has clicked on the first or the second half of the character. The event "pageX" is indicative of where on the page the user has clicked, "off- setLeft" gives the position in horizontal (X) direction of the relative to page, "offset Width" gives the width of the span element. This is illustrated in Fig. 10.

If "pageX" is smaller than "offsetLeft + (offsetWidth / 2)" this means that the user has clicked on the first half of the element. If "pageX" is bigger than the result of the formula, we know, this means that the user wants the cursor be positioned on the right side of the element. In the case illustrated above, pageX would be 128, the result smaller than 131.5, the result of the formula. So is known that the user has clicked on the first half of the element, and the cursor can be set accordingly.

The method described above may be used for detecting the arrow keys. To move the cursor to the left side, the ID "Cursor" is removed, and the ID of the element before the old cursor is set to "Cursor".

To move the cursor to the right side, the ID "Cursor" is removed, and the ID of the element is set to the next span element.

To move cursor up, it is looped backwards through the "allSpans" array described above, and their "offsetLeft" value is compared to that of the cursor. When the one is found whose "offsetLeft" matches closest, the cursor is set as described in above in connection with Fig. 10.

Referring now to Fig. 11, it is explained what happens if the user moves the cursor set at "B" (see Fig. 10) one line up. Fig. 11a illustrates the visual appearance on the screen on the page. Fig. 1 Ib illustrates the process of comparing offset left values. The same principles apply to offset top values. Refer to find- Char(direction, searchID) for more details.

As it can be seen from Fig. 1 Ib, the closest match found in the table of Fig. 1 Ib is equal to the one obtained visually Fig. 11a.

To move the cursor down, the same is done as described before, except that it is looped forward instead of backward.

Referring to Fig. 12, text range selection by use of the mouse is described. When a user selects a text range with the mouse he will press the left mouse button at the starting point of his selection than move the mouse and release the mouse button at the ending point of his selection. This would be represented in the inventive system as illustrated in Fig. 12.

Thus, if the user wants to select the characters b, c, d in the first paragraph a mouse down event for the element containing b is obtained, which is then saved to a variable as the starting point of the selection. Then, as the user moves the mouse, mouse over events are obtained for each span element the user moves the mouse over.

Then, the class "selected" having a light grey background color assigned via CSS (Cascading Style Sheets) is assigned to all spans in between the starting point and the span covered. Due to that the user sees what he has selected immediately. When the mouse button is released we know that the span element that has got that event is the ending point of the selection (in this case the span element comprising the character d). This is illustrated in Fig. 13a. The corresponding visual appearance on the page is shown in Fig. 13b.

For allowing selection of a text range via the arrow and shift keys, the method described above is modified. When the user holds down the shift key, the current cursor position is remembered as the starting point of the selection. When the user presses an arrow key, the method described above is applied to get the new cursor position. Then the selection is set as described above in connection with Fig. 12.

In the following, further applications are described. Exemplary text modifications comprise "delete characters", "insert line breaks", and "insert characters".

"Delete characters" may be implemented via the backspace key or the DEL key. In case of the backspace key, the span element before the curser is removed. In case of the DEL key, the span element after the curser is removed.

"Insert line breaks" may be implemented via the return (or enter) key. When re- turn (or enter) is pressed the first time, a tag is inserted after the cursor. When the return (or enter) key is pressed twice, the tag close to the parent tag at the position before the cursor is removed, and a new tag is started. We compare that event to a character code table and insert a new element containing the character before the cursor.

For formatting texts, the following processing is performed. When the user has selected text we use the information gained the event handling mechanism de- scribed above, and assign the desired formatting by wrapping the selected span elements with the tag suitable for the desired formatting. If the user has not selected text we will loop through the allSpans array searching for the previous and next space character or line break. This gives us the current word, and we wrap the span elements the word consists of with the desired format tag.

For alignment of texts, the following processing is performed. We assign the attribute of the text to the parent tag of the span having the id "cursor". For example if the patent tag is a , and the attribute of the text is "align", and the argument is left, i.e., align the text to the left, the following operation would be performed: .

To change the parent tag type (e.g., . from to <hl>), we get the innerHtml of the parent tag containing the child having the id "cursor", remove the par- ent, and insert a new parent tag at the position of the old one containing the old one's innerHtml.

Clean-up. To save the changes of the web document we remove all tags, leaving only the characters they contain. We now have an ordinary HTML or XHTML compliant page containing all the changes ready for saving.

It should be understood that the clean-up step can be omitted since the web document comprising tags is displayed in any browser in the same way as without tags. The clean-up step is merely performed for size reasons.

The present techniques can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Apparatus of the invention can be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor. Method steps according to the invention can be performed by a programmable processor executing a program of instructions to perform functions of the invention by operating on the basis of input data, and by generating output data. The invention may be implemented in one or several computer programs that are executable in a programmable system, which includes at least one programmable processor coupled to receive data from, and transmit data to, a storage system, at least one input device, and at least one output device, respectively.

Computer programs may be implemented in a high-level or object-oriented programming language, and/or in assembly or machine code. The language or code can be a compiled or interpreted language or code. Processors may include general and special purpose microprocessors. A processor receives instructions and data from memories, in particular from read-only memories and/ or random access memories. A computer may include one or more mass storage devices for storing data; such devices may include magnetic disks, such as internal hard disks and removable disks; magneto -optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non- volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto -optical disks; and CD-ROM disks. Any of the foregoing can be supplemented by or incorporated in ASICs (application- specific integrated circuits).

The computer systems or distributed computer networks as mentioned above may be used, for example, for producing goods, delivering parts for assembling products, controlling technical or economical processes, or implementing telecommunication activities. To provide for interaction with a user, the invention can be implemented on a computer system having a display device such as a monitor or LCD screen for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer system. The computer system can be programmed to provide a graphical or text user interface through which computer programs interact with users.

A computer may include a processor, memory coupled to the processor, a hard drive controller, a video controller and an input/output controller coupled to the processor by a processor bus. The hard drive controller is coupled to a hard disk drive suitable for storing executable computer programs, including programs embodying the present technique. The I/O controller is coupled by means of an I/O bus to an I/O interface. The I/O interface receives and transmits in analogue or digital form over at least one communication link. Such a communication link may be a serial link, a parallel link, local area network, or wireless link (e.g. an RF communication link). A display is coupled to an interface, which is coupled to an I/O bus. A keyboard and pointing device are also coupled to the I/O bus. Alternatively, separate buses may be used for the keyboard pointing device and I/O interface.

Claims

1. A computer-implemented method for editing an electronic document based on user input, the document being displayed in a web browser, the docu- ment comprising characters coded in a document description language, the method comprising the steps of: converting at least one character of the document into at least one element which is individually addressable in the document description language in the web browser; - addressing the at least one element of the document; processing the at least one addressed element on the basis of the user input.

2. The method of claim 1, further comprising: Capturing at least one event on the basis of the user input, and associating the at least one event with the at least one addressed element.

3. The method of claim 2, wherein the user input comprises at least one keyboard stroke operation, and processing the at least one addressed element is performed on the basis of the at least one associated event.

4. The method of claim 2, wherein the user input comprises at least one mouse operation, and addressing and processing the at least one element is performed based on the basis of the at least one mouse operation.

5. The method of claim 3, further comprising generating position information for the at least one addressed element.

6. The method of claim 5, wherein the at least one keyboard stroke operation comprises at least one text cursor positioning operation, and the position information is associated to the position of the text cursor.

7. The method of claim 6 wherein the position information is used to detect an adjacent character of the text cursor position in the electronic document.

8. The method of claim 7, wherein the text cursor is set to a new position based on the detected adjacent character.

9. The method of claim 2, wherein the at least one addressed element is memorized as one of at least one an object and at least one element marked by an attribute.

10. The method of claim 9, wherein the at least one memorized addressed element is used to identify a text selection in the document, and to visualize the text selection in the web browser.

11. The method of claim 10, wherein a formatting operation is applied to the identified text selection.

12. The method of claim of one of the preceding claims, wherein the document is a web document.

13. The method of claim of one of the preceding claims, further comprising a step of transforming the document into a document which is coded in a web document description language, the transforming step being executed prior to the converting step.

14. The method of claim 1 or 2, further comprising: displaying the document comprising the processed element in the browser.

15. The method of one of the preceding claims, further comprising: after processing the addressed element, converting each element back to the original character.

16. The method of one of the preceding claims, wherein the step of addressing comprises a mouse click in the browser.

17. The method of one of the preceding claims, wherein the step of addressing comprises a key stroke in the browser.

18. The method of one of the preceding claims, wherein the addressable element comprises at least one predefined tag which is invisible for the browser in the web document description language.

19. The method of claim of one of the preceding claims, wherein the step of converting a character into an element comprises wrapping around the character at least two predefined tags which are invisible for the browser, one of the predefined tags being placed before the character, and the other of the predefined tags being placed behind the character.

20. The method of one of the preceding claims, wherein each character which shall be processable is converted into a respective element which is individually addressable in the document description language.

21. The method of one of the preceding claims, wherein the step of converting comprises establishing, in the web document, an array structure which contains references to each element.

22. The method of one of the preceding claims, wherein the web document is located on a web server, and the operation is received from a remote client.

23. The method of one of the preceding claims, wherein the operation is received from the same system where the web document is located.

24. The method of one of the preceding claims, whereby the document is coded in one of HTML, and XHTML.