I'm new to CSS, jQuery etc. I have created a page and I need some guidance.
Currently I am using the metadata viewport tag with a fixed width (since my page is a fixed width at all times) and a initial-scale of 1.
This works very well once you have zoomed out - on all devices. The page renders at the correct scale, everything is great and you can zoom in and back out, and the page stays the same.
The problem is the INITIAL zoom level. When "Initial scale" is set to 1, it will zoom in way too much on phones, which is disturbing to first-time-viewers.
Is there a way to just tell whatever device that is viewing the page, that it should just zoom out as much as the viewport allows it? Like you would do with you fingers as it is right now. Just zoom all the way out and everything is fine... There must be some simple way to accomplish this? I've searched the net as much as I can, and all the solutions I have found either don't work or are really complicated, which seems unnecessary to me!
Thanks in advance
Turns out, the entire thing was because I had used a comma (,), instead of semicolon (;), to seperate my arguments in the metatag. This caused my first argument, which was width:810px, [next argument] to become invalid, cause the comma was attached to 810px. As soon as I replaced it with a semicolon, everything worked!
Related
This question is related to this other one (Android). A sample test case was also provided here
Basically, I can get past the "glitch" of losing the bottom screen under the keyboard that occurs sometimes when a single line TextField is focused by setting the TextField's bottom padding and making it a layer
But when the same glitch occurs to a multi-line TextField, each time the cursor is moved to a different line the keyboard follows the current line and hides everything underneath. I've been looking at TextArea and Component but I can't see anything there that stops this behavior. My "trick" of making the TextField a layer with bottom padding doesn't work in multi-line mode. I'm out of options, could this be enabled or alternatively is there some magic method somewhere I am missing?
Also, I've checked that calling getComponentForm().getInvisibleAreaUnderVKB() returns 0 when the glitch occurs
I think you need to re-open the applicable issue. This code is very platform specific as the virtual keyboard behavior is handled 100% within the Android port.
Android doesn't implement getInvisibleAreaUnderVKB() since the VKB doesn't work that way in Android. It resizes the screen instead to provide the additional space. It will generally try to get the top area where your cursor is. That's the chief goal.
When the screen is empty that might look problematic but when your screen is full of data we'd rather see the data than have the full text component in view. Unfortunately, the native editing code has no way to distinguish between the two cases. We might be able to come up with a workaround but with these things there are often issues/regressions.
Solution to prevent this consists in setting the Form's setFormBottomPaddingEditingMode(true);. Easy fix! 👍
I am working on a page where there are two rows in the header.
The first row has a "My Account" icon, Company Logo, and Logout.
The second row has a navigation bar.
When the Focus Ring/Focus Indicator highlights an item on the first row, the bottom of the focus ring is cut off by the navigation bar in the second row.
I am not allowed to change the spacing of the elements on the DOM.
Is there a way I can change the layering so that all of the elements on the page are not changed in size or location, but the Focus Ring is not cut off by the navigation bar?
The site built with React.
I've tried googling a number of things, but haven't turned up much specific to this issue.
I'm a little new to programming (my first job, first year). I'm not totally sure where to even start.
You are looking for z-index. The second element is positioned in front of the first element and so it covers the focus indicator.
This allows you to specify how far 'forward' elements are on the page.
Assuming nothing is using fixed or absolute position within the <div>s you are working on this should solve your issue.
i.e.
<div class="container">
<div id="behind" z-index="1"></div>
<div id="infront" z-index="0"></div> <!--The z-index is not really needed here so try without it first, it is to illustrate that the item in front at the moment should have a lower z-index than the one at the back-->
</div>
You may need to play with the z-index in order to get this to work (you can go to 999999 without a problem, but try and use as low a number as possible).
You may also have to fiddle with heights of elements if the site is poorly designed but without a code example I can only offer general advice and gotcha's
Without a code example it is difficult to suggest a solution, but it sounds like your two rows are overlapping, and thereby hiding part of the focus indicator.
Three different solutions come to mind,
Change the height and placement of the two rows to avoid the overlap in the first place
Try using the CSS z-index property to control which element is rendered foremost
Using the CSS outline-offset property, with a negative value, i.e. -5px, to shrink the focus indicator and hopefully making it visible
Can you please explain me what is the difference of the two options "scrollable" and "zoom" of the Simulator? I've done some trials and they seems to act equally.
Zoom used to have a different meaning. Right now it maps to disabling/enabling scrolling and sizing the window to a reasonable size.
We kept the menu option in place since people are used to that and Scrollable isn't an intuitive name.
I'm having an issue with CellMeasurer in conjunction with scrollToIndex on a List. If I set scrollToIndex to some large value (presumably any index corresponding to a row preceded by rows that haven't been measured yet), and then I scroll upwards, the scroll seems to reset back to it's original position repeatedly. Eventually it starts resetting higher and higher up, until eventually I've made my way back to the start of the list.
Relevant Plunker--it's a list with 300 elements (all the same static height so CellMeasurer isn't necessary but it illustrates my problem), and I set scrollToIndex to 150. Try scrolling upward.
https://plnkr.co/edit/XPF5D88WI9CErhkmrgAy?p=preview
Understandably the scroll might not be perfectly smooth since the calculations are based on predicted heights and they're not always going to be correct (in practice at least--in this case they will be correct), but this seems particularly bad/unintended. I suspect (and hope) that I'm doing something incorrectly here--would appreciate any thoughts. Thanks.
EDIT:
On my MBP this happens in both Chrome and Firefox, though it looks slightly different depending on which browser I'm using. On Windows, using Chrome, there is some weird flashing of different rows while scrolling up, but it doesn't seem to reset back to 150 at least.
EDIT:
Here's a gif of the issue occurring - this is on Chrome 60.0.3112.113, Mac OS Sierra 10.12.6:
Seems to be a bug, filed here: https://github.com/bvaughn/react-virtualized/issues/803.
Since it's a bit difficult to explain, I did a mockup to get across as much as possible visually:
http://sassmeister.com/gist/70624a740b1ca4ae7764
(If there's a better way to share a sass gist, let me know. First time using it)
Basically, this is the layout I want for a tablet in landscape mode. What I'm trying to do is make sure it fits perfectly on different tablets with different aspect ratios. Some things are fixed. The main content area is a 16x9 video, so that aspect is locked.
I have the header and footer (main column only) fixed right now as they need to be for portrait mode, but I could bring them into the regular flow if it's helpful for tablet landscape. Anyway, it's all basic responsive right now via susy2, and the sidebar is totally separate so it can scroll independent of the main content. What I would like is for the whole main area including header and footer to fit perfectly with even margins above and below vid, but then have the sidebar column change it's width to match the tablet.
So... if the tablet is wider, the teaser thumbnails go out to 16x9 ratio. If the tablet is narrower, the main column remains unchanged, but the teaser thumbs narrow down to squares.
If it's easier first to just figure out how to responsively shrink the right column only, so the aspect of thumbs is unchanged, that's ok. I just don't want the overall layout to get screwed up on one device vs another because of aspect ratio, so main focus is that the header hits top, footer hits bottom, main vid fits perfectly between them, then sidebar responds to fill in the rest (within reason).
thx for any input. First time making a website here, so lots to learn.
ps. I had vertical scroll enabled for the right column, but disabled it (by adding extra letter to to the scrolling class in scss column) since it's not actually letting me scroll. Not sure if that's because there's no actual content, or it doesn't recognize the empty padded cells as something worthy of scrolling.
You're biting off a lot for your first website, but Sassmeister is a great way to show what you are doing. I approve. :)
One of the problems you'll find is that CSS don't have the concept of aspect ratio built in, so the sort of layout you are attempting is non-trivial. CSS is best at handling widths, and letting everything overflow vertically. It takes some effort to make it handle height well.
If you can get away with it (depending on browser support), your best option is to use flexbox. Flexbox should make this much easier, but doesn't ave a lot of support yet. You could consider table-cells, which have more support, but can be harder to control.
In any case, you should ignore most of Susy for this — at least in laying out the large sections. If you want Susy to help you with grid calculations, ditch the mixins and just use the span() and gutter() functions to help you set widths. Something like this:
.flexbox {
flex: 1;
flex-basis: span(3);
}
.tables {
display: table-cell;
width: span(3);
}
// NOT THIS
.no {
#include span(3);
}
You can go back to using Susy mixins for simpler bits, like the items in the top navigation.