I'm having trouble with a mobile website, where I don't have direct access to the source (my task was changing CSSÂ only).
I requested the developer to insert the viewport meta tag at the header
but Chrome Inspector shows it as a wrapper to everything below, creating a weird closing tag at the end of the body.
What might be causing this?
http://i.stack.imgur.com/QryBj.png
The spaces in the viewport meta tag are non-breaking spaces, so the tag is not being recognised correctly. Get the developer to fix the spaces in the tag.
Related
There are so many issues with contenteditable divs and deleting html and/or non content editable content inside editable divs.
Using an answer by the excellent Tim Down here: How to delete an HTML element inside a div with attribute contentEditable?
Using Tim's code, the entire text node gets deleted. I need this to work like any textarea would, deleting character by character and just making sure html elements can be backspaced as well.
I tried the following
else if(node){
var index = node.length-1;
if(index >= 0)
node.deleteData(index,1);
else
this.removeChild(node);
}
But this is obviously not going to work correctly. If I am at the end of the content, things work as expected. But if I place the cursor anywhere else, it's still deleting from the end.
I'm lost at this point, any help is very appreciated
http://jsfiddle.net/mstefanko/DvhGd/1/
After breaking down how google uses contenteditable divs in their google plus user tagging, I landed on a much more reasonable solution. Maybe it will help someone else out.
After adding 1 tag, you can already see a lot of differences in the html browser to browser.
In Google Chrome, a space is added with each tag. The button tag is used. And the chrome-only contenteditable="plaintext-only" is used.
When I backspace the space in chrome, a BR tag is then appended.
In Firefox the BR tag is added immediately with the first tag. No spaces are needed. And an input tag is used instead of the button tag.
The BR tag was the single greatest break-through I had while digging through this. Before adding this, there was a lot of quirky behavior with deleting tags, as well as focus issues.
In IE, more interesting changes were made. A span with contenteditable false is used for the tags here. No spaces or BR tags, but an empty text node.
With all of that, you don't have to copy google exactly.
The important parts:
If you're rendering HTML, do the following...
1. Chrome should use the button tag
2. Firefox/IE should use the input tag
For range/selection you generally want to treat things like tags as a single character. You can build this into your range/selection logic, but the behavior of the input/button tags is much more consistent, and way less code.
IE behaves better in IE7-8 using a span. Just from a UI standpoint. But if you don't care if your site is pretty in old versions of IE, the input has the correct behaviour in IE as well as firefox.
3. Chrome only, use the contenteditable="plaintext-only" attribute on your editable div.
Otherwise, a lot of weird issues happen not only when a user tries to paste rich-text, but also when deleting html elements sometimes the styles can get transferred to the div, I noted many strange issues with this.
4. If you need to set the caret position to the end of the div, set the end of the range before the BR.
for FireFox:
range.setEndBefore($(el).find('br')[0]);
I have an issue with Google Chrome: 19.0.1084.52 m when I have the Ask Toolbar installed
it breaks the website layout.
See print screen:
Is it usual behaviour that toolbars in Chrome would effect the website?
EDIT: I guess I should wrap everything inside a <div> and move the background-image from the <body> although is there a better option without adding this extra markup?
Website link
A Javascript snippet can disable ask toolbar in chrome. I hope this function spreads quickly!!
function removeAsk(){
if(document.getElementById("apn-null-toolbar") != null){
// mainMenu had a style change for its top positioning, returning it to normal
// perhaps a function can be made which iterates over every element ask has changed
document.getElementById("mainMenu").style.top = "-16px";
// Just remove the iframe and style elements
(elem=document.getElementById("apn-null-toolbar")).parentNode.removeChild(elem);
(elem=document.getElementById("apn-body-style")).parentNode.removeChild(elem);
}
}
Call this method after body onload
<body onload="removeAsk()">
There is no Chrome extensions API for creating a toolbar so mentioned extension must have created it via content script. What it means is that for each page you open, CSS and JavaScript files are injected by this extension to create a DOM element within the page acting as a toolbar. Problem with this solution is that using the content script it is possible to mess up website look or even the way it works.
I ran into this exact same issue with the Ask Toolbar. I basically took out my positioning attributes and top/left/right/bottom 's and replaced with margins. Margin uses less space and it comes out cleaner.
Although i do agree, it's kind of ridiculous to accommodate for a toolbar because the end-user could have anything installed that breaks and gives your layout bugs. Even Skype extensions will break a layout just changing the phone number.
So there's not much you can do, but use margins and keep CSS to a minimum. Just my 2 cents. and if you have to use CSS then stick with margins.
I've got myself multiple a tags floating on a page.
They have been styled in a unique way to center an image horizontally inside it, using a span and css. The a tag itself has fixed width and height.
I thought this was basic stuff, and my theme was causing the issue, but I've created a stripped down jsFiddle and I'm still getting the same problem when running the jsFiddle in IE 7.
The a tags are all click-able in every browser apart from IE7, why is this happening?
Can anyone explain? Thanks.
http://jsfiddle.net/motocomdigital/Qk9tu/6/ - Test click-able state in IE7, works fine everywhere else.
Don't worry about IE 6 - I'm not coding for this anymore.
On IE, a link element (<a></a>) with an empty attribute href doesn't display a link-cursor (hand).
Either put a # in your href attributes or add a cursor:pointer on a.home-module
It's the spans inside the a that cause the trouble...
You can achieve what you are trying to do with just CSS, but it requires a slightly different layout in your HTML and some extra CSS.
JSFiddle - http://jsfiddle.net/8E8um/2/
Note
In a.home-module I have added a transparent image. This is because IE7 will not assign an "empty" parameter (due to the negative text-indent) to the top level and would therefore still leave the link unclickable.
you should assign "#" to href attribute.
Try this: http://jsfiddle.net/Qk9tu/5/
I have a page that is generated by ajax/jquery at http://chainery.comoj.com/test.html. That page is the html generated by http://chainery.comoj.com#anklets. The problem is the product image is not being displayed. I think my problem lies in the css as neither the ajax page nor the html page show the image to the left of the product description. The link and image appear to be there in explorer's dom but just not showing. Everything does show in FF and safari. Also IE is not displaying any errors, that I can see.
Thank you for any tips or solutions,
Todd
This is a pretty unique issue, but I think I know what the cause is.
If you look at the generated source on your page, the img tag that you're having issues with reads exactly like this:
<img class="itempic" src="images/products/anklets/thumbnails/SSA-40_thumb.jpg" alt="Ravina - Ravina - A hana-gusari anklet" title="Click image for larger view" height="" width="">
If you look at that you'll notice that the height and width attributes are both set to an empty string (""). I'm guessing that Firefox is generously ignoring those attributes and IE is cruelly applying them. Meaning that in IE the height and width of your image are 0, since that's the closest numerical value that IE can derive from "".
Try changing whatever it is in your script that creates that tag to either set a height and width that is appropriate, or to not add those attributes at all.
I have a web page that includes an iframe as well a DHTML calendar widget. The page displays correctly as well as the content inside the iframe. The problem is when I activate the calendar which is positioned close enough to the iframe that some of the calendar is hidden by the iframe.
I have tried to manipulate the positioning of the iframe by using both javascript and CSS (Zindex, z-index) but the iframe always appears as the top most layer on the page obscurring any parent DHTML content that gets rendered in the same area as the iframe. I also changed the css of the DHTML calendar to values > 0 and wrapped the widget scriplet in a div/span with a high z-index value but no luck.
The z-index of an iframe is handled in a weird way by IE. If you can get rid of it, I'd recommend you do and just embeded the content in a regular Div.
If you don't have other choices than do it like this, keep in mind that the z-index of elements like and will be infinite in IE6. So the way to stack that is to use iframes with higher zindexes, so that it will be infinity vs infinity+1.
An example of this is vs stacking. Both have infinite z-index, but you can stack them. Checkout Stu Nicholls code, that could be helpful.
That's pretty bad thought, my fix would be to avoid having other fields in this area.
Google for "IE z-index bug" for a variety of examples and solutions to similar problems. The html specification states that z-index should be absolute, but in IE it can be determined for an element if a parent element is positioned. In extreme circumstances, I've had to trace back up the DOM tree from the element that's causing problems and set the z-index attribute on whatever parent element has position, not on the element that is being obscured (and should rightfully have its z-index set). IE Developer toolbar can help for dynamic debugging if it's really a mess, just start setting the z-index properties up the tree until you find the one that makes it looks right.
You can definitely cover the iFrame with a div.
The thing is you can't use z-index unless you use position:relative, or position:absolute, or position: fixed on the calandar div.
What you want to do is change the "position" CSS property of the calandar to be "relative". If your iFrame has the normal static positioning (meaning you didn't add any special positioning to it, this will work).
If your iFrame has "absolute" positioning, you might need to do "position:absolute" on the calandar.
See link: http://resopollution.com/test/test.html
(works in all modern browsers including IE6)
I just realized that the problem seems to be related to the MSXML and how IE transforms XML documents. The XML has an XSLT stylesheet association which the browser uses to transform the XML document. The output of the transformation is an HTML document. I didn't think it was import to disclose that I my HTTP response was XML since the HTML is what is rendered in the end, but it does matter.
When the source of the IFRAME is an HTML document everything works fine. The DHTML is not covered by the IFRAME. But when MSXML is used to transform the IFRAME content this is when the problem occurs. Below are some sample files that illustrate the problem.
For the DHTML compoenent I am using the spiffycalendar widget but I would imagine any DHTML element would produce the same results.
PARENT.HTML
IFRAME DHTML CONFLICT EXAMPLE
var pickupdate=new ctlSpiffyCalendarBox("pickupdate", "mainF", "PICKUP_DATE","btnDate1","",1);
</script>
PARENT WINDOW
FIELD
FIELD
FIELDpickupdate.writeControl();
FIELD
FIELD
FIELD
Save Changes
IFRAME.HTML
IFRAME.XSL
]>
TEST XML DOC
IFRAME CONTENT