I'm using Normalizr to display alternate PNG background images, where SVG is being used, for older browsers.
The no-svg class is being triggered, however, there are some strange results: background sizing properties set on the backgrounds are lost on some elements, but seem to be retained on others. Furthermore, I couldn't use shorthand to set this (having to write separate declarations), but I imagine that's the browser's fault.
I need to control the sizing, especially because the layout is responsive.
If you have any ideas, please do reply.
Thank you for your time.
Related
I've been mocking up a landing page in Adobe Illustrator, and I'm about to begin coding it.
Is there a reason I shouldn't just export the whole page as an SVG and use that in lieu of recreating everything in html/css?
The only cons I can think of are:
SEO, as I won't have regular text
(easy enough to just remove text from SVGs and recreate in html)
User interaction (buttons etc)
(same solution as the SEO problem)
Responsiveness with respect to elements repositioning at different viewport sizes.
(trickier; but already mocked up a few different layouts for different device sizes, so i can just serve different versions)
My suspicion is there's something I'm missing, because I haven't been able to find anything online addressing this approach.
Some clarification:
I believe SVG compatibility gets dodgy before IE9 or so, but my product involves a chrome extension, so this isn't a huge concern
my design is Material Design-inspired, so there are a lot of colored divs & the like. this is a good approximation (source):
While the buttons and text would best be handled with HTML/CSS/JS, I'm interested in the reasons that the rest of it (i.e., the image and layout components) can't be handled w/ a single SVG.
How can you add a footer in SVG always at the bottom of the page with dynamic page content?
I think that the main difference is that a SVG is a canvas with fixed height and width, html document has a dynamic-sized window.
I want to create an opacity blur overlay, similar to Windows Aero or iOS7. Unfortunately the filter: blur() or filter: url(#svgBlur) properties can only apply to the element, not content behind it.
To get round this we need a copy of the background that is blurred. This is possible in FX using the background: -moz-element(#elementId) experimental CSS property. Using that I can get the effect I want in FX only.
There are other questions about solving the blur problem, and one solution appears to be the use of the html2Canvas plug in.
However that is recreating the entire blurred content, including manually recreated styles and the like. It's very impressive work, but it seems like massive overkill (both in performance and size) for this kind of effect.
What I want to do is create is some kind of shim just for -moz-element. It looks like that should be possible using an SVG foreignObject, but that has both security issues and fails if your HTML is not valid XML.
Is there any way round of emulating -moz-element (using canvas, SVG, or something else) where I don't have to parse/redraw the entire overlaid area?
Browsers that support the BackgroundImage pseudo input allow you to filter the content behind an element. Opera 12 supports that and maybe some other UAs too.
I think Opera 12 also supports the SVG 1.2 Tiny feature of having an external foreignObject i.e.
<foreignObject xlink:href="external file url"/>
You could combine this with the backgroundImage to have html content as a background even if the html content was not not valid XML.
Your milage may vary with other UAs though and as you say Firefox has a different solution.
You can check out a plugin I recently made called AeroJS. It does exactly what you're looking for and supports everything but IE.
EDIT: My apologies for not not including a description of the plugin.
Basically, the way AeroJS works is by taking the HTML of a specified element (backgroundElement), the background image of a specified element (backgroundImage) and prepending them to the specified element. Then, using WebKit's blur filter, a specified amount of blur (blurAmount) is applied to the elements in the background. It's still in the early stages of development so bugs are expected. One drawback of using AeroJS is that it's almost entirely static. You can move around the element and everythung behind it will be blurred however any changes that happen to the original DOM will not be reflected in the blurred/copied HTML. Custom code will be needed for that.
If those properties only apply to the selected element, why don't you select them all?
Maybe with:
#myElementID *
I am on a team trying to convert our Flash Application into HTML5 and Css, and I am running into a bug affecting WebKit and wanted some help trying to figure it out. The basic idea is that there is a table with a single cell with a background image and a background color and for whatever reason when the image is exactly the right size background-size: 100% 100% the image actually shrinks to reveal the background color. This also repeats if I use pixel values instead of % values.
Before anyone tells me to just use a div (since its only one cell anyway), this content is authored by other people who are using an existing tool to create a custom xml document that gives us tables and I have to get my solution to work on the pre-existing content we already have.
This is the fiddle which shows it and follows are image in various browsers:
http://jsfiddle.net/CEvnx/2/
Flash (Reference)
Firefox (working)
Chrome (the image shrinks)
Safari (the image grows)
P.S. Ignore the height and font differences as those aren't in any way relevant to the problem.
has to do with the table's border-width, if you set border-width at 2px or less the background sizes correct (in Chrome/Safari). Quite strange that Chrome shrinks and Safari grows. There must be some odd math or image resize logic in webkit and probably worth submitting a bug report.
I've been experimenting with pretty complicated SVG backgrounds (via CSS, fixed, 100% size) and it makes both FF and Webkit based browsers slow to a crawl, to the point it's impossible to scroll.
Would you have any idea how to improve the speed of it?
I investigated a big PNG (slow to load, not as "smooth" as SVG) and Canvas without much success.
The site in question was here. Now it incorporates canvas method.
All the elements on the site are vector-based so it can scale to whatever device there is.
So it seems that all popular browsers render page/scroll much faster when the complicated svg background is applied to an underlying canvas (or img) then if it was applied to the body element itself.
Still looking for suggestions how to make it work faster, but at least now it is usable.
This background is very complicated to render on the fly, so I believe that SVG is not feasible. You will have to consider one of the following solutions:
Use a pre-rendered background (i.e. a png background).
Use a simpler SVG, with less elements. In your current background the browser will have to render each line individually.
In other topics I've found that IE/FF doesn't print background images by default. Now that's a shame, because background images add some possibilities that are very difficult to reproduce with classical <img> tags:
You can align them both horizontally and vertically
You can crop them if they are larger than the target element (which also enables the idea of CSS sprites)
Now, it's not impossible to do, but it will require me to have different HTML layouts for printing and normal page, and the printing layout will be quite overcomplicated (since I'll have to use <table>s to achieve vertical alignment). Also, the benefits of CSS sprites will be lost.
Is there any hope? I gather that #media print doesn't help, but isn't there something else, maybe browser-specific, that would allow one to say: "Yes, this isn't a normal background, it really needs to be there even in print view"?
Not possible. You would have to some how convert your background images to img or use Canvas. Of course using canvas depends on which IE you supporting.
Its a browser setting which restricts the printing of background images. I think the logic behind it was that the vendors wanted to give the users the option of printing background images and ensure that the web developer could not alter these settings through some sort of script.
As a general rule, background images should be reserved for adding to the page design but aren't essential to understanding the content. Therefore it shouldn't matter if they are missing when the page is printed. If something (such as a product shot) is important, then it should be included as an actual image (which has the added bonus of being more accessible).
Could you look at including the image, then hiding it using CSS and duplicating is as a background image (perhaps dynamically using JS)? That way, you can ensure the image itself shows in your print stylesheet, and you get the benefits that having a background image brings. I've created a very simple example here.