I want to build a custom object in HTML which is focusable. How can I do that in general?
More specific about why I want that: I need some kind of editor component with much more power and control over it. I.e. no single character should be possible to be typed in directly. It is like a big tree of objects (imagine an AST or so) and your focus is on some of these objects. Each object has some properties, maybe a character sequence which can be edited and some subobjects. Now when you type, depending on where the focus is, it should manipulate those objects, i.e. add some new sub objects (at the place where the focus is), delete some objects or do some other manipulations. Also pasting should not be allowed directly, it should rather parse the current clipboard content and then do the specific manipulations. Copying some content should result in some sort of text representation in the clipboard.
I could go now and somehow recode something like a focus cursor myself but that has several disadvantages. Mostly that it ignores where the real focus is right now. And I'm not sure if it makes anything easier, if HTML may provide already something like this.
Edit: After I found some first useful information, some still open questions:
What is an easy way to draw some focus cursor? I.e. if some div has the focus right now and it contains some text, I want to draw a cursor.
How do I handle copy & paste? (See above for more details.)
Ah, I found somewhat useful information here. I guess there is anything explained I need to handle the focus in the way I want.
Simply use html inputs, and handle special keys with it.
If you add tabIndex attribute to html elements the focus can be stopped on it (i mean not just input and textarea). If you alternate these focusable objects with text inputs when its focused, you can easily build custom editor UI.
In ie window.clipboardData wraps the clipboard object (simple ex: http://lab.artlung.com/copy-to-clipboard-javascript/) in other browsers you can trigger copy/paste width document/Range.execCommand('Copy');
Simple Example:
Copy = textHolderElement.createTextRange();
Copy.execCommand("Copy");
Related
Is there any way to keep the current selection inside a Jodit-editor, when clicking outside of it? E.g. I'd like to have a button completely outside the editor (e.g. in a sidebar of the application) that can insert some elements in the editor window at the current position.
You can store the selection by using editor.selection.save() and it will be temporarily written in the markup. This can be restored using editor.selection.restore(). This mechanism would actually work for my use-case, but unfortunately, the 'helper-markup' is also removed/reset in the moment of the editor losing focus.
Also, I didn't find something like a 'selection'-event, that I could use to 'remember' the selection in my own state. Plus the selection. The set method from the selection doesn't seem to work, but I haven't dug into that yet.
I had the same problems and I have solved that a small trick.
As you know you can catch selection in the "onBlur" event and in there I added a special string for the check after losing focus.
for example "{}".
and then string replace with my want.
I'm getting this strange behaviour in a very specific set of inputs on one my applications. I create some inputs and I can see them as I created them on the Elements panel (google chrome), but the way the browser renders it is different.
Note how the input is renders with comma instead of a point, but the value attribute uses a point
When I get a referente to that element using the selector API, I get this:
A direct reference to the Dom Element will return 11,00. The tag has 11.00 and jQuery returns the 11,00. I've removed all js that interacts with this element (masks, events, etc) and the issue still happens.
I've been swearing at the DOM for a day and a half, but I know this is most probably an issue with my application. What bothers me the most is that the browser does not honor what I see in the elements panel.
This is the small piece of code that creates the element, stopped right before the tag is created. Note the variables values in the right panel:
Could someone give me a hint about what could be causing this difference in between element, view and attributes? If possible, I'd like to know what/how this is happening in depth.
Thank you in advance
I was wondering if it was possible to create a new kind of input, as opposed to the normal number, text, etc. For example, I am making a forest fire model for my internship, and one thing I am trying to add is wind. I was wondering if I could do something like <input type='wind'/> and define what that would look like and how it would behave. I could do it some other ways, but I also just wanted to know if it would be possible to do something like this.
Thanks
The list of available input types is here: http://www.w3.org/community/webed/wiki/HTML/Elements/input
The type attribute is enumerated (i.e. you can only use those values) with default of text.
However there is nothing stopping you from adding class="wind" or the like to the input and using JavaScript to alter the behavior of all such inputs.
In practice, nothing really prevents you from writing <input type='wind'/> in HTML and styling and scripting it, e.g. (using jQuery) $('input[type=wind]').click(handler). It won’t be valid HTML, but this just means it does no conform to specifications; browsers don’t care about that. They will treat the element as a normal text input box, because they do not recognize the attribute value and will therefore use the default type='text'. This means that the DOM node has text as the value of the type property, but its attributes array (well, array-like object) still has wind as the value for type
So it would be like using <input class='wind'>, as suggested by #ExplosionPills, just using a different attribute name, and with extra complications. Either way, the fallback (in situations where scripting is disabled) is an ordinary text input box.
If the fallback is not relevant (the page would not work at all without JavaScript), it would be simplest to use a span or div element with class and implement it the way you like. Then you would not have to deal with the default rendering and behavior of normal text input box; it can be a bit tricky to wipe them out in favor of your own rendering and functionality.
I have a requirement to disable selection on a web page for everything except input[type=text] elements.
This accepted answer to a similar question almost does the trick, but it doesn't disable selection for containers that contain input[type=text] elements. Therefore the user can still select by starting a drag operation from within one of these containers.
Is this even possible, i.e. is it possible to disable selection for a container element, while enabling it for child elements (specifically, child input=text elements).
#Pointy, "Why not just take out that first .not() call?"
Taking out the first .not call, will give:
$('body').not('input').disableSelection();
which, as pointed out in the linked question, will still disable everything on the page, including the input[type=text] elements.
#David Thomas, "Do you have a live demo ..."
I don't have a live demo, but it's fairly trivial. For example, a div with a bit of padding that contains an input[type=text] element. The result is:
With $('body').not('input').disableSelection(); selectiopn is disabled for all the page, including the input elements.
With $('body *').not(':has(input)').not('input').disableSelection(); selection is disabled for all elements that don't contain an input element. But it is possible to select the whole page by starting a drag operation from within a container that contains an input element.
Well, cinch up your suspenders and get ready for a really dirty hack.
Disclaimer:
I don't think this is a good way to do things. I simply wanted to tackle the challenge of getting the OP's desired functionality. If someone else can get this to work in a cleaner way, please post it.
After playing around with the disableSelection() function, it seemed that if a parent element had been disabled, all of its children would be unselectable as well (please correct me if I'm wrong). So, I decided that if you wanted everything to be unselectable except small parts, you could put all of your markup in one unselectable <div> and use absolute positioning to place selectable clones of your <input> tags (or any tag, really) on top of the unselectable ones. These clones would reside in a second <div> that was not disabled.
Here's an example of this idea: http://jsfiddle.net/pnCxE/2/.
Drawbacks:
Styling becomes a big headache. Any element that relies on a parent's style (i.e., position, size, colors, etc.) cannot be cloned since the clones reside in a separate place.
Forms become much harder to manage since (again) the clone isn't in the same place as the cloned element.
You have to deal with naming collisions since the clone will have the same ID as the cloned element. (It's doable; I just didn't want to code it since it would probably need specific attention by anyone that uses this idea)
So, while you can work around the selectable limitations, you might be better off just accepting the container selection. I would think long and hard before putting this code into a production environment.
I've found a solution that appears to do what I want, and would be interested in comments / improvements from jquery / javascript experts.
$(document).ready(function () {
$("body").disableSelection();
$("body").delegate('input[type=text],textarea', "focus", function () {
$("body").enableSelection();
});
$("body").delegate("input[type=text],textarea", "blur", function () {
$("body").disableSelection();
});
});
When a textbox (input[type=text] or textarea) has the focus, then dragging with the mouse only selects text within the textbox. Therefore it's "safe" to enable selection for the whole page while a textbox has focus (between focus and blur events).
There is a noticeable delay when tabbing between textboxes on IE8/9. It's not noticeable on Google Chrome, which I understand has a faster javascript engine. So I can live with the performance hit, especially since IE10 is going to have a faster javascript engine.
UPDATE
When using ASP.NET UpdatePanel, this needs to be modified to disable selection after each partial postback:
Sys.Application.add_load(function () {
$("body").disableSelection();
});
Try this, although it is same with what you're already using:
$('* :not(input)').disableSelection();
I don't get though why do you have to use entire body element and not narrow it down to text nodes (p, h[..], ul, ol etc.)
And I agree with #David Thomas - it would be easier to see a test page you're working on.
I want to create a little WYSIWYG editor.
The idea:
First I want to add the feature to write and change text. So I add an onClick and onKeyBoard Listener to my div container. When I click the div I set a varaible named "focused" to true. When an key event is fired I check if focused is true. In case focus is false nothing will happen else the new charater will be added on the cursor's position.
My questions:
Is this the right way? I tried to check how other editors handle the text input but I wasnt able to get it.
In case this is the right way - how can I simulate a blinking cursor. In a textarea the cursor will blink but who about a div container? The cursor will hide immideatly after clicking.
I'm assuming you're doing this for fun/practice. If you're doing this for professional reason then I HIGHLY recommend you don't reinvent the wheel and use something like Ckeditor, tinyMCE or YUI.
That being said; you need to look into event handling. Specifically, for your question about focusing, you can look here. The way you're describing (setting a variable to true/false) seems like it is going to just run into problems. If you use the standard events attribute (as opposed to setting a "focus" variable onclick) you should define functions to execute and then set them as an onfocus/onblur attribute for the element you're listening to.
That is if you aren't using a javacript library like mootools, jquery, extJS, etc. If you're using one of those they likely have their own way of handling events, so you should search their respective documentation for how to implement event handlers.
One more note; you really should be using a textarea over a div (unless I'm misunderstanding and you just want to do something when a user focuses on your div). If you're using javascript only to completely reinvent a texteditor from a div; then your web page will not function without javascript. If you keep the text area; users could still type information in and you still get the benefit of grabbing text contents for form submits but using divs means your web page will just be rendered useless without javascript.