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.
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.
Working on implementing/fixing the accessibility features of my client's website, we stumbled on the particular case that Firefox decides to set focus to an <iframe> when tabbing through a page, which no other browser does. The client then suggested that the <iframe> content be given a title attribute (in the <head> of the loaded HTML) so that the VoiceOver feature (and its equivalents) reads the <iframe> title out loud.
This works when tested in a void, as you can test here:
http://dev.jansensan.net/tests/iframe-title-accessibility/
http://dev.jansensan.net/tests/iframe-title-accessibility/one-time-payment.html
So in the context of the project, this should also work. However the browser keeps saying "Firefox busy" no matter what we tab onto.
What would cause this situation? I have tried asking on the Mozilla Support forums in the hopes of being pointed to some documentation that would provide some guidance, to no avail.
We would appreciate some guidance, in order to see if we need to change something in our content, or if this is an issue with Firefox itself.
I was having issues because of Chrome automatically referencing DIV... It works that way in Safari (desktop and mobile), but not in Firefox.
See image:
See Fiddle (open in Chrome, then in Firefox):
http://jsfiddle.net/stefek99/Sqcff/
The question is - how to disable this feature? I would really like to develop in "strict" mode without any Google quirks, just to make sure my code is cross-browser compliant.
This is a known 'problem', however I have not been able to find a reliable method of disabling this. One might think that "use strict"; should probably disable it but that doesn't seem to be the case.
In any case, some more explanation on it; Do DOM tree elements with ids become global variables? As explained there it will probably be standardized in HTML5. It all started out as a non-standard IE feature, which ofcourse got mimicked in other browsers. Theres even a msdn blog post noting it as a 'problem' so it seems a bit silly the HTML5 working group is trying to standardize it now.
I would like to note to anybody to please not rely on this problem feature as it is very ambiguous and hard to debug for programmers who don't know of it.
Please check out this snippet of my site.
http://jsfiddle.net/TmnPV/
The logo is made up of the 'circle1' and other div tags in the same html sections. It doesn't show up on jsfiddle either and it looks different on every browser.
On chrome = shows all
On firefox = no logo shows and bottom text under input field is larger
On safari = no logo shows
What can I do?
This is called, umm... , welcome to wild wild world of web. Every browser vendor parses html/css/javascript differently. Some are lenient, some are strict. (Chrome Vs. Opera). Some have different Box model, some have standard operational behavior, some tend to do their own thing.(Opera Vs. IE6)
Answer to different renderings : You have to hunt down each and every little quirk. One by one.
Welcome.
You'll need to adjust your styles for older browsers if you plan on doing alot of css3 transforms.
IE 6, 7, and 8 just don't have the ability to read those styles.
Even on Firefox, depending on the version, you'll run into various spacing issues since the rendering engine is different than Chrome (and Safari).
For using html5 and css3 in older IEs you can (sparingly) use polyfills, which duplicate the effect using javascript. You can see a list of available polyfills here:
https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
Quirksmode is a great resource for checking compatibility: http://www.quirksmode.org/compatibility.html
I would highly recommend the Firebug add-on for Firefox to see where the extra spacing, etc is happening.
When you run into a specific issue with a specific browser that you can't figure out post a question here. It's much easier to help with one bug than just general browser problems.
That's mostly because you are using code to work with one browser. Different browser uses different code renderer. It's hard to make everything look the same, even tho Internet explorer is the worst, other browsers have different features. Opera has most of the HTML5 form features, that no other browser supports so far, but Chrome and Firefox supports the most of the HTML5 attributes. Hope this helps understand the reason why.
Is there a Windows application that I could use to simply paste the HTML source of a page, and have it parsed so that I can see where each section starts and ends?
When lines are wrongly indented, it's a pain to figure out the logic of a page.
I'd rather a stand-alone utility rather than an add-on to a browser.
Thank you.
Edit: If possible, I'd like a light utility (ie. not a full-fledged IDE like Eclipse or VS) that displays blocks as a tree, so I can fold/unfold blocks and concentrate on those I'm interested in.
If you develop your HTML in Eclipse or IntelliJ you can use the format code shortcut
The built-in DOM inspectors in most modern browsers would be a good start. I know you said stand-alone rather than a browser add-on, but the advantage with these is that they will highlight the element on the page which is extremely handy. They're also good for playing with CSS and quick Javascript experiments.
For IE8, go to Tools > Developer Tools (or F12). There are a couple of extentions available for IE6 & IE7: IE Developer Toolbar and Web Development Helper
For Opera and Chrome, simply right click anywhere > Inspect Element. Safari also has this it just has to be enabled.
For Firefox you need to download Firebug
Of all of these I prefer Firebug. In my experience it tends to be most stable and easiest to make HTML and CSS changes to the page for experimenting, although the WebKit inspector is also very good.
Always remember that these tools show you the parsed DOM tree, which may be different from the original HTML.
Sounds like HTML tidy will fit the bill.
Many programmer editors already have this in place - notepad++ has a HTML tidy feature, visual studio can also be used (Ctrl + k + d).
Install freeware Opera Browser, navigate to the page, right click on something, press "Inspect element".