Chrome/Opera users in Windows: wrap the following lines in any valid html skeleton:
<a id = "a" href="http://www.google.com">http://www.google.com</a>
<br />
Some text THEN a link <a id="b" href="http://www.google.com">http://www.google.com</a>
<br />
<a id="c" href="http://www.google.com">http://www.google.com</a> A link THEN some text
<br />
Now, putting the mouse aside and using only tab and the the context key/menu key/application key*, attempt to "save link as". The first and third fail and attempt to save the current page.
The second works as it should. Additionally, if I use a css reset library like normalizr, it fails on all of the links.
In IE and Firefox, all links behave as they should. This only happens in blink-based browsers.
*(call it what you will, it's the image of a mouse pointer pointing at a context menu, usually bottom right of a keyboard's alpha section and is relied on by keyboard users and blind/screenreader users).
Chromium have removed the "bug" tag on my ticket and say the desire for consistent behaviour, not just between mouse and keyboard, but even between placement of links on a line, is a "feature request".
As well as assembling a small army of blind users to explain why excluding them sucks, I'm hoping to put together rock solid technical proof too.
The trouble is, after almost the entire morning, I can't find a way of "diff"-ing the two DOM elements to find out what causes one to work and one to fail.
There are many stackoverflow answers that point to something like:
var a = document.getElementById("a");
var b = document.getElementById("b");
alert( a.isEqualNode(b) );
But it doesn't help me much anyway. The trouble is, drilling down through all the event properties, listeners, elements, styles etc seems to be an endless task - on the "blur" listener alone there appear to be almost infinite levels of property. As you can tell, I'm a but out of my depth at this point.
tl;dr version of my question
Is there any way of taking everything the DOM/browser knows about an element, and comparing it with what should be an identical element?
Clarification
This is a question relating to accessibility for users relying on keyboard-shortcuts solely affecting browsers built round the blink rendering engine. This relates to DOM, not javascript. Please consider the question carefully before removing those three essential tags or adding other irrelevant ones. Thank you.
Related
Simply out of curiosity - I have been nailed in my previous question for trying to put button within an anchored image. I looked at documentations and other questions and although everyone is saying that it should not be done, they are not saying why.
Even the documentation http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element states that there should be no interactive content within anchor, but does not tell me the reasoning.
Does anyone know why is it such a horrible practice to do so?
Imagine that situation:
<a href="http://google.com">
<select>
<option>V1</option>
<option>V2</option>
</select>
</a>
Now when you press on select element these actions will take effect (in order):
Open select dropdown.
Bubble click event to parent (<a> in this case).
<a> element follows it's href value (at this point you leave current page).
(after some delay by human body) You would select desired option (but you had already left website)
I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.
I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.
A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements, and making a heading element contenteditable is buggy in Firefox4 and can crash the page in Chrome5.
I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely, I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.
So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?
Bug notes:
Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.
Demo code
Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.
[contenteditable=true] {
border: 1px dotted #999;
}
<article style="width: 100px">
<h1 contenteditable="true">Heading</h1>
<p>
<strong>Some adjacent content</strong>
<span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
</p>
<div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
In my opinion, I'd say div is the safest bet across the board. Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element. Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.
I am looking to disable a few html controls and I am running into cross browser issues with the differences between IE and Firefox/Webkit browsers. The primary issue is evident with the following line:
<input type="text" name="badIE" disabled="disabled" style="color:blue;" value="IE won't show this correctly" />
In IE, the above input would have grey text, while the text is blue in every other browser I have tested. It would appear that IE allows the disabled field of a text input to take precedence over the CSS rules for the text color. Is there any established best practice or IE CSS hack to address this type of issue?
According to the upvoted (but not accepted) answer here, you're kind of stuck with using 'readonly'.
Just out of curiousity - why are you displaying text in a textarea that you don't even want your users to be able to focus on? Seems to me you'd be better off displaying that in a regular text HTML element (e.g. <p>).
It turns out that there are few different ways to attack this problem but there isn't one exact answer. In order to provide the most complete answer possible, here is a list of the possible solutions.
Accept the differences between browsers and continue using the disabled field. This is probably the right answer. As chipcullen suggested on his comment, there is rarely a necessity that all browsers look identical. It is better to simply accept the differences between and work with them.
Use the readonly attribute instead of disabled. The problem with this method is that a user can still interact with a readonly control. For example, users could focus on the control or stick a blinking cursor in the middle of the text. If interaction is a major concern, you can always shield the disabled control behind an invisible element, although that method is on the hacky side.
The option I chose was to replace the input elements with a pure text element. Although this method might not be as straightforward as it might sound. My page was interactive and certain elements would be enabled/disabled depending on client side actions. In order to handle the transition, I threw together the following Javascript (after chipcullen's suggestion and with the help of jQuery):
function disabledToSpan() {
$('input[type=text]:disabled, textarea:disabled').replaceWith(function () {
return $('<span>' + $(this).val() + '</span>').attr('class',
$(this).attr('class')).addClass('disabledTextInput');
});
}
In summary, this will find all disabled text inputs and textareas, switch them to spans while preserving both their values and classes, before finally adding a disabledTextInput class to specially stylize the disabled elements.
I've read various posts on this subject and think I understand the usual points of failure. I find that my two product thumbnail images, under the "This Click'n'Pick Set Consists Of The Following 2 Products" heading, are clickable, but do not take me to the named <div> element further down the page. Instead, they cause navigation to http://www.premierrange.co.uk/#bundle_product_anchor_448, for example. I see this both in Chrome (18.0.1025.33 beta) and Firefox (10.0.1) on Linux.
http://www.premierrange.co.uk/index.php?main_page=clicknpick&groups_id=2&chosen_0=243&chosen_1=448
So for example there's an anchor targeting '#bundle_product_anchor_243':
<a href="#bundle_product_anchor_243" title="Click here to jump to the 70cm Truly Curved Black Glass Curved Cooker Hood H77-7B">
<img src="http://www.premierrange.co.uk/thumbnailer.php?filename=images/H77-700.jpg&height=100" alt="70cm Truly Curved Black Glass Curved Cooker Hood H77-7B">
</a>
This targets the <div> further down the page:
<div class="productSeparator" id="bundle_product_anchor_243">
<h1>Product number 1 in this bundle of 2 products</h1>
</div>
I've also tried making the <h1> inside the target <div> be the target instead, in case the target must be an inline element rather than a div, but nothing seems to work.
The <div> containing the badly behaving <a> is completely closed by the time the <div> containing the target element appears in the document. I don't think there's a problem with the target element not being defined at the point in time the <a> is parsed by the browser.
Manually adding "#bundle_product_anchor_448" to the URL does work.
I am aware that the page fails HTML validation on a large number of points, due to a large number of factors that I'm not going to be able to address easily. I'd have thought this basic 'jump to a named element' functionality should work regardless. The page is completely functional other than this little navigation quirk.
Anyone got any clues?
Try removing <base href="http://www.premierrange.co.uk/"></base> from the page header.
The <base> tag specifies the base URL or target for all relative URLs (the ones that don't say http://www.example.com/...) on your page. Without it, your link should function as intended though you may have to fix other links to accommodate this change.
While using the <base> tag in your application, the best approach would be to just use absolute URL's before the hash, with the absolute URL pointing to the same page you're in.
So, assuming that you are on the 'http://example.com/products/curved-glass' page, instead of
<a href="#bundle_product_anchor_243">...
you would need to include the absolute current URL before the hash:
<a href="http://example.com/products/curved-glass#bundle_product_anchor_243">...
Finding out the current URL is a trivial task in most of the environments, and this method also avoids the removal of your <base> tag, action which might have negative consequences in other areas of your application.
I have a named anchor tag:
<table id="search_results" name="search_results">
I am linking to this like so:
pagename.php#search_results
This is working in Firefox and chrome, but not IE (8).
I have tried using an <a> tag as suggested in some other posts. I have also tried to give the search results table the css:
display: inline-block
as suggested by one of the commenters on this article. My table always has content as well, which the article suggests can be the reason for IE rejecting it.
I'd be grateful for any suggestions.
Many thanks
That's how I was motivated to search for a different solution:
Added text was inappropriate for the display and the non-breaking space caused an extra line space to appear between the paragraphs. This could have been corrected, but the multi-MB pages would have required a lot of manual work.
The pages, developed with iPage, can be viewed here: www.theUB.org
I've been told by several professionals that such long pages are usually avoided in web site design, but these pages (with many named anchors and a "point & click" Table of Contents) seem to work well for this 2000-page public domain text.
One more disadvantage of the non-breaking space solution:
This online text needed to be read correctly by computer screen readers. Some people have commented on other blogs that screen readers voice the non-breaking space (or added text).
(Note the added decimal point after the paragraph numbers - this was necessary to prevent screen readers from voicing the merged paragraph number and first word of paragraph.)
Couple things:
IE8 does not support inline-block ;)
When you tried the a anchor, which is probably best, was your code something like
<a name="search_results"></a>
<table name="search_results" id="search_results">
</table>
The <a name=""> method is pretty much universally supported.
Firstly, using named anchors to navigate the page does what it says. You have you use a named anchor (<a> tag) to do it. Some browsers support it on non-anchors, but this is not universal and should not be relied upon - as you have discovered.
Secondly, are you sure you page is long enough? If the thing you are trying to link to is right at the bottom of the page, it won't display at the top of the viewport as you might expect, since there is nothing below it to display at the bottom of the page.
Thirdly, check that you did the named anchor correctly. You should be doing something like this:
<a name="search_results"></a>
<table name="search_results">
...
Regarding named anchors that do not require text:
Others have suggested this "workaround" for IE8: insert a "non-breaking space" character if no text is required ( ).
However, I also discovered that resetting my IE8's View/Zoom from 125% to 100% also activated the anchors that were not corrected with the "non-breaking space" solution. IE8's View/Text Size is not part of this problem.
Note: Large, text only, HTML pages were being tested: (font face="Verdana" size="+1"). These HTML pages displayed correctly in Firefox 15.01 without regard to View/Zoom,Text Size settings.
I've got this working by adding some text inside the anchor, like:
<a name="search_results"> </a>
This appears to be another solution to the IE large file load delay: create a smaller HTML file which links via HREF to the large file (or to a bookmark (named anchor) in that file).
This test has been tried multiple times with the IE direct load of the large file always causing a long delay, but not when the user clicks the link in the small file to go to the large file.
Perhaps, IE is analyzing the primary file to see if it had already been loaded into the cache.
Note: This HTML file being tested is 11 MB (an entire book with many bookmarks and links to those bookmarks from other parts of this very long HTML page).
I faced the same problem on IE, Edge and chrome,
and I think the problem is because the encoding and decoding on the name attribute
so I did a workaround solution, take a look
anchorElem.on("click",function() {
var href = $(this).attr('href');
var scrollEle = $(".tocContent").find('a[name="' + href.substr(1) + '"]' + ', a[name="' + decodeURIComponent(href).substr(1) + '"]');
if (scrollEle.length > 0) {
$('html, body').animate({
scrollTop: scrollEle.offset().top
}, 0);
return false;
}
})
hope this help you
and happy solving browser compatibility issues