<amp-carousel
layout="fixed-height"
height="426"
type="carousel"
heights="(min-width:957px) 426px, 376px">
<amp-img src="https://dummyimage.com/400x210/ccc/aaa" height="210"
width="400"
sizes="(min-width: 957px) 400px, 210px">
</amp-img>
</amp-carousel>
The code below works as intended i.e. carousel height changes with screen size but error pops up
The attribute 'heights' in tag 'amp-carousel' is disallowed by specified layout 'FIXED_HEIGHT'.
without the fixed-height layout, horizontal scroll is not working as intended.
I tried reducing duplicate code as written in this page to showcase stories.
You can not use "heights" attribute with layout="fixed-height", read it here https://www.ampproject.org/docs/reference/common_attributes#heights
So basically if you want to have responsive height, go with layout="responsive" and set heights attribute. Otherwise if you are going with layout="fixed-height" you have to duplicate the code with different "media" attribute(as seen in the link you have shared). Which works as, if the media condition is satisfied than only that particular tag will come into play otherwise that will be display none.
Related
I am using NextJS and react-pdf/renderer and my tool creates a PDF and I'd like to display it with the PDFViewer component.
The Viewer loads but only takes up a small part of the screen. Whenever I change the 'width' and 'height' attribute with relative values (100%, 100vh), it won't take it. The only way to force it, is to put specific pixel values in it, but that defeats the purpose of being responsive to the screen size.
Sandbox that reproduces my issue: https://stackblitz.com/edit/nextjs-su5bi1?file=pages/index.js
Does anyone have an idea why this is happening?
Here is your screen with a red block of pixels of 150 pels high, note how it matches exactly your frame height.
Generally you ONLY set frame height in pixel units (The cross browser default minimum is 150?) you probably need somewhere to set a style defining the height as a different number of pixels.
see comment 2 in https://stackoverflow.com/a/73201090/10802527
This Stackblitz example opens a simple dialog which contains a radio group in the mat-dialog-content div.
You can see that the dialog-content shows an ugly scrollbar:
This does not happen when other components are used: e.g. input, etc.
Using chrome dev-tools, I can see that the mat-radio-buttons have a height of 20px:
but the mat-radio-group only has a height of 17px:
Is this a bug in angular material components (the example uses version 12.0.4), or is there a simple workaround/css that we can use to get rid of the scrollbar?
I've tried explicitly setting the height on the mat-radio-group, but this has no effect.
Notes:
in production we do of course have many dialogs and some of them are large and need the scrollbars
we need an application wide solution/workaround
simply hiding the scrollbars is not okay: it must remain auto so that the dialog can react to size changes (e.g. user rotates device, some items are shown/hidden dynamically, etc.
For now we came up with a workaround that fixes the issue in all our 30+ dialogs.
The nice thing is that we can apply it in one place, in styles.scss:
.mat-dialog-content {
padding-bottom: 10px !important;
}
We just add a padding to the bottom of the dialog content area and then scrollbars: auto works as expected in all our dialogs (small and large). i.e. when you make the browser window larger/smaller, the scrollbar is automatically shown/hidden.
And it also works when there are multiple mat-radio-groups in one dialog.
The additional padding between the content and bottom dialog-actions is acceptable for our ui.
Stackblitz example with workaround
The reason this happens is due to the ripple effect on the radio button - which takes up additional space and causes the scrollbar to show. See https://github.com/angular/components/issues/20344
There are a number of ways to resolve this, such as using padding or margins on the components or on the dialog content itself like you did. The important thing is that there is enough space added to accommodate the ripple.
I want to make a button in a popup window as Script Lab as follows. Note that, in Script Lab, the width of the button is enough to hold the sentence in one line, even though the popup window is not very wide:
I almost use the same code as ScriptLab:
import { PrimaryButton } from 'office-ui-fabric-react/lib/Button';
... ...
return (
<div style={{ height: '100vh', display: 'flex', flexDirection: 'column'}}>
<PrimaryButton
style={{ margin: 'auto' }}
text="Open link in new window"
// tslint:disable-next-line: jsx-no-lambda
onClick={() => {
window.open(this.props.url);
}}
/>
</div>
);
Here is my result, where the width of the button is proportionnel to the width of the popup window. As a consequence, the sentence needs to be displayed in 2 rows, which is not what I want.
Does anyone know how to amend the code to get the effect like Script Lab?
Edit 1:
I have made a sandbox: https://codesandbox.io/s/relaxed-feather-i6jz6?file=/src/App.js
Now, the problem is, if we Open In New Window and open https://i6jz6.csb.app/ in a new browser tab several times, we may see a little adjustment of the font of the text in the button. Does anyone know how to avoid that?
On button width:
In order to not have the width of the button grow proportionately with the container you can enforce the width: auto on the button. This way it will only be as wide as it needs to be to contain the text. Value auto is also better than having a fixed width, because it can automatically wrap the text if the popup becomes too narrow to display the text in one line (with fixed width your button would overflow instead - which looks really bad).
On font adjustments
For the font adjustments you experience - this is a very common thing on web and it even has its own name - FOUT (Flash of Unstyled Text). It happens when you use custom fonts on the page, because these are files like any other and so they take some time to download. Browsers prefer displaying the content as early as possible (even without custom fonts loaded) to displaying the perfect content (by waiting on all resources) with some speed penalty.
The only way (at least that I know) to completely avoid FOUT is to use system fonts instead of custom fonts (github does that for example).
If that's not an option, you can minimize the FOUT by caching the fonts on client machines for long times. This way they will experience the flash briefly on the first visit, but not on subsequent ones.
You can also try to minimize the FOUT by telling the browser to try to preload the font files that will be needed for the page (part of the reason why FOUT happens is that browser discovers the fonts very late) https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content
Set a fixed width to the button.Setting a fixed width will make it unproportional to the width of the pop-up window.
width:280px;
Second Option: If you use min-width, the button width will decrease to a point.
Third Option: If you use max-width, the button width will increase upto a point.
Fourth Option: You can also use '#media' queries to customize the width according to size of the screen.
You don't want the button's text to wrap, so you'll need to change the font size, which you can do when you find that the button's height increases when the text wraps. I suggest that you create a invisible, but not 'display: none', possibly 'off-screen' version of the button so that the real button's font is changed after you know the right size is needed. Alternatively, what about an image or glyph instead of text, and a Title for the button text?
I have an ActionScript project set up using the Flash Builder IDE. Using the Flex 4 compiler to compile it. At the top of my application class, I have:
[SWF(width="100%", height="100%")]
public class MediaPlayer extends MovieClip {
This is not acceptable to the compiler to do a release (it throws errors saying it can't parse the width/height values). Pretty annoying. I've tried to do things the "right" way, but none of the following work:
[SWF(percentWidth="100%", percentHeight="100%")]
[SWF(percentWidth="100", percentWidth="100")]
[SWF(widthPercent="100%", heightPercent="100%")]
[SWF(widthPercent="100", heightPercent="100")]
When I use any of those, the stageHeight is 375 (the Flex default) and stageWidth is 500 (default). What is the proper way to do this?
My flash files are being embedded on the web, and I just need the width and height attributes defining the bounds of the flash content to be respected by the SWF.
UPDATE
To give a little more context, I don't have control over how this SWF is embedded - it is handled by Facebook code for their in-stream media content.
<div id="u162171_43" style="width:398px;height:259px">
<iframe width="398" height="259" frameborder="0" src="https://s-static.ak.facebook.com/common/referer_frame.php">
<body style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">
<embed type="application/x-shockwave-flash" src="http://www.rootmusicd.com/flash/fb/rm_player.swf?v=140&d=www.rootmusicd.com&id=102199429820702" width="398" height="259" style="" id="swf_u187610_44" name="swf_u187610_44" bgcolor="#FFFFFF" quality="high" scale="scale" allowfullscreen="true" allowscriptaccess="never" salign="tl" wmode="opaque" flashvars="bridge_connection_id=_conn_4d9b46f8c10ea6089493440&payer_connection_id=_payer_4d9b46f8c10f64d23500210&width=398&height=259">
</body>
</iframe>
</div>
So the width and height attributes are being explicitly set to numbers here. I don't know much about the 'scale' attribute; maybe it is coming in to play here? And, to be clear: it will work as expected if I set the [SWF] meta tag to have width "100%" and height "100%"... so it seems like it actually is preferring the compiled arguments over the browser environment. Perhaps there are other settings I am missing?
Short answer: set the size you want in the web page where you embed the SWF, rather than in the AS source.
Full answer: As metadata, the width and height that get compiled into a SWF are essentially suggestions. When the SWF is displayed, its size is wholly decided by its container, so the only time the metadata gets honored is if the container chooses to read and honor it. Generally, they only container that does that is the standalone player - thus if you double-click the SWF it should launch at the size you specified in the source. But when you display the SWF embedded in a web page, the width/height metadata gets ignored entirely, and the SWF's size is determined similarly to all the other elements in your page (by the embedding HTML, CSS, and so on).
That's all slightly beside the question of why the metadata doesn't take percentages, but hopefully it makes more sense in this context... and since the metadata doesn't affect what happens in a browser, it's a bit academic. I can't answer for how percentWidth etc. fit into things, as it doesn't seem to be documented, but I assume that setting those values doesn't affect the SWF's size in a browser either (unless of course FlashBuilder is generating HTML based on the metadata, or something fancy like that - I'm not too up on FB).
Update
I think I see your problem here. We need to back up a bit and talk about scaling. Any time the size of a SWF differs from the size of its viewport (i.e. the size allotted to Flash by its container), Flash makes a decision about how to scale the content, depending on the stageScaleMode. The details of the four scale options are described in that link, but basically the content is left unscaled, or it's scaled up or down in such a way as to preserve, or not preserve, aspect ratio.
However, in order for Flash to know whether/how to scale the content, the content must have an "intrinsic" size. The height/width metadata we've been talking about is used as that size. So if your HTML container is 200x400 and you use the "exact fit" scalemode, then if your metadata describes a size of 100x200 your content will display at double size, and if your metadata said 400x800, the SWF will show up at half size. If you use the "no scale" scalemode, then your metadata will not affect the content's scaling. (Content still gets aligned within the container according to stageAlign.)
Taking the previous into account, I hope it will be clear that the "correct" value to use for your size metadata depends on what kind of scaling you use and how your content will adapt (or not adapt) to different sized containers. If your content is laid out statically within a 259x398 area, then 259x398 is the proper metadata size to use. That way, if you were to view it in a larger container, your content would be scaled up as one would expect, depending on scale mode. However, if your content dynamically adjusts to variably-sized containers, and automatically lays out its content at runtime, then you almost certainly need to use "no scale" mode - in which case it doesn't matter very much what size metadata you use, so the flex default size should work fine.
Incidentally, scale mode can be defined in the HTML embed parameters, but you can also override that setting at runtime. So work out what scale mode meets your needs, and set that mode before your content initializes, and then you should be able to find a metadata size that works.
Set your SWF tag to the proper aspect ratio in pixels and then use 100% as your width and height in the embed code on your page
swfobject.embedSWF('foo.swf', 'bar', '100%', '100%', '9');
I've got HTML component as part of a datagroup itemrenderer which I need to resize the content of (there are lots of them).
This works quite well but the content looks really crusty. No font antialiasing. Even at 50% looks crusty.
I've considered generating thumbnails bitmaps on load 'complete', but that would be my last resort.
<mx:HTML location="{uri}" width="900" height="660" scaleX=".25" scaleY=".25" />
Any ideas?
Thanks a lot.
nic
I think the problem is with the HTML page. If you've designed the page, make sure that you have tested the page on various sizes (by resizing). Flex's mx:HTML simply renders what is in the HTML page.
A good HTML design includes ordering all page elements inside a table (with invisible borders) so that even when the page is resized, the elements won't get crusty.
Thanks,
Nirmal
The solution is to reduce size by changing width and height of mx:HTML and keep scaleX and scaleY equal to 1 (even if you parent has scale < 1, then your mx:HTML shall have scale = 1/parent.scale).
In your example it will be like that:
<mx:HTML location="{uri}" width="{900*0.25}" height="{660*0.25}" scaleX="1" scaleY="1" />