So I've got this sidescroll constrained by height (say, 50vh). This works fine
Now comes the hard part, when the content is less wide than the browser I would like the images to be centered! Is this possible?
If I use justify-content:center I get this weird behaviour where a part of the first image is outside the viewport - and I don't know why that happens, but it happens in both FF and Brave, so at least it's consistent.
This only happens when the content is wider than the browser. If the content is less wide than the browser it actually centers it fine, but the overflowing mechanism is a bit ..wierd?
Related
I am experiencing two weird things happening with svg rendered in safari (works fine in Chrome/Edge/FF and heck even IE)
Lines not defined in SVG will appear and disappear randomly when panning around.
Lines defined in SVG might disappear randomly when panning around.
Not really that easy to describe so I made a video for it
https://youtu.be/BqlItab0k_g
I did not use any fancy SVG feature like script or media query. The only elements used are text/path/rectangle.
The SVG is generated by me and optimized using SVGO
[Codepen](https://codepen.io/alt22247/pen/vwzBmL)
The svg is base64 encoded since I can't upload svg to code pen. Had to use code pen instead of SO built in since the base64 encoded img text exceed SO limit. Feel free to decode it back to text.
I can't think of any way to mess up the SVG without causing a parse error so I believe this is a Safari bug. But we need to support Safari regardless (typical life of a web dev).
So the question is: What is causing this and is there any work around I can do rather than wait for Apple to fix it 10 years later?
I am really stressed out with this, i have built an entire designer with Fabricjs, gone through some right hoops with the text to make it work how it's needed. The problem is now when the data from the canvas is sent to the server for a full resolution render with NodeJs (fabricjs in node) the fonts are coming out looking different to they do in the browser.
All the fonts are installed on the server, and the correct font does render, it just seems to have different spacing between the characters even though the fabric version is the same and all the extension code is the same on browser and server side, all the TTF fonts are the same etc etc
Here is the browser version:
And here is the node js version:
As you can see the font is correct on the node one compared to the browser one, but it's being rendered slightly differently.
Is there a solution anyone knows of to fix this?
I don't believe that there is any way to solve this problem when using fabric.js
Text in fabric.js can be scaled arbitrarily, but then it is rasterized and displayed as a canvas object like any other image.
You can see in the fabric.js demos that the text will stretch like an image until your input is complete, then it re-renders to a new image at that scale.
Knowing that this is how fabric.js handles text, it is possible to select two scales that produce quite different results:
In the image above you can see that the two fonts are pretty much the same size, but the one on the right (slightly larger) has been rasterized such that it appears to have a bolder appearance. It's the best example I could reproduce with limited time.
This is why rendering the fabric.js objects in your browser at a smaller resolution than the server will lead to the font appearing slightly different.
If you try rendering the browser version at the same size as the server you are likely going to get the same results.
The scroll of the list is going crazy when I scroll and it keeps jittering afterwards even if I don't do anything) as you can see here: https://imgur.com/SdgMf7f (sorry embedding that gif doesn't work here)
I made a minimal example where it happens in:
https://codesandbox.io/s/4r2q3omv1w
I did pass the style to the rows.
Also, if you change the height and width of the list to get the values from Autosizer, then the list doesn't appear, even though this looks exactly like in the example.
Any ideas how to fix these two problems?
EDIT: it seems that it works a little better in Firefox, still a little jumpy in my own code though and the codesandbox's scroll still isn't perfect. (it's super jumpy in chrome, even in incognito).
It seems the problem was related to 2 issues:
Not delegating height and width from <AutoSizer> to the <List>
Row height was defined as 50 but the actual rendered height was more -
From the docs: Note that it is very important that rows do not have vertical overflow. It would make scrolling the list difficult (as individual items will intercept the scroll events)
Here's a working example: https://codesandbox.io/s/jppm1mmo83
I don't know if I'm misunderstanding something fundamental in how screen resolutions work, but I'm getting stuck on an issue with the Kindle Fire HD (7").
I have a responsively designed page that, as normal, uses CSS media queries to change the presentation of certain elements. This works as expected on all browsers and devices tested, except for when browsing with the Kindle Fire HD (7"). According to specs (http://en.wikipedia.org/wiki/Kindle_Fire_HD) it has a screen resolution of 1280 x 800 px. This is also verified when I check the device using WURFL's test tool at tools.scientiamobile.com.
So... I have breakpoint screen widths set for
'mobile' - 767px and below
'tablet' - 768 - 989 px
'desktop' - 990px and above
... so I'd expect the Kindle Fire to display my page in 'tablet' mode in portrait orientation, or 'desktop' mode in landscape. However instead it shows it in unexpectedly smaller breakpoints: 'mobile' mode in portrait, and 'tablet' mode in landscape.
On closer inspection, I'm not sure this is actually much to do with my webpage, or its CSS. When using this device, I also seem to be seeing 'smaller' breakpoint views of other RWD sites (e.g. in portrait mode, I get the 'tiny' breakpoint view of getbootstrap.com, which is aimed at 767px and below).
What's then strange is that, when detecting the screen size using JavaScript, I get 534 x 854px (and have also tested this again on other sites, like supportdetails.com, and got the same results).
I haven't found any similar issues reported re this device, so I'm wondering a) if anyone's encountered similar issues, or b) if I'm just misunderstanding something crucial with how screen resolutions are detected by different devices.
Thanks!
When doing media queries you need to take into account the CSS pixel ratio.
The value you need to use on the media query = (The Advertised number of pixels) / (CSS Pixel Ratio).
This wikipedia page is a good source of CSS pixel ratios to use for this:
http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density
Good Luck
So I have two images set to fill the screen - one at 320x480 (iPhone 3) and the other at 640x960 (iPhone 4).
img.png (320x480)
img#2x.png (640x960)
In Interface Builder, I have img.png set to fill the view (it shouldn't be filling the iPhone 4 view, though, right?), and when I build and run, it is notably too small.
So, when I do the opposite, setting img#2x.png as the img, a giant blue question mark fills the view. The project still builds and the image fills the screen, but is very pixelated as if it has been rescaled. It shouldn't have been rescaled, though, as it is the higher resolution.
Now using...
img.png (640x960)
img#2x.png (320x480)
I've also tried switching which file takes the #2x suffix, but that has not helped either. With the smaller file taking the #2x suffix, and setting the image view to img.png, it shows up way larger than the view canvas, but way too small when on the phone. With the smaller file still having the #2x suffix, I tried switching the view to the new img#2x.png and once again got the oversized, pixelated question mark in IB and a low res full-screen image when deployed to the phone.
I also made sure that my view size was set to 640x960 in the size inspector. What else should I be doing?
Don't use #2x when specifying the image name. Just use the base name of the image (so in your case, just img). iOS will do the magic behind the scenes to use the 2x version if it's on a retina display and the regular version otherwise (including when you use a xib to lay out your interface).
The displayed dimensions of the image will always be the dimensions of the non-2x image. The retina display just displays 2 pixels for every 1 which is why the scale is 2.0 and you have to double the dimensions of the original image. So your view size in IB should be 320x480.
Edit
If IB is being finicky, especially in Xcode 4, just try deleting the xib and starting over. Sometimes it gets a bit corrupted and doesn't know what to do with itself. I've had to do this on one or two occasions, and it seems that it worked for the OP as well.