dijit form select does not behave like HTML SELECT - javascript

I am using dijit.form.Select as a replacement for the HTML SELECT.
I am unable to get it to allow me to select an item purely by typing as you can with the HTML version. Ie, if you have a list of US states you can hit C several times to select Conneticut. What am I missing? TIA
And yet, it works on the web page below....
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test%5FSelect.html

When designing a select element that is visually consistent with a UI theme, CSS is often not powerful enough to completely control the look of select element, as some browsers treat CSS stylings on a select element differently. So the next best thing for many is to develop a faux-select with javascript so that way you have a better looking select element.
What you're left with is something that looks like a select element, but isn't, and the real select is hidden nearby, typically.
That means that there is a good possibility that when the developer was making that javascript version of the select element, they didn't do their diligence to at least program the minimum features that come native with the HTML version. (after all, it would be a lot of work to do string searching and sorting on a keyup event... and i'm not surprised they didn't do it)
to add insult to injury, sometimes the plugin actually allows for the change event on the native select to still be focused beneath the surface, which is why your typing works sometimes.

A chap named Bob Tarling has solved my problem. Much obliged Bob!!
See this link for his solution http://dojo-toolkit.33424.n3.nabble.com/Sharing-a-solution-for-type-ahead-in-Select-and-help-request-to-adapt-tt3995899.html#none

Related

Word ribbon customization of native Office commands

I'm trying to figure out if it's possible to customize Ribbon in Word programatically using Word JavaScript API. I went through the documentation and couldn't figure it out. I'm also curious if it's even possible right now.
What I'd like to achieve is to disable one of the items within Revision Tab. There's a property on the Office object called Office.ribon, which provides requestUpdate(input) method, which should enable this kind of functionality. Although it looks like the RibbonApi is not fully supported yet in Word as stated in the documentation. https://learn.microsoft.com/en-us/office/dev/add-ins/reference/requirement-sets/ribbon-api-requirement-sets
Is there any alternative how to achieve this goal? It might be possible to do it in manifest.xml, but I'm not sure how to get the specific ID of that item. Only IDs of those top-level Tabs are documented, but not their buttons, dropdowns, etc. It also looks like it's only possible to customize only my own custom items, where I specify the ID by myself. Is it also possible to edit a state of those native Office components, like disabling a button within a Tab?
It seems like a basic operation which could already be a part of the API. Can anybody confirm that it's really impossible to do it so far or is there some kind of a workaround at least?
Thank you.
There is currently no way to programmatically change the ribbon in Word. We are working on enhanced ribbon customization, but I would not expect them to be available in Word before mid-2021 and they may not include the option of disabling a built-in ribbon button.

Read Only equivalents for other inputs in html/JS

Background
I have a basic CRUD form/webapp. It happens to be react/redux but for our purposes it doesn't matter much. I'm pretty sure this is an HTML question.
The form itself represents a 'legal document' a bit, and multiple users log in to view/edit it at once. (think kinda google docs ish)
Some users can only view, some can edit.
The Problem
I want my edit users to be able to use the form elements (input/select etc) to modify the data, and my view users to see that same data as similarly as possible.
I want my view users to be able to copy and paste from the screen.
The disabled and readOnly flags won't quite work.
Failed Solutions
Disabled: With a little CSS magic is looks perfect, and the view users don't get onclick reactions they shouldn't. BUT you can't copy and paste the text. This is the current state of the app.
ReadOnly: Isn't supported by many of the inputs I have (select, radio, etc) although it's pretty much perfect for text and texarea.
The Question
Is there a reasonable or elegant way to achieve behaviour like ReadOnly but across all HTML elements?
Clarifications
Since the current view of the page is exactly what I want my view users to see (it's made to look like a paper form a little) If I chose to use 'view mode' spans for my components or a 'view page' mode I would end up having a to make them look as much like my current inputs as possible. It feels weird/bad to try and make a precise recreation of what I have out of spans and divs instead of making what I have behave correctly. Still... it's the backup plan.
We are using all kinds of inputs. Selects and dates and checkboxes oh my. Text and Texarea are well behaved, but the rest get less well behaved.
Readonly propperty is only supported by input and textarea, check caniuse.
As it has been said in a comment, replace input elements by others that don't allow insert data and re-style the elements to look similar if that's what you want.

Making an editable options box in HTML (Possible Javascript)

I want to create a drop down menu (like an <options> tag) in an HTML form. The issue is that I also want the user to be able to not only select from a list of options, but also type in their own if they want. So it would almost be like there was a text field that was automatically filled when you selected something from the drop down box, but you could still edit it.
This is the sort of thing I mean, only its a desktop app on windows (notice how the text can be edited):
I'm pretty flexible about exactly how it looks. If there is another, easy to implement, solution where the user can easy scroll/see a list of options or add in their own that doesn't look like what I described, I'm open to the idea.
Most of the drop down auto type scripts out there will let you type into the input box text that doesn't have to match one of the options in the options list. Just when you go to submit the form be sure to check to see if there is a selectedValue in the drop down and if not grab the drop down's text instead. How to do this will vary on what script you are using. As to what type ahead drop down script to use there are plenty out there, here is an ancient one that works pretty well but there are lot's of others.
http://trappedinhoth.blogspot.com/2008/07/jquery-autocomplete-example.html
HTML 5 even supports an autocomplete drop down
http://trappedinhoth.blogspot.com/2013/03/html-5-datalist-key-value-work-around.html
I hope that points you in the right direction.

Accessible javascript alternatives to select elements

I am developing some javascript code that will replace a standard select element with a javascript controlled dropdown menu which will redirect users to a particular page. The standard select element must work when JS is disabled
An example of what I want to achieve is here: www.play.com
What I have noticed with this site is that they simply position the select element behind the javascript alternative. This means that both controls are available to screen readers and keyboard users.
Does anyone have any experience of setting such functionality up and have any suggestions for the best methods to ensure accessibility?
Plain links would be your starting setup, as they work to take users to new pages without any additional scripting required.
You can put them in a container ul, and then use javascript in a 'progressive enhancement' way to turn the list into a dropdown (by re-writing the html) for the people who've got it turned on. This way, a user without javascript turned on will have no problems, and the majority of users will see your drop-down menu.
Even better, don't use a select menu for navigation. It's not really semantically correct, and requires more work to make it operable and robust.
Try something like the Suckerfish drop-down menus which are based on nested lists: http://www.htmldog.com/articles/suckerfish/ or if you want a bit of jQuery fun: http://users.tpg.com.au/j_birch/plugins/superfish/#sample1

Make javascript mandatory in web application?

I am building a web application that will have a fair bit of forms. The html forms are generated using php.
One of the things I came across is this:
I have a drop down box for the user to select his country. Once he selects the country, a call is made to the server to fetch a list of states within that country and populate it in a drop down box.
Initially, I thought I could provide 2 options:
An enhanced jquery version where ajax is used to fetch the states and the populate it in a drop down.
Where javascript is not availiable, the whole page is submitted to the server and then rerendered with the new states in the drop down.
However, onChange() requires javascript. So if someone where to visit the form without javascript enabled, there's no way we can deal with the second option, since javascript is required to submit a form using onChange().
What are some ways to deal with this? My only solution at the moment is to just make javascript mandatory. Users without javascript enabled will see a message saying that the page will not work properly.
Some sites:
Hotmail.com - Refuses to show anything except a "javascript is required message"
Facebook.com - Tells us we should use the mobile version of the site.
Google Maps - Does not work. No message to say javascript is required.
Gmail - Falls back to basic html.
Google account - Does not work. No message to say javascript is required.
Is it acceptable to require users to have javascript enabled at the current state of the web (august 2011)?
Just came across this possible solution:
http://cita.disability.uiuc.edu/html-best-practices/auto/onchange.php
I could perhaps add a button which the user can use to select their country. This should allow us to reload and render the form with the states drop down without any javascript.
You can provide a drop-down of states and tell the user to leave it blank if not applicable. If JavaScript is enabled, it can remove the drop-down until a country where it is applicable is selected.
No, it is not acceptable to require JavaScript; many security-conscious users use NoScript, for example, and would prefer not to turn it off.
By default you should load all possible values into the second dropdown, then clear them out on page load with Javascript. That way people without Javascript enabled can still choose the correct option.
I'm guaranteed to take flak for this, but whether you support no-JS or not should be your call. If you think your userbase is likely to have a sizeable portion of people who disable JS, then you should give them a site that works, but not optimally. If you think most of them will be running with "normal" (air quotes are important there) browsers, then you may consider dropping support for no-JS users.
I am NOT a professional developer, so take my input accordingly. Here are my observations:
I support a website for a wedding cake vendor. Upon observing the competition, all the more appealing sites are embellished (tastefully) with slideshows, dropdowns, animations, interactive form validation, etc.
When scouting for methods to incorporate these features into our site, I found that mostly every classy method was based in javascript.
Figuring it was better to present ourselves as the classy act we are (humble smile), I have decided to require users to have javascript enabled. We've been up for 7 years, and I have not received any complaints. All work on mobile devices.
A compromise option is to start with your State drop-down populated with the states of whatever country your business is in, e.g., all US states, with an extra option (preferably at the top of the list) that says "Other, non-[yourcountrynamehere]". Next to the State drop-down have a text input where the user can type the name of their state if it's not in the list. If JavaScript is enabled then on document-ready you can hide the text input and go with your Ajax solution. Without JavaScript the user has a fully functional page that doesn't even need a reload.
What I ended up doing is to add a button beside the drop down that says "select country". Users without javascript will see this button. Upon clicking it, the page will reload with the list of states rendered.
For users without javascript, this button is hidden, and selecting a country will automatically render a new drop down containing the relevant states.

Categories

Resources