Search the Community

I'm trying to work with SVGs but I'm pretty sure there's going to be some people using the old browsers that don't do this, so I'm looking into installing some kind of a fallback. Is there some way I can do this? Maybe make a DIV with the PNG for the background and containing the SVG?

Hi guys! I just went through difficult maintenance for a website project involving iframes with the necessity of short, not embedded initial content. I was using @srcdoc and it already was difficult enough as syntax rules. Then I changed mime type for the pages, converting them into proper XHTML, and the result was confusing and terrible: Syntax adjustments for the "markup model" inside the attribute's value made me double the length of the value. It is not checked by validator, so predicting errors is difficult. It relies on the support of @seamless in order to match the design of the page, or otherwise it needs style declaration/stylesheet embedding which make it longer and impact on page loading while using several iframes in the page. Anyway using both could lead to conflicts during the (future, eventual) transition phase when @seamless is implemented on some UAs but not all and/or we'll have to face both support and backward compatibility. inserting semantic markup is too long because it ends up being treated as external document, so there must me a link reference to the main argument which is pointless (IMO), as the content is actually part of the page containing the main argument itself. XML serialization is wrong also in those browsers which currently support @srcdoc: Firefox always parses it as HTML, while the other ones complete the srcdoc document with tags missing (following the spec rules about tag omission in text/html) also where this is not requested. @srcdoc syntax is difficult to find, read, parse and serialize for any client different from browsers, i.e. search engines, data mining tools, scripts which fetch documents, and even for the authors themselves which have to write proper scripts for retrieving data (perhaps from databases) and insert them in a so particular position (with a special syntax inside an attribute) it is theoretically confusing because it mixes elements and attributes. It forces authors to write unmaintainable document fragments, also denying them the use of common editing aids like indentation and markup highlighting. These reasons and many more make iframe@srcdoc practically unusable now and in the near future. It is not a case that in webpages fetched by webdevdata as of october 2013 no use of @srcdoc has ever been made. And I suppose neither is a case that iframe@srcdoc is the very only feature making use of a "markup model" inside an attribute value. Now, iframe is not a void element: the restrictions on content, different between HTML (content model: text) and XHTML (content model: empty) documents, have been introduced with HTML5. Has anyone ever thought that the very same results of @srcdoc, with better, richer and more practical result using the native <iframe>'s content?