Chrome doesn't select <linearGradient> with D3.js. In the following code all selections are empty.
var defs = d3.select("body").append("svg").append("defs");
defs.append("linearGradient");
defs.append("linearGradient");
console.log(defs.selectAll("linearGradient")); // empty
console.log(defs.selectAll("lineargradient")); // empty
console.log(d3.selectAll("linearGradient")); // empty
If you replace <linearGradient> with say <mask> it's all right.
var defs = d3.select("body").append("svg").append("defs");
defs.append("mask");
defs.append("mask");
console.log(defs.selectAll("mask")); // 2 elements selected
Firefox works fine for both. I'm using Chrome 28.0.1500.95. Please suggest a way to select the gradients.
This is a bug in webkit -- see the bug report. The short answer is that for it's just broken. You may be able to work around this by keeping explicit references to the gradients you need to modify, e.g.
var grad1 = defs.append("linearGradient");
Related
I've looked through a number of posts all pointing towards different ways of using the autocomplete property, but I have yet to have this work in all my browsers. I've seen some really ugly workarounds such as this, but I'm looking for something that is clean and easy.
What is a good way to disable text field autofill on all (or at least, most) common browsers?
The following code will disable autocomplete in FF, IE, and Chrome.
<script>
$(document).ready(function () {
// IE & FF
$('input').attr('autocomplete', 'off');
// Chrome
if ( $.browser.webkit ) {
$('input').attr('autocomplete', 'new-password');
}});
</script>
Enabling Autocomplete on both form and input fields (with the "off" value) for the sake of those law-abiding browsers that do play by the rules is always a good beginning - also for the unlikely event that one day "other" browser...s may feel like compliance isn't all bad.
Until that day hacks are needed. I've noticed that Chrome looks for matching data in at least three places: Labels (contexts), Names and Placeholders. If the Name field is missing from input fields it will look in both Labels and placeholders, but if the Name field is present it will only look in Name and Placeholder.
This script utilize the "form-control" class from Bootstrap on input fields that must be guarded from Autocomplete. Use any other class or filter you like. Also assuming that Placeholders are in use - just remove that part if not.
$(document).ready(function() {
// Begin
var this_obj = null, this_placeholder = null, this_name = null;
$(".form-control").focus(function() {
this_obj = this;
this_name = $(this).prop("name");
this_placeholder = $(this).attr("placeholder");
$(this).prop("name", "NaN" + Math.random());
$(this).attr("placeholder", "...");
}).blur(function() {
$(this_obj).prop("name", this_name);
$(This_obj).attr("placeholder", this_placeholder);
});
// End
});
Note: Leaving the Placeholder empty might actually inadvertently trigger the Autocomplete function as empty assignments are apparently ignored.
The two variables this_name and this_placeholder may be avoided as they are accessible through this_obj, but I like to keep them around for the sake of readability and clarity.
The Script is erm.. quite unobtrusive, as it cleans up after itself and it only requires one matching class or attribute.
It works in Version 68.0.3440.106 (Officiel version) (64-bit), IE11 11.228.17134.0 and Firefox 61.0.2 (64-bit). Sorry, haven't tested others.
Add a class to all your input tags, suppose no-complete
And in your js file add following code:
setTimeout(function (){
$('.no-complete').val ("");
},1);
I'm experiencing a major bug in IE 11 (latest version 11.0.9600.16521 on Windows 7). When on any form if I open a select dropdown all the other form fields on the page freeze. I can 'unfreeze' them by adjusting the Window size (causing a redraw). This seems to happen on any form what-so-ever.
To reproduce:
Open IE 11.0.9600.16521
Go to http://www.wikipedia.org/
Select any language from the language dropdown
Result:
language dropdown does not appear to get updated on the screen
the search box appears to be frozen - i.e. focus on select box and start typing but no text appears. However if you adjust the window size the form fields are updated and go back to working as normal (until you interact with another select element)
I can't find much in Google for this issue so maybe it's just something specific to my settings. Only thing that sounds somewhat similar to what I'm experiencing is this: http://connect.microsoft.com/IE/feedback/details/806679/ie-11-desktop-selecting-an-item-from-a-drop-down-list-on-a-webpage-causes-the-tab-to-crash. Anyone else able to reproduce this?
I had a similar issue with IE11 that turned out to be any modification to the .text property of an SELECT-option element. I eventually found the "hint" on stackoverflow here
How to fix IE select issue when dynamically changing options.
In my case I use straight JavaScript, and with so many inter-dependent SELECT boxes had to come up with a generic solution, so my solution was to intercept (defineGetter) assignment to any .text property of an HTMLOptionElement, and set a 1 ms timer to perform an add element and remove element as in the referenced post that is titled "I have the fix. We have to add and remove options list to trigger the rendering in IE8." Notice the reference to IE8, AFAIK IE has had several issues with SELECT boxes since at least IE7, possibly earlier.
So the code I added to one of my global scripts is as follows:
try { var IE11; // IE10 and IE11 removed ActiveXObject from the window object but it can still be instantiated
IE11 = new ActiveXObject('MSXML2.DOMDocument.6.0');
IE11 = null;
if (typeof(HTMLOptionElement) != "undefined") {
try { HTMLOptionElement.prototype.__defineSetter__(
'text',
function(original) {
return function(newValue) { var sel;
original.call(this, newValue);
if (!(sel=this.parentElement).fixIE) sel.fixIE = window.setTimeout(_fixIE_(sel), 1);
}
}(HTMLOptionElement.prototype.__lookupSetter__('text')));
} catch(e) {};
}
} catch(e) {}
}
// IE11 broke SELECT boxes again, modifying any options .text attribute "freezes" the SELECT so it appears disabled
function _fixIE_(selBox) {
return _fixIE_;
function _fixIE_(){ var lc = selBox.options.length;
selBox.options.add(new Option('',''));
selBox.options.remove(lc);
selBox.fixIE = undefined;
}
}
Phil
Go to programs
Then widdcom folder
Right click bttray
Go compatibility
Tick run as admin
Restart
I had the same problem in IE 11 on Dell Windows 7.
It was solved by turning off hardware rendering in IE, as you suggested in your link.
According to the HTML5 specs the dropEffect property on a drop target allows the drop target to select the desired drop effect. The drag and drop framework should combine this with the effectAllowed property set by the drag source to display the matching visual feedback (typically a specific cursor depending on the operation).
I was however not able to use this feature consistently across browsers. It seems to work for Chrome and Opera as expected but doe not for IE and FF (although the developer documentation for each browsers explicitly documents it).
I have put together a sample on JSFiddle: http://jsfiddle.net/cleue/zT87T/
function onDragStart(element, event) {
var dataTransfer = event.dataTransfer,
effect = element.innerText || element.textContent;
dataTransfer.effectAllowed = effect;
dataTransfer.setData("Text", effect);
dataTransfer.setDragImage(element, 0, 0);
}
function onDragEnter(element, event) {
var dataTransfer = event.dataTransfer,
effect = element.innerText || element.textContent;
dataTransfer.dropEffect = effect;
event.preventDefault();
}
function onDragOver(element, event) {
var dataTransfer = event.dataTransfer,
effect = element.innerText || element.textContent;
dataTransfer.dropEffect = effect;
event.preventDefault();
}
Is this sample incorrect or my understanding of the purpose of this feature or are these browser bugs?
i had exactly the same problem and came to the same conclusion as yourself, it just doesn't work. In addition to changing the mouse cursor there is the job of working out at the source element what took place - from the spec you can listen to dragend and e.g. remove the element if the drop effect was move and leave it if it were copy. That doesn't work consistently either. I asked the question here, i put a longish explanation with all my findings.
btw - i see it says that drag and drop is at risk from being removed due to a lack of implementation which is a pity.
I am trying to clone an HTML node using cloneNode() method of browser's DOM API and even using Jquery clone() function. The API works perfectly fine with HTML tags, However i am facing some issues while using it with HTML5 tags like time e.g.
The issue is that following <time> tag content <time class="storydate">April 7, 2010</time> gets converted to: <:time class=storydate awpUniq="912">April 7, 2010. Although IE renders the original time node correctly then why such issue with the clone API.
And this issue isn't observed in FF/ chrome. Please give some clue how to avoid this
Is this of any help? From the HTML5 Shiv issue list:
http://code.google.com/p/html5shiv/issues/detail?id=28
Links to
http://pastie.org/935834#49
solution seems to be:
// Issue: <HTML5_elements> become <:HTML5_elements> when element is cloneNode'd
// Solution: use an alternate cloneNode function, the default is broken and should not be used in IE anyway (for example: it should not clone events)
// Example of HTML5-safe element cloning
function html5_cloneNode(element) {
var div = html5_createElement('div'); // create a HTML5-safe element
div.innerHTML = element.outerHTML; // set HTML5-safe element's innerHTML as input element's outerHTML
return div.firstChild; // return HTML5-safe element's first child, which is an outerHTML clone of the input element
} // critique: function could be written more cross-browser friendly?
Custom data attributes: http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data
When I say “work”, I mean, if I’ve got HTML like this:
<div id="geoff" data-geoff="geoff de geoff">
will the following JavaScript:
var geoff = document.getElementById('geoff');
alert(geoff.dataGeoff);
produce, in IE 6, an alert with “geoff de geoff” in it?
You can retrieve values of custom (or your own) attributes using getAttribute. Following your example with
<div id="geoff" data-geoff="geoff de geoff">
I can get the value of data-geoff using
var geoff = document.getElementById("geoff");
alert(geoff.getAttribute("data-geoff"));
See MSDN. And although it is mentioned there that you need IE7 to get this to work, I tested this a while ago with IE6 and it functioned correctly (even in quirks mode).
But this has nothing to do with HTML5-specific attributes, of course.
Yes, they work.
IE has supported getAttribute() from IE4 which is what jQuery uses internally for data().
data = elem.getAttribute( "data-" + key ); // Line 1606, jQuery.1.5.2.js
So you can either use jQuery's .data() method or plain vanilla JavaScript:
Sample HTML
<div id="some-data" data-name="Tom"></div>
Javascript
var el = document.getElementById("some-data");
var name = el.getAttribute("data-name");
alert(name);
jQuery
var name = $("#some-data").data("name");
Not only does IE6 not support the HTML5 Data Attribute feature, in fact virtually no current browser supports them! The only exception at the moment is Chrome.
You are perfectly at liberty to use data-geoff="geoff de geoff" as an attribute, but only Chrome of the current browser versions will give you the .dataGeoff property.
Fortunately, all current browsers - including IE6 - can reference unknown attributes using the standard DOM .getAttribute() method, so .getAttribute("data-geoff") will work everywhere.
In the very near future, new versions of Firefox and Safari will start to support the data attributes, but given that there's a perfectly good way of accessessing it that works in all browsers, then there's really no reason to be using the HTML5 method that will only work for some of your visitors.
You can see more about the current state of support for this feature at CanIUse.com.
Hope that helps.
I think IE has always supported this (at least starting from IE4) and you can access them from JS. They were called 'expando properties'. See old MSDN article
This behaviour can be disabled by setting the expando property to false on a DOM element (it's true by default, so the expando properties work by default).
Edit: fixed the URL
If you wanted to retrieve all of the custom data attributes at once like the dataset property in newer browsers, you could do the following. This is what I did and works great for me in ie7+.
function getDataSet(node) {
var dataset = {};
var attrs = node.attributes;
for (var i = 0; i < attrs.length; i++) {
var attr = attrs.item(i);
// make sure it is a data attribute
if(attr.nodeName.match(new RegExp(/^data-/))) {
// remove the 'data-' from the string
dataset[attr.nodeName.replace(new RegExp('^data-'), '')] = attr.nodeValue;
}
}
return dataset;
}
In IE6, it may not work. For reference: MSDN
I suggest using jQuery to handle most of the cases:
var geoff = $("#geoff").data("data-geoff");
alert(geoff);
Try this in your coding.