Develop Reference

Page breaks in SAPUI5

What is the best practice for creating specific page breaks in SAPUI5 and is it actually possible?
Classical CSS atributes page-break-after and page-break-beforedoesn't seem to work in my case. For example, I have two sap.m.VBox elements and I attached them a CSS class which specifies page-break-after: always !important;when printing, but nothing happens. If I add
* {overflow-x: visible !important; overflow-y: visible !important;} then it will break and continue to draw the content in next page if it doesn't fit in one page, but it doesn't work in IE.
I have tryed also adding an empty div element that would work as a page break indicator, but still CSS wouldn't do anything. I guess that's because everything in SAPUI5 is put into one content div.

You can solve this by adding an empty element in between.
If you want a break that is 200 pixels high, your page content can look like this:
return new sap.m.Page({
content:[
oVBox1,
sap.m.Panel({height: "200px", width: "100%}),
oVBox2
]
});
ofcourse you might want to set your panel background-color to transparent ;)

The "page-break-after" is ignored because the property display of SAPUI5 views is set to inline-block.
Simply override the CSS style for the corresponding class with a custom CSS and it should work:
.sapUiView {
display: block;
}

visibility:hidden vs display:none vs opacity:0

I'm currently starting on an animation project. In the project I'll have more than 40000 divs and animate them iteratively. If any of divs are in passive state (i.e. it's not animating at least for 2 seconds), I won't display them to increase animation performance.
The question is: which css property is the most suitable for this?
.passive1{
display:none
}
.passive2{
visibility:hidden;
}
.passive3{
opacity:0;
}
And how can I measure rendering performance like fps, gpu usage?

While all 3 properties make an element's box seem invisible, there are crucial differences between them:
Property
Painted
In layout
Stacking context
Pointer events
Keyboard events
opacity: 0;
No
Yes
New
Yes
Yes
visibility: hidden;
No
Yes
Varies
No
No
display: none;
No
No
Varies
No
No
The "Painted" column indicates if the browser will paint the element's background (e.g. background-image), #text content, and so on.
An element cannot be painted without also participating in the page's layout, of course.
This is No for all 3 properties and values, as the browser won't need to paint the element's box as it's invisible.
The "In layout" column indicates if the browser will compute the layout and dimensions of the element - along with any of its descendants not excluded from layout.
This is only No for display: none;, as with opacity: 0; and visibility: hidden; the browser will still determine the size of the element so it can correctly layout other elements relative to the current element (e.g. if you have span.hidden { visibility: hidden; display: inline; }).
The "Stacking context" column indicates that any use of opacity (except opacity: 1.0;) will create a new stacking-context, which complicates use of the position property.
The "Pointer events" column indicates if the element will respond to user-interaction from a pointing device, such as a mouse, touch-screen, stylus, etc.
e.g. with visibility: hidden; then the :hover state won't work, and clicking the same element won't apply :focus or :active either.
Additionally, the DOM won't raise any pointer events you'd handle in JavaScript (e.g. visibility: hidden; won't raise mouseclick, touchstart, etc - note that the click event can still be raised by certain elements, like <button> if invoked by the user using a non-pointer input method, such as with keyboard or voice (accessible) navigation means.
You can use pointer-events: none; to block pointer events, but this won't block keyboard and other non-pointer input and so should not be used to disable an element because the user can still use the keyboard to interact with it (especially <button>, <input />, <select>, and <textarea>).
The "Keyboard events" column indicates if the element can be interacted-with using keyboard navigation (and possibly other navigation means).
This includes smart-device (smartphones' and tablets') browsers' "Prev/Next Field" buttons for navigating <form> elements (as this uses tabindex).
Unlike how pointer-events can be disabled in CSS using pointer-events: none;, there is no CSS property to disable keyboard interaction.
This table shows a more complete comparison between the main values of those 3 properties:
Property
Painted
In layout
Stacking context
Pointer events
Keyboard events
Animatable
Opacity
opacity: 0;
No
Yes
New
Yes
Yes
Yes
opacity: 0.1;
Yes
Yes
New
Yes
Yes
Yes
opacity: 0.9;
Yes
Yes
New
Yes
Yes
Yes
opacity: 1;
Yes
Yes
Varies
Yes
Yes
Yes
Visibility
visibility: hidden;
No
Yes
Varies
No
No
Yes, with caveats
visibility: visible;
Yes
Yes
Varies
Yes
Yes
Yes, with caveats
Display
display: none;
No
No
Varies
No
No
No
display: contents;
Text and children only
Text and children only
Varies
Yes
Yes
No
Other
pointer-events: none;
N/A
N/A
N/A
No
Yes
No
The "Animatable" column indicates if that property can be used with a CSS transition (transition:) or CSS animation (#keyframes).
Crucially, the display: property cannot be animated, which is why we can't use a #keyframes timeline to completely hide an element after the animation is complete.
But curiously, we can animate the visibility: property despite being non-continuous, albeit with caveats.
Also, don't get confused by the similarly-named backface-visibility and content-visibility properties.
backface-visibility is only applicable to 3D transform operations.
content-visibility is an optimization to speed-up page rendering during initial page-load, but requires CSS Containment first, which is out-of-scope for this QA.

The answer found here will answer your first question (most likely display:none as the space is collapsed completely).
To your second question, tools such as this will probably be useful for you. However 40,000 divs sounds like way too many and you will probably have better performance using canvas or SVG (for example, using the KineticJS library as this handles animations - transformation, rotation, scale, etc.) for you.

display:none will hide the whole element and remove that from layout space whereas visibility:hidden hides an element but take up the same space as before.
Opacity can be used if you want to create transparency or fade effect.

Performance will be an issue if display:none or visibility:hidden is used since they trigger paint and layout in most browsers which means your browser will redraw the viewport whenever those two changes so I will recommend opacity but still for that number of divs it will still be not performant as expected you can try webgl using a library called html-gl which render your divs in webgl check https://github.com/PixelsCommander/HTML-GL

Here is a compilation of verified information from the various answers.
Each of these CSS properties is in fact unique. In addition to rendering an element not visible, they have the following additional effect(s):
Collapses the space that the element would normally occupy
Responds to events (e.g., click, keypress)
Participates in the taborder
collapse events taborder
opacity: 0 No Yes Yes
visibility: hidden No No No
visibility: collapse * No No
display: none Yes No No
* Yes inside a table element, otherwise No.
got from link

display:none because the divs are taken out of the flow then, thus their position does not have to be calculated.
That being said, 40000 divs sounds crazy. Did you consider the alternatives like HTML5 canvas or SVG?

Sometime i use visibility and opacity together to achieve effect to avoid click event
e.g.
normal state/element removed from screen:
visibility:hidden;
opacity:0;
transition: all .3s;
hover state/element on screen:
visibility:visible;
opacity:1;

Found this thread whilst investigating a hover: bug in Safari mobile
Confirming that opacity: 0 is a valid approach (it is in my case, thanks all). opacity: 0 fixes it enough to be workable (still requires an annoying js redraw on screen rotate [width change]).
Background info on the bug I fixed with opacity: 0:
The hover is on a li containing a div that is revealed when hovering (or single touch on mobile) a calendar entry. Really random working/not working in Safari mobile - and even weirder the behavior changes on a screen rotate++ [nb no media queries involved so not that].
So annoying as otherwise works in all other browsers I've tried.

Get rid of useless scroll bars on fancybox iframe

I have some content I want to show in iframe with fancybox. When I use it, it pops up with horizontal and vertical scroll bars even though all the content is inside of it. Inspecting it in Firefox shows that when I click on html everything is inside but there is a little left over that is outside of the highlighted box. The next level up is iframe.fancybox-iframe which includes the scroll bars. I looked at the css and that has padding and margins set to zero so I don't know why the scroll bars are there. Right now as far as options I just have autoSize:false. All I have inside the body of the page I want to show is a form.

If anyone wonders which class name to use
.fancybox-inner {
overflow: hidden !important;
}
And if you found a small white background you can reset it using
.fancybox-skin {
background: inherit;
}

Try adding this to the css:
.style{
overflow: hidden;
}
If it didn't help, please post your HTML and CSS.

jQuery: How do I scroll the body without showing the scroll bar?

I'm trying to hide the scroll bar of the document (in some browsers it's the body element, in others it's the html element) by using overflow:hidden;. Then i'm using jQuery.animate() to try and animate the scrollTop property. It works fine when the scroll bar is visible (i.e. without the overflow:hidden; style) but doesn't work when the scroll bar is hidden. Why is that? I'll be able to post a link to a snapshot of the problematic page in a bit...

Try make <body> overflow:hidden and animate the margin-top property, note the margin-top should be negative if you want a positive scrollTop.
On webkit you could use ::-webkit-scrollbar: { display: none; } to hide the scrollbar with scroll features enabled.

Content jumps horizontally whenever browser adds a scrollbar

I'm using a fixed width body and auto margins to center my content in the middle of the page. When the content exceeds the page's height and the browser adds a scrollbar, the auto margins force the content to jump half the width of the scrollbar left.
Is comparing outerHeight with window.innerHeight an appropriate way of solving this? Is there another way to solve this?
I think this should be enough info for the problem, but let me know if I can answer anything else.
Edit for clarification: I don't want to force the scrollbar to appear.

I'll just leave this link here because it seems an elegant solution to me:
https://aykevl.nl/2014/09/fix-jumping-scrollbar
What he does is add this css:
#media screen and (min-width: 960px) {
html {
margin-left: calc(100vw - 100%);
margin-right: 0;
}
}
This will move the content to the left just the size of the scrollbar, so when it appears the content is already moved. This works for centered content with overflow: auto; applied to the html tag. The media query disables this for mobile phones, as its very obvious the difference in margin widths.
You can see an example here:
http://codepen.io/anon/pen/NPgbKP

I've run into this problem myself and I've found two ways to solve it:
Always force the scrollbar to be present:
body { overflow-y: scroll; } Setting it on the html doesn't work in all browsers or might give double scroll bars if the scrollbar does appear.
Add a class that adds ~30 pixels to the right margin of your page if there is no scrollbar.
I've chosen option 1 but I'm not sure if it works in all browsers (especially the older ones).
Facebook uses option 2.

Use this CSS:
body { overflow-y: scroll; }

You can force the scrollbar to always appear:
http://www.mediacollege.com/internet/css/scroll-always.html

The process is :
html {
overflow-y: scroll !important;
}
This will show the scrollbar even there no need any scroll bar.

Best possible way through CSS, It will show/hide Scrollbar accordingly, will
solve jump problem, works on every browser
html {
overflow: hidden;
}
body {
overflow-y: auto;
-webkit-overflow-scrolling:touch;
}

For me, the solution was to add this rule to the body:
body {
overflow-anchor: none;
}
This rule was added recently, and aims to reduce the variability of browsers having different default assumptions about how they should react to overflowing. Chrome, for example, has overflow anchoring enabled by default, whereas Firefox does not. Setting this property will force both browsers to behave the same way.
https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-anchor