how to set max character limit for textarea in zend like 300 characters
I don't think there is an easy way. If you assume HTML5 capabilities of the displaying browser you can use the inherited setAttrib method of the textarea to set the maxlength attribute. If you'd like to be more compatible you'll have to stick to a javascript solution. Both approaches are client side restrictions! You should always check the length when the form has been submitted.
Related
I created a plugin for Joomla which uses Sweetalert2 and it generally works fine.
However, surprisingly, when the size of the html message I use is too long, the box does not popup and the content gets instead written to the document body itself...
Is there a size limit for the html parameter or could this somewhat be caused by Joomla?
Thx
Philippe
I am using TinyMCE as editor on my Joomla website and I have a problem with the maximum font size.
When I insert some text into the TinyMCE editor I can change the font size but the maximum size seems to be: t (36pt), why?
I need to insert larger text into my pages. What can I do to fix?
Tnx
Andrea
There are many ways you could tackle this, but I would try one of these first:
You can change the dropdown font options using the theme_advanced_font_sizes option, in general, it is something like this:
tinyMCE.init({
...
theme_advanced_font_sizes : "10px,12px,14px,16px,24px"
});
For more info on this, look here.
Now, since you're using Joomla, you can try to pass your parameters in an array to the display editor call, like is explained in the official joomla documentation (keep in mind that you need to check this is one of the adjustable parameters) or you could also try to change the setting for the editor you're interested in by adding some javascript to a specific view, but I'm not sure it'll work. It should be something like: tinymce.get('editor_id').settings.theme_advanced_font_sizes="10px,12px,14px,16px,24px";.
Depending on what you want to do, you could also try using tinyMce indepently or duplicating the plugin with your own tweaks, so that it doesn't get overwritten when you update your site.
Don't do anything at all. You can control the appearance of any block by inserting css code directly, just use the code view.
I am using the kendo editor. If I write any html data like : <img src=x onerror=alert(0) > as an input. The script is getting executed. Means the kendo editor is not secure. How I can encode the value on client side ?
Thanks in advance.
I don't think the problem here is so much that the Kendo editor is insecure, more that the javascript fragment has made it onto the page in the first place.
On initialization the Kendo editor merely copies the input value verbatim and uses it within the iFrame that is contained within the editor, hence the script executes.
Typically you would encode/sanitize user content server-side before it's displayed. It's your website that generates the HTML page so you have full control over the output and need to ensure that a potentially dangerous value doesn't get added to the input's value in the first place.
It might be worth looking into Microsoft's AntiXSS offering.
I have a site developed in C#.net and VS2010. It is is localized and works well overall. However, some of the localization strings don't look the best.
For example, I have a message at the top of the login page
Currently it appears like this:
Your session has expired. Please login to
continue.
I would like it to appear like this:
Your session has expired.
Please login to continue.
I can't change the size of the containing div because the width could be different for each language.
I am looking for a way to put layout capabilities in the localization file. The simplest approach (on the surface) is to put new line characters in the string. However, \n, \r\n, and <br/> all appear in the string because it is rendered with " around the string.
Is there another approach that will work? Is this a bad idea? How else can we compensate for length differences accross the many languages?
The best approach in this case is to use HTML formatting in your string (both in English and in your translation) and where necessary adjust the translation.
There is no reason why you could not include <br /> in your string and have it rendered as intended. I don't know if you are using WebForms or ASP.NET MVC, but in the case of MVC you can avoid the default behaviour (automatic HTML encoding of your string) by using the Html.Raw helper, for example instead of this:
<div class='whatever'>#Resources.MyString</div>
Do this:
<div class='whatever'>#Html.Raw(Resources.MyString)</div>
I was wondering if anyone knew if it were possible to override the default behaviour of browsers that support the new HTML input types such as type="email" and type="date"?
I appreciate that I could test if a browser supports an input type and provide a fallback for those browsers that don't, but what I want to know is is there any way to prevent that default behaviour from happening in browsers that do support it?
For instance, if in Opera I want to use the date input type, but I don't want Opera to display the native datepicker (i.e. I want to replace it with my own custom one) is that possible? Are there any DOM events triggered like onDatePickerShow that one can hook into?
I don't believe that this is possible, but if anyone knows for sure one way or the other I would love to hear from you.
input type=date without datepicker is almost the same as input type=text. If you want to keep validation, then you might use pattern attribute instead.
There's no way to customize look'n'feel of the standard date picker. There are no events for the picker. Spec doesn't define any UI for pickers. Consider how wildly different pickers can be – compare one you get on desktop with picker on the iPhone.
In the future CSS might get pseudo-classes for some customizations of date picker (and file picker), but currently it's all-or-nothing.
Disable validation of HTML5 form elements
If you add a novalidate attribute, then for example you can enter an email without an #
This only seems to disable the client side HTML5 validation.