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.
Related
Lets say we have a simple input tag:
<input type="text" />
In the moment that its type attribute is changed to date, the input element modify its behaviour by adding a native date picker field which varies from browser to browser.
My question is: how this event of adding a native date picker works?
Is there a way to get access to this object using Javascript?
No.
HTMLInputElements have internal state dictated by the type attribute. Whereas other elements are descendants of other prototypes( or classes ) there is no way to adjust the prototype of an HTMLInputElement based on its type before creation, though you may choose to extend or adjust that prototype yourself to include additional, type-specific functionality and create an input element based on that prototype/class and not its parent, HTMLInputElement
Furthermore, this isn't unusual. You aren't able to adjust anything that utilizes native, internal functionality in the host browser. A.e. things like alert, prompt, and file dialogs are completely out of control for the developer.
I'm part of a team that develops a custom element library for a big customer (according to custom element spec v1). We've developed like 30 components so far, half of those being autonomous custom elements, the other half being customized built-ins.
We're currently in the phase of refactoring and unifying the API of those components. Almost all of these components have custom attributes / properties.
With standard HTML elements the convention is to use data-attributes which are reflected to and from the dataset of the element.
I'm aware of the fact that autonomous custom elements allow for free attribute / property naming as long as the name doesn't conflict with what HTMLElement already has.
The idea behind data- attributes as I understand is to make sure that no libary will begin implementing a custom attribute which might conflict with future versions of the HTML standard.
The same, though, should be valid for property names. Imagine the HTML standard would get a new universal attribute, let's abstractly call it attr. Of course that would also reflect to a same-name property on the HTMLElement prototype.
My questions are:
What is the suggested approach to evade future conflicts here? Is it to always only use data--attributes for custom attribute implementations, and thus, avoid the conflict by working with the dataset instead of properties directly attached to the element?
If so, how would you then implement "boolean" data-attributes (where the attribute value doesn't matter, the state is implemented via absence/presence of that attribute)?
Is it possible to define own getters and setters for properties in the dataset of an element?
Please ask for clarification if anything is unclear. I tried to make the question as concise as possible.
I don't worry about future-proofing my custom element attributes or properties against what may become a predefined attribute or property of HTMLElement. If the spec changes, then I will deal with it then. But to try to guess everything that might be used in the future is not possible nor worth my time.
I avoid using data- attributes for custom elements. The dataset values are only strings and do not convert well. For example if I do this:
el.dataset.dog = {woof:10};
then my tag get's an attribute like this: data-dog="[object Object]" and this console.log(el.dataset.dog) displays "[object Object]". That defeats the purpose of many properties that may need to deal with objects.
I only create attributes for things that must be attributes. If I must allow the HTML to define default values or if I need to create a CSS attribute selector then I will create an attribute. But only under these two conditions.
I create properties (getter/setter) or functions for everything I need. It is easier to pass in data of any format into a property or function then it is to convert it into a string to pass in through an attribute.
I have even taken over one or more of the existing HTMLElement properties and attributes. This is rare, but sometimes I need to do something with the value or I just don't want the default operation to happen. Again, this is rare.
I am trying to disable user text input in a text field, and am using the readonly="true" attribute on the input itself.
However, I don't want it too look different then a default input field. I'm am trying to write a solution that will not make me go in and write CSS for it, as browsers may change their styling and make this miserable.
Is there any way to just remove the browsers readonly style?
Here's a screenshot I'm talking about. The one on the right is readonly, but I want it to look the same as the one on the left.
Browser styles are by definition browser-specific, so any solution would be browser-specific. You would need to study the browser defaults (from documentation or via experimentation) and to serve different styles to different browsers. A lot of work, and I don’t quite see what the potential benefit might be. It would in general be bad for usability to remove the distinction between normal and disabled fields.
You can set the style explicitly to be the same for normal and disabled fields, but then you won’t get browser defaults.
I want to add telerik RadNumericTextBox to innerHTML using javascript or jquery. How can i achieve this?
If you mean the RadNumericTextBox specified here, then you are looking for a server solution that has nothing to do with javascript.
innerHTML is a property of a DOM element that can't exist until firstly a DOM and secondly an element within it exists. So if you are looking for a server-side solution it has nothing to do with innerHTML or javascript (at least in regard to adding suitable markup at the server in ASP.NET).
If you are looking for equivalent functionality to be applied on the client, you can validate input at some convenient time (that is, convenient for the user) which is likely when a form is posted or when the user leaves the field in question (which will typically dispatch a blur event and perhaps a change event if the value changed).
You can also use the HTML5 input#type=number, however that will only work in browsers that support it (a good percentage don't).
A listener that validates that the value of a form control (probably an input in this case) is quite simple to write and attach to the element if that is what you want. In any case, innerHTML is unlikely to be involved in a suitable client-side solution.
What are you actually trying to do?
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");