I tried to make something like in this example: http://jsfiddle.net/WM583/20/ on Windows RT with IE10.
The problem is, that the touched element always gets selected on touch, which looks bad. I tried:
-ms-touch-select:none;
-ms-user-select:none;
user-select:none;
But it still gets selected. Does anybody know how to prevent the selection?
Try the following
Special meta tag
<meta name="msapplication-tap-highlight" content="no" />
and also the following style
a:active{background-color:transparent !important;}
Related
I've got a strange probleme here.
If I have this line in the HEAD part
<meta name="viewport" content="width=1200,initial-scale=2,minimum-scale=2">
touching the lines which are not links in the following example causes one of the links to get activated:
<ul>
<li>example</li>
<li>test</li>
<li>Text in between</li>
<li>Even more text in between</li>
<li>something</li>
<li>other</li>
</ul>
This seems to happen only with that line in the HEAD part. Everything is okay with Chrome and Android Browser.
Is there any way to solve this?
Edit:
It gets even worse if I make the line-height small, for example this way:
li { font-family:Arial; font-weight:bold; font-size:12px; line-height:12px;}
Now whether I use that META element or not, it is almost impossible to tap the texts in between without activating one of the links. Again only in Firefox mobile browser.
I think I've found a solution, however, I don't like it very much.
Adding an "onclick" attribute (whether empty or not) to each unlinked element makes it touchable in Firefox browser.
This can be achieved through a small JavaScript loop.
Better solutions are appreciated!
Ok i have a telerik:RadRotator on my page that loads a few images from the db, the rotator displays correctly in both FireFox and Chrome but when i open it in IE9 the rotator div is placed on the page but the rotator itself doesn't display(render).
<telerik:RadRotator ID="RadRotator1" runat="server" Width="791px" Height="215px"
ItemHeight="215px" ItemWidth="791px" OnItemDataBound="RadRotator1_ItemDataBound"
RotatorType="AutomaticAdvance" FrameDuration="10000" ScrollDuration="3000" CssClass="ImageRotator"
ScrollDirection="Right" PauseOnMouseOver="false">
<ItemTemplate>
<asp:HyperLink ID="hypImage" runat="server">
<asp:Image ID="imgScroller" runat="server" Width="791" Height="215" /></asp:HyperLink>
</ItemTemplate>
Any ideas as to what is happening here? I have tried to remove the styles applied and nothing.
Such problems are often related to an incorrectly formatted HTML that is not ignored by IE, especially older versions of the browser. The only issue that I found in your code was the unclosed RadRotator control tag, although most probably you have missed it by accident. Since the code from your sample appears to be valid, it is possible that an erroneous content is inserted from the data source. Please verify that the content in the datasource is entered correctly and that the data, populating the items of the rotator, is properly escaped before it is used. You can also check if the RadRotator's items are rendered properly by examining the content of the li elements in the HTML representation of the control on the source of your page.
Ok after much fuss I found that the scroller itself was wrapped in a hyperlink. After removing the hyperlink everything works 100%
If you have an element following another element that has float:left and turn on contenteditable in IE8, the following element will be precedet by an empty line in IE8 if you turn contentEditable="true".
An example:
<img src="foo.jpg" style="float:left">
<p>Some random text</p>
in IE8 this will be rendered like this:
See the line before "Some random text"?
This is especially annoying if you use a wysiwyg-editor because this affects some of its functionality. Also, this creates markup you don#t want. In CKEditor, you can see that the dom-path of that line is in the body, not inside any element.
I reported that problem to Microsoft some time ago and they didn't want to fix it: https://connect.microsoft.com/IE/feedback/details/576042/floated-elements-in-contenteditable-can-generate-an-empty-line
The last time that I checked with IE10 pp2 still had the problem.
Manually setting the css of paragraph elements with:
p {margin-top:0;margin-bottom:0}
should resolve this issue.
I have a strange result happening when loading a Partial View using jQuery Ajax into the DOM, but only when viewing the result using IE8.
The Partial View in question (for example purposes only) looks like this;
<aside>Example test</aside>
When the result comes back from the Ajax call it appears to look exactly as above. However when viewing the DOM using the developer tools in IE8 the result looks like this;
<aisde/>
Example test
</aside/>
As a result the element is not recognised and the text does not sit within it. Also the style sheet class for 'aside' is not being applied. This only happens in IE8 as far as I can see.
Any one got any suggestions, other than do not use custom tags?
Thanks in advance
You need to make sure the DOM recognizes HTML5 elements. Essentially you will have to do:
document.createElement('aisde');
Have a look at this link. Without creating the element older IE browsers will not see or style the elements.
The common practice around these issues is to load a html5 fix javascript file within a conditional comment block. The script does a createElement on all new html5 node types.
<!--[if lte IE 8]>
<script src="html5.js" type="text/javascript"></script>
<![endif]-->
I recently have found a strange occurrence in IE8 & FF.
The designers where using js to dynamically create some span tags for layout (they were placing rounded corner graphics on some tabs). Now the xhtml, in js, looked like this: <span class=”leftcorner” /><span class=”rightcorner” /> and worked perfectly!
As we all know dynamically rendering elements in js can be quite processor intensive so I moved the elements from js into the page source, exactly as above.
... and it didn’t work... not only didn’t it work, it crashes IE8.The fix was simple, put the close span in ie: <span class=”leftcorner”></span>
I am a bit confused by this.
Firstly as far as I am aware <span class=”leftcorner” /> is perfectly valid XHTML!
Secondly it works dynamically, but not in XHTML?!?!?
Can anyone shed any light on this or is it simply another odd occurrence of browsers?
The major browsers only support a small subset of self-closing tags. (See this answer for a complete list.)
Depending on how you were creating the elements in JS, the JavaScript engine probably created a valid element to place in the DOM.
I had similar problem with a tags in IE.
The problem was my links looked like that (it was an icon set with the css, so I didn't need the text in it:
<a href="link" class="icon edit" />
Unfortunately in IE these links were not displayed at all. They have to be in
format (leaving empty text didn't work as well so I put there). So what I did is I add an few extra JS lines to fix it as I didn't want to change all my HTML just for this browser (ps. I'm using jQuery for my JS).
if ($.browser.msie) {
$('a.icon').html(' ');
}
IE in particular does not support XHTML. That is, it will never apply proper XML parsing rules to a document - it will treat it as HTML even with proper DOCTYPE and all. XHTML is not always valid SGML, however. In some cases (such as <br/>) IE can figure it out because it's prepared to parse tagsoup, and not just valid SGML. However, in other cases, the same "tagsoup" behavior means that it won't treat /> as self-closing tag terminator.
In general, my advice is to just use HTML 4.01 Strict. That way you know exactly what to expect. And there's little point in feeding XHTML to browsers when they're treating it as HTML anyway...
See I think that one of the answers to Is writing self closing tags for elements not traditionally empty bad practice? will answer your question.
XHTML is only XHTML if it is served as application/xhtml+xml — otherwise, at least as far as browsers are concerned, it is HTML and treated as tag soup.
As a result, <span /> means "A span start tag" and not "A complete span element". (Technically it should mean "A span start tag and a greater than sign", but that is another story).
The XHTML spec tells you what you need to do to get your XHTML to parse as HTML.
One of the rules is "For non-empty elements, end tags are required". The list of elements includes a quick reference to which are empty and which are not.