I am creating a website and need to have a specific link open with the Edge browser. (Company designed software to only work with Edge as its easier for SSO, not compatible with Firefox or Chrome)
I created an anchor tag with the microsoft-edge parameter and the link will open up fine when using other browsers like Firefox (a popup will force the user to select edge) but when actually using edge the link does not do anything. Upon inspecting element the anchor tag is not even rendered in the DOM.
The following is an example of how i used the anchor.
<a href="microsoft-edge:https://google.com> Click Here </a>
Any advice?
Well, to start, your anchor, <a href="microsoft-edge:https://google.com> is missing a " to close the value of the href attribute. The working code appears in the following snippet:
Click Here
However, this only explains the final issue you mention :
...the anchor tag is not even rendered in the DOM
(I assume you got tangled up in your troubleshooting steps)
The actual problem is that Microsoft Edge doesn't support the microsoft-edge: protocol. I haven't found a published source for this, but I have found a reference to this issue (and a javascript-based workaround) in the SO answer: https://stackoverflow.com/a/53765993/2540235
Related
TL;DR
How/why are some browsers able to search and highlight text in the HTML body which is followed by #:~:text= in the URL?
Explanation
One day I was searching for something on Google, which lead me to Quora's result. I observed that 2 sentences were highlighted in yellow, which were part of URL after the aforementioned parameter. I thought this would be Quora's feature for SEO or something, however, also found this on Linkedin, and Medium, and so on.
I'd like to know:
What is this highlighting called? Why/how does it work?
This seems to be browser-specific. What kind of browsers support this?
It seems to work on Chrome and Edge; but not on Firefox, Safari, and IE.
Does a frontend programmer need to incorporate something in the code to have search engines highlight content on their web-pages? (Based on the assumption that search engines actually appends the relevant string predicted by user's query)
The highlighting is called Text Fragments. Its a new feature that was recently added to Chrome 80. It works by specifying a text snippet in the URL hash.
Yes it is browser specific.
No, the experience that you get when clicking on a link from Google's search results is part of Featured Snippets which are algorithmically determined. There is nothing you can incorporate into your code to prompt search engines to highlight text on your page.
There is no markup needed by webmasters. This happens automatically,
using Scroll To Text for HTML pages
https://chromestatus.com/feature/4733392803332096. See also more
background here: https://support.google.com/webmasters/answer/6229325
Sources:
https://web.dev/text-fragments/
https://www.theverge.com/2020/6/4/21280115/google-search-engine-yellow-highlight-featured-snippet-anchor-text
https://www.theverge.com/2020/6/18/21295300/google-link-to-text-fragment-chrome-extension-chromium-highlight-scroll-down
https://searchengineland.com/google-launches-featured-snippet-to-web-page-content-highlight-feature-335511
https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html
While text fragments is natively implemented only in latest Google Chrome (and the latest versions of Chromium-based browsers, such as the new Microsoft Edge), there is a browser extension/add-on that seems to enable it on Firefox and Safari: https://github.com/GoogleChromeLabs/link-to-text-fragment
It appears to use #ref-for-fragment-directive:~:text= and additional arguments (instead of just simple #:~:text=).
Firefox: https://addons.mozilla.org/firefox/addon/link-to-text-fragment/
Safari: https://apps.apple.com/app/link-to-text-fragment/id1532224396
Curiously enough, the extension has also been made available for Chrome and Edge too (!).
.
UPDATE: I'm testing it on Firefox Developer Edition, and it doesn't work for me.
I use Chrome as my default navigator and it's been a while that I have to appeal to other browsers (or external tools like Dash) whenever I need to read some apple documentation because Apple docs menu style is just broken for me on Chrome.
The unusual thing is that it does not seem to be a CSS incompatibility issue, but seems that the DOM is not being created accordingly to the page's HTML.
This doc page, for example, has this HTML for the menu:
<menu id="bashful" type="toolbar">
<div class="shield"></div>
<menuitem id="jump_to" class="menu-bar-item closed">
<span>On This Page</span>
<div class="chevron"> ... </div>
<menu type="list" class="details">
<ul class="list-bullet">
<li class="item">
Mutability of Collections
</li>
...
</ul>
</menu>
</menuitem>
</menu>
Ignoring their poor indentation, it is pretty clear that all menu items are inside the <menuitem> tag, but when inspecting my chrome elements tab, it does not show that, it shows the <span> and <menu> tags all outside it, making a lot of CSS selectors rules to stop applying.
Here is how it is being shown on Chrome (buggy)
and Chrome Canary (works properly),
This tests were done with the following browser versions
Chrome Version 45.0.2454.101 (64-bit) - breaks
Chrome Canary Version 48.0.2528.0 canary (64-bit) - works
Firefox 40.0.3 - works
Safari Version 8.0.8 (10600.8.9) - works
First I suspected it to be a simple browser incompatibility issue, so I tried to replicate the problem asking for other people with the same browser to test Apple docs link, but so far I was the only one with this "problem"
I already also tried:
Disabled all browser extensions
Disabled/Clear all browser cache
Compared both browser downloaded HTML and CSS resources but they are identical
I created a codepen with just this piece of HTML and the same issue occurs without all other Apple docs garbage if you want a simple HTML for better analysis
I checked <menuitem> on mdn and it seems that the label attribute is "Required when a command attribute is not present", but it this enough to break everything on Chrome? Is Apple using <menuitem> for purposes other than the intended in the specification?
Well, does anybody know what might be the cause and what are possible solutions to this annoying issue?
This is part of Chromium issue #87553 "Implement HTMJ5 menu tag".
menuitem parsing is implemented a year ago on Aug 2014.
Overall, it seems to be mostly done, but the feature is still "in development" and is not yet "shipped", so it is disabled by default in stable channel.
When it is not enabled, current stable Chrome (v.45) does not know menuitem and parse it as a normal element requiring end tag, instead of as a content-less element without end tag according to spec.
But if you enable the "Experimental Web Platform Features" Chrome flags, your code will be parsed correctly.
For now, you can make sure the tags are properly closed.
(Self-closing, as the spec suggested, does not work for Chrome.)
As long as the menuitem is empty, standard compliance browsers will ignore it and there is no harm done.
P.S. Technically, throwing error and stop is also standard compliance, but no browser really do that.
These are (usually and currently) the only compliance options - die or ignore.
P.S.2 In case it is not clear, as of Oct 2015, menuitem element cannot and should not have content, and this part is the same as the Jan 2015 spec.
According to the MDN Documentation, the <menuitem> element is an experimental technology and it must be nested as a child element of a <menu> element. The element is supposed to provide HTML access to context menus i.e. for right click menus. It has only been officially supported by Firefox. Officially, none of the other browsers support it, which means that it's rendering would be undefined. It may be handled as XML data, or it could be mishandled as some other HTML element that the browser has a definition for, but that's purely speculative.
I find it curious that Apple is using an experimental HTML element that Safari, Apple's own browser, does not officially support. Perhaps they intend to support the element in a future version of Safari, and one of their web devs jumped the gun by using it in a production environment. Even if the element was supported, it still may not function correctly. The current documentation states that there are required attributes (either one of label or command) which are not used in Apple's code. So the code would still be bad even if it was officially supported.
The short answer is: Apple screwed up, and they need to fix their HTML.
Meanwhile the only "possible solution" for users is to use a different browser. On the developer side, though, there is a nicer solution. If you want to learn about the way that context menus are supposed to be implemented in Chrome, Google has provided an API for that purpose.
While using haslink (#testhash) is not working on Safari. I am really unable to locate the problem.
Here is the following code I am providing below
Click here to go to Hash
<div style="height:500px"> </div>
<div id="testhash"></div>
<div>............Test Data............</div>
When I am clicking on the link, it is got going to proper place on Safari but it is working fine on Google Chrome, Mozila Firefox and IE9. In Safari the link is redirect to the site http://example.com/ instead http://example.com/#testhash after URL rewritting. The funny thing is when I am directly putting the link http://example.com/#testhash on the address bar of Safari, it is working fine but the time of clicking it is not working and also when I am writting http://example.com/?page_id=112#testhash, it is giving problem.
You may do one thing. Give the full link instead of ?page_id because sometime Safari or some other browsers write different rewrite rules for Wordpress and thats why Hashlinks doesn't work. You may put
Click here to go to Hash
instead of
Click here to go to Hash and it may work.
*I meant by Rewritten page as the browser divides the page by parents and children like about-us/page/etc so the url should be from my example http://testwordpress.com/about-us/page/etc/#testhash
Can you change the href to just "#testhash" and see if that fixes your problem?
Editing my answer as it wasn't clear:
Try this:
Click here to go to Hash
<div style="height:1200px"> </div>
<a name="testhash" />
<div id="testhash"></div>
I'm using Firefox alongside Firebug Developer tools.
Is the HTML shown in View Source (Ctrl + U) different from the HTML I see when inspecting elements using Firebug?
What are the differences between the two?
Yes they are different.
View source shows you the original HTML source of the page.
The inspector shows you the DOM as it was interpreted by the browser. This includes for example changes made by javascript which cannot be seen in the HTML source.
Oh and this also counts for the developer tools that allow you to view the DOM in other browsers, like the Chrome Web Inspector and Internet Explorer Developer Toolbar. The HTML source will always be the same across all browsers, the generated DOM might differ as it is an interpretation and render engines are not all the same (unfortunately).
It should also be noted that aside from the dynamic DOM manipulation which could be occurring via javascript etc, Firefox will also parse and "clean-up" malformed (X)HTML, so these changes will also affect what you see when inspecting an element.
The difference are (but not limited to) that in firebug console you can see dynamically changes, which occurred in web page. For example, DOM elements modifications (from AJAX or regular JavaScript), CSS in-place modifications, etc...
In Firefox, View Source may reload the page, changing what is on it. See this bug and vote for it if it is bothering you:
https://bugzilla.mozilla.org/show_bug.cgi?id=307089
I have a very weird problem, I have a markup, which is being treated by chrome (tested on mac, windows, and ubuntu-chromium) in weird manner..
I've created a simple version of the situation..
<h3>First Part<span>Content in Span</span></h3>
Chrome is adding extra quotes to First Part, while its not present in any other browser (tested on Firefox, and ie.)
Simple demo I've created on JsFiddle here..
In Chrome:
In Firefox:
This is just the way that chrome presents the text node content in the element inspector. You can see white-space better this way. The quotes are purely virtual.
The quotes do not exist in your HTML document. They just appear in Chrome, to show that you are viewing the text content of an element.
You shouldn't worry about them at all. If you check the Source code (right click, View Page Source), you will see that they are not there.