However once picture is supported, that is a better option than the alternative, which is that those who have JavaScript disabled in browser that supports picture would see two copies of the same image. Initially, the 0.2% of site traffic that actually has JavaScript disabled will see alt text rather than an image. Modify tests to no longer check for the noscript element or fallback image. Remove supporting functions that generate the fallback image in the noscript element Modify markup to remove noscript element Remove noscript from our markup for the picture element. That means that 0.2% of traffic will see alt text instead of an image, but that's probably better than getting two copies of an images downloaded and displayed, which slows down page rendering time and screws up the layout. A better solution is to drop noscript from our markup. Hello, I would also like to add to this conversation, as we also had similar request from our SEO specialists to remove this noscript tag, as it makes search bots think that the image is duplicated (it's alt attribute is saved in cache, that's what triggered SEO specialists). As browsers start to implement picture support, though, noscript will become a real problem for those people, as it will cause them to see two copies of an image. So right now noscript provides a benefit to a small number of people: the 0.2% of traffic where JS is disabled in the browser. If JS is enabled but not working, noscript doesn't do anything: that's a much larger percentage, about 0.9% of traffic. ) shows that noscript only works when JS is disabled in the browser, which is about 0.2% of traffic. The problem is that for those who are using a browser that supports picture, but have JavaScript disabled, they will get two copies of the image downloaded and displayed, which is really bad. Once that change is made, we will have another issue, which is detailed in an issue related to the refactoring of the polyfill for the picture element, Picturefill: In client/ReactDOM.We are working to add an empty img element inside the picture element in issue #2220865: Add empty img element inside picture element to match up with the current version of the picture specification, and to ensure that the img displayed by the picture element (once supported by browsers) has a proper alt attribute. Would this be doable in the new codebase? Either way it should be a separate issue. While it's really really awesome that React 16 now handles, if we want a really great story around noscript, I’d say automatically removing nested noscript-tags as per suggestion in Nested renders invalid HTML #6204 is key.The proposed solution to ignore the content of noscript-tags on the client is perfect (as long as we still keep the existing content in them).(If JS crashes before bucket has been set - Catch error and replace all relevant noscript-tags with divs and set their innerHTML with the innerHTML of the noscript-tag).Use dangerouslySetInnerHTML with the above.Instead of renderToStaticMarkup - Read existing textContent/innerHTML of the noscript-tag.Remove all nested noscript-tags in the resulting string (quite common for us since we also use noscript-fallbacks for lazy-loaded images).Render default component with renderToStaticMarkup (including using a couple of Providers to make Redux and react-router work).It could be as easy as but to make this work fully we have had to: Providing a noscript-fallback for conditional functionality that is determined on the client might be a bit niche but shouldn’t be that uncommon either. Often we still want to provide a default variant (in a noscript-tag) for people without JS, or as graceful degradation in cases where JS has crashed. We use this mainly for A/B-testing for cases where we want to determine the bucket on the client and render a component only after that. I've been tracking this issue since #1252 and #6204 so I'll chime in with our current use-case and some thoughts (long post but some background is necessary I think).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |