I'm using http://code.google.com/p/flex-iframe/ for showing html in an flex application. To set this up I need to set vmode=opaque. But doing this messes with keyboardinput (at least a swedish charlayout) in Firefox. For example a press on the array key resolves in two arrow chars/steps. If I remove vmode=opaque it works again.
There have historically been lots of issues with setting wmode to opaque. I've had similar issues in the past and had to resort to removing this wmode setting. However, if you're so inclined you could hackishly detect the presence of two keyboard input events within a relatively short time period and suppress one of them. It's not a really elegant solution but if you cannot get rid of wmode, it might be a viable workaround until the bug is fixed by adobe.
Related
How to force browsers to scroll pages smoothly to the focused element while navigating with 'tab' key?
Note: I've looked this up but haven't found the solution yet.
As this as marked as accessibility the simple answer is don't.
You may not like that the page jumps about but you have to consider the opposite side effect of changing scrolling behaviour.
What if your user is partially sighted and has the zoom set to 300% on your page. A tabble item such as a link may be many many pixels off screen when zoom levels are so high, having to wait for it to scroll into view will only be frustrating.
Additionally for WCAG 2.1 (applies to level AA I think) guidelines you should avoid animation of any kind or have the option for users to switch it off, you are adding a lot of extra work in needing a setting to remove this scrolling directly within your site. This is because certain cognitive impairments make animations far more jarring and distracting than a simple jump and also that is expected behaviour - changing expected behaviour can also lead to disorientation for people with cognitive impairements.
Another thing to consider is that to achieve this you would have to intercept the tab key - this is a terrible idea as screen readers rely heavily on this key in different scenarios (tabbing in a list of items tabs down to the next item in some screen readers, intercepting the tab key would result in unexpected behaviour.)
Don't worry about it, disabled and able bodied users will thank you for leaving the tab key well alone (as I hate when people slow my scroll speed)
If you did want to do this you would intercept the keypress of the tab key and manually cycle to the next tabbable element - but please don't do it!!
You would also (for accessibility and WCAG 2.1) have to then add an option to remove this functionality within the site accessibility settings (if you have them).
Smooth scrolling is a browser setting (chrome > about:flags, firefox > about:preferences, ie > tools>options>advanced). You might be able to change the browser's setting programmatically, but that would seem like a security risk that browsers would block. It's a personal setting. Some users like it and some don't. If you forced it upon a user that didn't like it, that would not be nice.
I am having an issue with a specific mac that is not displaying a certain website I have built correctly. Every other mac and pc I have tested displays the website correctly but this one specific mac in all browsers on it is displaying incorrectly the issue I am getting is inline block elements are not next to each other, I have all the 'hacks' in place and like mentioned this displays correctly on every other computer.
This question here is the exact same issue but it doesnt seem to have been resolved.
https://discussions.apple.com/thread/6650689?start=0&tstart=0
I know I could try floats but I would rather find the route of this cause, does anyone know of any reason this might be happening?
If browser renderings vary only on a single or a few machines, fonts are a possible culprit. Make sure all computers use the same fonts to render your page, actually even that the same version of the font is used.
A lot of fonts get slightly modified over time, often the kerning (space between two characters) or the hinting (how the curves that describe fonts should be mapped to pixels on the screen) might change, resulting in very minor differences in the width some text consumes when being displayed.
If indeed the font version is the culprit: Remember that visitors of your page might also have this "bad" version of the font. So it is advisable to try to improve your HTML layout.
I've often observed that leaving a few percentages empty helps to deal with such font issues. For example: having a div (width=100%) that contains two elements in each "row", the first one a label of about 1/3rd the width, and the second one being some control, taking up the rest of the space. Having them defined with width:33% and width:67% often results in the case that the second part is laid out below the first part instead next to each other. Changing the widths to something like width:32% and width:65% often fixes this, as it allows for some rounding errors in the browsers when laying out the elements.
I wonder if its possible to use the browsers cursor as an image.
So for example that I could use somewhere on the page the resize image of the cursor.
I tried to find some answer to this, all I could find is how to use an image as a cursor.
And interesting enough,
Microsoft uses images to show the cursors:
https://msdn.microsoft.com/en-us/library/aa358795.aspx
Mozilla also uses images:
https://developer.mozilla.org/en-US/docs/Web/CSS/cursor
Which makes sense, since one might have complete different set of cursors (maybe even a broken set - not having all variants) defined in the Operating System. And so it wouldn't show what they actually wanted to show. So my hopes are still up that there is some way.
I suppose what I want is not possible, but I thought lets ask.
Maybe its very simple and I am really overlooking something I hope.
It is simply not possible to use the image which is used by the browser.
Has anyone ever seen this before, Chrome is calculating my values, even in the body too specifically. Meaning the values are in the millionths if not billions decimals places:
Example:
width: 281.6477355957031px;
I do not have this problem with IE. I normally wouldn't care, but these fractional pixels are really screwing up an effort to add a sticky header to a common grid control we've developed to work with OData.
This issues seems to happen when just a body tag is on the form with no other lower level controls. I am baffled.
Does anyone know of a way to reset the entire html page or even better, just reset a particular element so that every element beneath it calculates using whole or near whole values?
thanks!
EDIT
Just to be clear, I have taken everything off the page except the main container, with no styles and Chrome is calculating this parent html tag, with a value of 1508.1817626953125px. This element has no styles attached
To answer my open question, the cause is Visual Studio 2012. Since I was using localhost to run my site, some plug-in or setting is set to force chrome that specifies dimensions much more specific than any normal human would want. Upon not using machine name instead of localhost the dimensions are back to normal. If i find the exact setting, i will report back later.
EDIT:
Upon further discovery, its not VS, its my browser zooming. At certain zooming in Chrome pixels in the development console are calculated to a sub pixel level. I imagine due to some inner division calculation. This throws off my calculations for allowing the a staic table header at different zoom levels. I will be forced to deal with CSS pixel rounding in my own calculation to handle these.
I am having problems finding the width of a string of text in a UITextField object. I know there are various methods documented to ostensibly do this, but they simply do not work. There is one and only one method that produces a correct value, but requires the use of the textField property of an mx.controls.Text object. If that textField is used, then getCharBoundaries works correctly, and you can just add up the returned widths from a series of calls to it to get the width of a string of text.
However, if you just call getCharBoundaries on a stand-alone TextField or UITextField (i.e. one that is not a property of MX:Text) then getCharBoundaries returns some entirely different value that is substantially less than if called on the textField property of an Mx:Text object. It is in fact about 25% smaller than the correct value, but that is not even consistent, because change the font size and the discrepancy seems to vary non-linearly. So what getCharBoundaries is actually returning in the case of a stand-alone UITextField, I have no idea.
But actually, call any other method for determining text width of a TextField (other than getCharBoundaries within an MX:Text object) , and you'll get the same erroneous value: TextField.getUITextFormat().measureHTMLText(...).width (or measureText), and TextField.getLineMetrics(...).width all return this same erroneous value. And you might say, "Well they're probably just returning the width from left most pixel in the text to righmost pixel", except as I said to begin with, in one instance getCharBoundaries is actually returning the total cell width of the text, which is what I want, (and then when called from a stand-alone Textfield some completely different value.)
But my problem first appeared when I tried to change an MX:Text object (within which I could call getCharBoundaries successfully) to a UITextField. So now neither getCharBoundaries or anything else works correctly for determining text width. (Note: I'm not actually displaying the UITextfield, but rather am using it for text processing purposes behind the scenes, as it is significantly faster than MX:Text. I set UITextField.htmlText to a value, then make a series of calls to getTextFormat, setTextFormat, and replaceText. And it all works as before with the Mx:Text object, except much faster. Only problem is there is now apparently no way to determine text width for a string of text, even though Adobe documents all these methods that are supposed to do that.
And so my question is, I get on google, and there is very little commentary on this, and no work around at all that I have seen documented anywhere. I did see one thread on actionscript.org from a couple of years ago, where someone else also said that all these width methods simply do not work. There was confirmation of this by someone, but no resolution provided. (Note: this poster noted that the error seemed to escalate with increasing font sizes and was not as noticeable at small font sizes, which I suppose may explain why it doesn't seemed to have been noticed.)
But I downloaded Flex 4 here a while ago, and the problem is still there. So just wondering if I am truly the only person who is cognizant of this, or has encountered it, or possibly someone point out what I'm missing. I guess the Flex Bug tracking system would be an option for me, but that would probably be a Black Hole.
So anyway, just wondering if anyone's encountered this or found a work around.
OK, I've solved my problem. I apologize for the rant against Adobe but then again I might not have solved this otherwise.
The problem was rather obscure and almost certainly not relevant to others, but here it is:
I was trying to find the text width of a prefix that contains some characters in a special nonstandard utility font I created with very nonstandard attributes. Mx:Text.textfield.getCharBoundaries had no problem with it, but every other width method did, evidently. Of course, Mx.Text.textField is not actually a TextField or a UITextField, but rather an IUITextField, meaning it just implements the interface. Evidently its implementation may have nothing in common with the implementation of TextField and UITextField which are both directly related.
As far as this nonstandard font, I had not had any problem with it in the past, so failed to identify it as the culprit. Its character widths are identical to another font's, so that solves my problem.
I have to provide an update here. The problem wasn't the font I was using, but rather that it was not a Windows System Font. measureText, measureHTMLText, etc. won't work unless a font is installed on a user's own system previously. It makes no difference if the font is embedded in the Flex Application, the end user has to already have that font installed on his own system for those width methods to work. MX:Text.textField.getCharBoundaries is the only one that doesn't care whether or not its a systemFont. (UITextField.getCharBoundaries also requires it to be a system font.)