I am making a webpage that has different areas that can be clicked on to change the contents.
I want to set it up so that when you click on an area, an openWYSIWYG editor appears in the middle of the screen with the rest of the page greyed out.
I have achieved this except for the positioning of the editor. When you click on a section I have a div with 50% opacity cover the page and a textarea appear in the middle. But when I try to attach the editor to the textarea, it loses it's position and falls behind the div not in front of it like the textarea is.
Can anyone suggest a way of centring the openWYSIWYG editor?
You're looking for Modal positioning. Here's one solution:
http://jqueryui.com/demos/dialog/#modal-form
Basically, apply the Jquery Dialog to the div that holds your WYSIWYG. Don't forget a submit button.
Just a quick heads up--I went through quite a bit of headache dealing with WYSIWYG editors for client-facing sites a few months back. It seems that clicking the "paste from WORD" button was a very difficult task to figure out. Word-pasted code can wreak havoc on websites, overrunning text fields in the database. I gave it a try on their demo (which also doesn't support webkit based browsers) and the result wasn't pretty. The only two options I found to solve this were to sanitize code on the back end, or to use CKEditor. I chose the latter because it was so easy. Take a look at CK, it's a great piece of free code.
Related
While doing accessibility sanity checks, I like to ensure to provide appropriate guidance for developers to correct anything that is reported as problematic or incorrect.
In this case, their implementation of a tooltip was incorrect. So I set to use MDN's documentation (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Tooltip_Role) as a reference.
But before simply sharing that, I tested MDN's code example with VoiceOver myself, and I discovered something curious:
List elements (<ul> in MDN's example) are not actually read by the screen reader. I tested with VoiceOver on Chrome and Firefox, and they both read the tooltip content as expected.
Does anyone know if this is a Safari bug, or if there is anything to ensure to do in the markup to ensure the tooltip content is read?
Here is a link to test: https://htmlpreview.github.io/?https://github.com/jansensan/test-a11y-tooltip/blob/main/public/index.html
Here is the code: https://github.com/jansensan/test-a11y-tooltip/blob/main/public/index.html
Edit: To clarify, I currently tested this on macOS Ventura with Safari, Firefox, and Chrome. The issue of VoiceOver not reading the content happens on Safari (weirdly enough). It skips the list altogether (I added paragraphs , <p> before and after the list to see what it would read).
There are two different situations here.
Descriptions only need to be read as a flat string
According to ARIA’s Text Equivalent Computation, exposure of the referenced structure is not required:
The purpose of the computation is to create a perceivable label or description for alternative presentations, in the form of a flat string of space separated textual tokens.
So this concerns the text read when focus is on the input—provided the user activated announcement of descriptions in their settings.
Reading the tooltips content by moving reading cursor onto it
If the reading cursor is moved onto the tooltip widget itself, the whole contents must be read, including structure. It would be surprising if Safari didn’t do that. If it doesn’t, it’s a bug.
Tooltips must stay open on hover
Both tooltip examples have one issue, though: They fail WCAG Success Criterion 1.4.13 Content on Hover or Focus, because they close when trying to move the mouse pointer on them.
Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
It’s a reflex of mouse users to hover content they are reading, independent of screen reader use.
I want to replicate Badoo's interests screen. The highlighting of each element and then being able to see these highlighted elements being remembered and able to be seen on another section of the menu. I've tried before, but in a very inefficient way.
https://youtu.be/X6cwHeb-0lg
Thanks!
im not sure if its the right place to put my question, but i think maybe get an answer here.
the last few days thinking about a way to make μυ work easier.
What I want is to write by hand and convert into text on the computer.
namely when I am on a page with multiple text forms like this im writing now,
when i choose a text form with a pen (like wacom graphic tablet) write on a surface and the automaticaly when i stop or pressing a button the text turn into text in the form.
my title say about wacom because i found bamboo scribe.. if someone uses this please explain me whats can do and if can work for me.
i test myscript. with fullscreen tool wich you can write everywhere on the screen is easiest but when you finish you have to press a button on the program to insert the text in the selected area.
so my question is there any way to press that button with the button placed on stylus pen?
i saw that you can set functions when a button clicked on the wacom tablet or on pen.
i have not bought yet anything because im searching if is out there anything could do what i want better. something made for that particular job
Thanks and sorry for my bad english..
I'm currently trying to embed a mailchimp sign up form using the HTML widget from impress pages, and at first, it seems to work perfectly fine.
I drag the block onto the screen, a popup comes up, then I paste the form code into it, and then voila! A pretty looking, rendered form appears. I then go ahead and press publish... and bam! My HTML widget is gone, and all that's left is an empty block within the layout asking me to click to add text!
I have no idea what's going on here, does anyone have any ideas? I'm using a custom theme, and I'm wondering if the workaround is to hard-code a widget for my client and just use that (although it looks like it'll be a big drain on my time)
If you get "Forbidden" as a response after pressing save, you should have a look at the answer here impresspages html widget not saving
I'm converting a Sharepoint 2007 installation to Sharepoint 2010. In 2010 each Web Part has an arrow in right side of the menu bar that only displays on mouse hover. How can I make that arrow always display? I've tried adding this to my custom CSS:
.ms-WPHeaderMenuImg{
visibility:visible !important;
}
The visibility set by corev4.css is hidden, but when I change it to visible in my CSS I still only see the image on mouse hover. Is there some JavaScript that is controlling this action? If so, where is it and can I override it? If not, how is this arrow showing and hiding?
You should check your priority of CSS imports and make sure your custom CSS is actually being applied because the code you have is correct. I was able to verify that on a standard page, adding a webpart did not show the drop-down arrow. When I then added in your code (and actually I didn't need the !important) then the arrows were shown by default. There was no JavaScript getting in the way, it was all controlled by CSS. So the problem may be somewhere else in your code.
One thing to be aware of is that there are two ways to display webparts: with the checkbox to the right of the arrow and without. That means that the arrows will not line up vertically on the page if you have them visible by default. This may be why Microsoft chose to hide them (although it also looks cleaner in the 2010 way).