Not that I want to promote buydomains.com (actually I despise their business model) but need to show it to illustrate my question, sorry.
I came across this website on which when you resize your browser window's width up/down, the elements' get slowly resized up/down (I'm guessing via JavaScript), until they seem to fit in an optimum way:.
For instance, resizing up the browser width, you can see that the "Researchhighlights" search box's width progressively reduces until the below elements fit on the same line:
I'm used to CSS responsive design where elements are resized and re-arranged instantly when certain break points are reached, so I'm wondering whether this method is an alternative to CSS responsive design (and if so what the pros/cons are) by letting JavaScript figure out the optimum elements' width.
Is there a technical reason behind this implementation?*
**since JavaScript has the capability of doing such processing instantly the fact that elements are re-sized slowly definitely seems to be some sort of aesthetic decision (otherwise why make people wait if you can do things faster), however there might still be some technical reason behind it.*
First of all, the same effects can be achieved using CSS, so this is not a JavaScript vs. CSS-based responsive design situation.
The decision to slow down the transitions is purely a design decision - there are no technical limitations on doing it instantly.
In my opinion (and experience), slow transitions are more annoying than aesthetically pleasing, especially on a "utility" website. Also, a screen resize event is relatively rare - most users do not resize a screen during their visit. When users do resize it (for example, by turning a tablet), they expect an instantaneous adjustment. I see no reason not to meet their expectations.
Related
I'm only just getting my head around how to build a responsive design site and in addition to a changing layout, I've also been tasked with functionality which should be responsive at various sizes. For example, on desktop, a link might not exist on a particular element, but then at mobile size, it should not only exist but it should also do something it didn't do at larger sizes.
I can understand using media queries to change the size or position of any particular element in CSS, but how does one go about changing functionality (i.e. JS & HTML) at various breakpoints?
(I'm not sure if the term exists or not, but for lack of a better name I'm going to call it responsive functionality.)
You're describing the difference between responsive design and adaptive design.
Responsive layouts respond to different screen sizes (using flexible
grids and media queries). They will often hide content or apply
different CSS rules on smaller screens.
Adaptive layouts adapt to different screen sizes and/or devices by taking a premeditated approach and optimizing the content that is served to the user.
For example, a responsive design might simply hide a sidebar on smaller resolutions while an adaptive design might show content specific to mobile devices (because the website knows the user is on a phone).
There are some good blog posts on the topic:
The biggest similarity between the two methods is that they both allow
websites to be viewed in mobile devices and various screen sizes,
ultimately providing visitors with a better mobile user experience.
Where the two methods differ is in their delivery of the
responsive/adaptive structures: RWD relying on flexible and fluid
grids, and AWD relying on predefined screen sizes. One of the main
distinctions between the two is that RWD might take more code and
implementation strategies with the fluid grids, CSS, and flexible
foundations, while AWD has a streamlined, layered approach, which
utilizes scripting to assist with adapting to various devices and
screen sizes.
Responsive functionality could be achieved a couple different ways:
You could use media queries to hide and show different segments of HTML that have different behaviors tied to them.
You can trigger your behavior with javascript where the javascript in the event handler examines the size/platform and decides what behavior to call.
You could dynamically generate different portions of HTML and their corresponding event handlers with javascript based on the size.
I've been working on a slideshow script that uses CSS3 transitions, or jQuery's animate when they are unavailable. I've created a custom function to do the slide animations, which does so appropriately. Everything seemed to be working fine, but I've hit a major snag during testing.
For one reason or another, there is an large delay applying the jQuery CSS before and after the transition on large slideshows. For example, the slideshow in the link below is around 9900 pixels wide (container width, most of which is hidden). The container is maneuvered to display the appropriate slide, using CSS3 transition and transform properties. The delay occurs applying the CSS between lines 75 - 82 in the paste below. In particular, applying the 'transition' CSS causes the problem. Add the 'transition' CSS to the stylesheet (rather than applying it with JS), and delay disappears. This isn't really a solution however, because we only want to use CSS3 transitions on specific properties, that can vary (using 'all' in the stylesheet would transition some CSS that we don't want to animate, but change regularly).
Animation function:
http://pastebin.com/9wumQvrP
Slideshow Demo:
http://www.matthewruddy.com/demo/?p=2431
The real problem is with iOS, in which the slideshow (and even the browser sometimes) becomes completely un-usable. I can't pinpoint any errors, and have really exhausted my knowledge of debugging JS. I'm sure it is related to this section of the function after playing around a bit, and disabling CSS3 support within the plugin altogether removes the problem completely.
I'm completely stuck, and really appreciate any help anyone can give.
--- Edit ---
I've tried applying the CSS with native Javascript rather than jQuery's .css function. Same results, no better performance. Also worth noting that this isn't happening at all in Firefox, and seems to only be a problem with Webkit browsers.
Anyone with a solution, would happy to make a donation towards a few beers! I really cannot figure this out!
--- Second Edit ---
Ok, so been debugging and I can see that the slowdown is caused by the browser repaint cycle that is taking a very long time. Is there a better way to handle this that the way it is already doing? Positioning the element absolutely is a known way to reduce repaints, but that isn't really working because the slideshow is responsive. Absolutely positioning the slide images or the slides themselves causes it to collapse.
--- Third Edit ---
A day later, and I've made some progress. Adding 'transition: all 0s ease' to the elements stylesheet CSS has gotten rid of the repaint caused by adding the inline CSS transition property via the custom animation function mentioned in the original post. This causes a significant performance gain, especially when removing the inline CSS transition property when the transition itself has finished.
Good stuff! However, now there is still a slowdown when the inline CSS translate is being removed (that was used to create the hardware accelerated transition effect itself) after the transition, and the left positioning is being applied. When the two happen together, there is a slowdown.
Breaking them up into two separate tasks (the translate removed, then the left position added in a setTimeout with no time specified), again gets rid of the repaints = performance gain, and looks likes problem solved. But sometimes, the CSS transition property isn't get negated fast enough, and the translate removal gets animated. No good, and don't know where to look next to work around it.
I think the problem is you're loading HUGE images :)
They are too big for the container you have them in, so you scale them down, which is even more resource intensive.
Try resizing them.
First of all congrats for your debugging!
I have been working on the exact same stuff lately and found out that ios devices don't support a large number of images positionned in the same page. It causes crashes and the only solution I found was removing elements instead of just hiding them. The downside is that removing and appending elements causes lags so you have to do it cleverly, when your transitions are done. I thought the best way to go was keep 3 or 5 images in the DOM and replacing the rest with thumbnails of the images, resized to fit the original. When transitions are done, I'd just put the large images back into place...
Hope this helps you a bit on the ios problem at least...
After spending some time analysing your code TimeLine with Chrome Dev Tools, I believe there's some optimization you could do.
As far as I can tell, every single one of your 16 images gets fully repainted every time an animation is requested. This seems quite obvious to me, as there are 16 images in your example, and the Chrome Dev Tools reports 16 long "Paint" executions every time in hit "Next".
In my humble opinion, you should figure out a solution that considers only translating two images: the one you want to hide and the one you want to show. So, consider please, not moving the rest of the images and, instead, leaving them all side-by-side to the shown image.
One more thing, using scaled down images is probably making the paint cycles quite longer. Avoid them whenever you can.
Well, think I've managed to figure it out! Just so you know, original post links don't reflect the changes as I've done them on my localhost environment.
Absolutely positioning the slides container has fixed the problem that was occurring with repaint speeds after the transition had taken place (whilst applying CSS properties). Obviously taking them out of the DOM has done the trick, allowing painting to take place much more efficiently.
I originally didn't try this too much because I knew this would add a lot of work to the resizing functionality. I had originally intended to not resize at all in JS, and rely on percentages to do the dirty work. Absolutely positioning the container would cause the slideshow viewport to collapse, rendering the native resizing useless.
However, I was already having problems with sub-pixel rendering in other browsers anyway, so I guess it was time to bite the bullet and rely on fixed pixel values. I then used JS to handle the resizing, using the window resize event. All seems good, however the slideshow was still collapsed due to the positioning. Assigning height values wasn't working correctly, so was at a bit of a loss.
Thankfully, I came across a neat little trick of setting the 'padding-top' of the slideshow viewport to a percentage value, dynamically calculated (desired slideshow height, set in the settings panel for this script, divided by desired width). As padding-top percentages are relative to the width of the element, this did a great job of providing responsive height and correcting the viewport again (no longer looking collapsed).
Here is some info on using padding-top for responsive elements that maintain aspect ratio. Great little trick: http://f6design.com/projects/responsive-aspect-ratio/
All is good now, and things are working well in iOS and webkit browsers. Everything is extremely quick and working as it should. Four days later, and it is finally figured out. Not happy about having to resort to JS for resizing, but I guess it was always going to happen due to percentage inconsistencies between browsers. Lots of decimals = no good!
Thanks to all who tried to point me in the right direction. Definitely got me thinking, and learned a lot of debugging skills that I can use again to make sure transitions are performing well. Thanks again!
not sure if this helps or not but I noticed you use 3d translation - I would think a simple 2d translation would be enough especially since your third parameter is 0 and might accelerate the issue, also go with fewer images as Armel L. suggested, don't have an iphone to test though... alternatively, this is a solution I used before css3 but should still work move the element containing the images using javascript by modifying left (?and top - the demo only moves left and right though? without the transition effects) and this way you can fine-tune the refresh rate which I think might account for the slowdown... you can go as low as 18 fps without anyone noticing, might even be good enough with just 16fps
I had this when I was first designing a magazine carousel-style page device.
If you have a series of images within a long "tray", even if they are not within the viewport, they will still take up ram, and you can effectively have five or so before leaks and nastiness begin to happen.
What I found works is "hiding" them ... But make sure they take up the physical space necessary.
What I also found worked was that one could make the 'previous' current and 'next' image are visible and move the tray, 'unhiding' them as they reach those three positions.
In my own system, I skipped the 'tray' holding e images and only had them at -100% width, 100% width and the current one a 0.
I never had much luck with the typical long-tray carousel with large scale background images... Especially with css3 acceleration.
I opened the Stack Overflow website on my 47 inch LCD TV (resolution 1920 * 1080, 16:9) and found the text and website right in the middle of a lot of whitespace. The text was unreadable because Stack Overflow, like many other websites, is optimized for standard 1200/1024 viewports.
In order to make the website readable, I pressed 'ctrl' and '+' keys and sort of got the content to occupy more screen width. I am sure this is not "zoom in" because what the browser is actually doing is scale up the content size (i.e. reduces the no. of pixels per character).
Can this 'ctrl +' behavior be achieved using Javascript as a pre-render exercise after detecting the resolution/size parameter of the viewport?
Update: I tried #media-queries which scales font-sizes and other few things, but it doesn't help to scale images and rest of the content (such as padding etc.) in a balanced way. Most importantly, it doesn't satisfy the condition to restrict the size of a given div to say "610px and yet occupy 75%" of the available screen-width.
Which is like a resolution change if we press ctrl + on Gecko/Webkit based browsers. Sorry can't accept the answer below.
Mostly yes.
IE6,7 have zoom and IE8 has -ms-zoom
Everyone else has 2D transforms and scale() so you're covered. see zoom css/javascript
I havent seen anyone apply this sort of effect to the entire document, so things might be buggy. Enjoy!
I'm sure it's possible with javascript, as most things seem to be, but I think that this is the exact kind of problem that CSS Media Queries were specifically designed to solve.
Check out the article on Responsive Web Design over at A List Apart
my site is aimed purely at the laptop market (dont ask why or argue!), all my users (or 95%+) we on a screen width of 1200+,
netbooks are now taking off, with a resolution of 1024 wide.
my site still looks great on a netbook if you zoom out once (ctrl-minus), but i don't want to rely on users knowing about ctrl-minus.
what are my options besides redesign? I'm keen not to have zoom buttons on my page.
is there a javascript zoomer outer?!!!
While this doesn't sort out your zoom, you could try a little trick based on CSS & relative sizing.
If you have an image or a container that is 100px wide, try setting it to 10em wide (or faff with the em amount until you find the appropriate value). Eventually, if you do this to every single dimension specified upon your site, you'd be able to actively shrink the page by changing the default font-size. E.g. from 1em, to 0.91em.
People often use the relative sizing to allow people the flexibility of being able to shrink and grow font sizes as they want. It's not as commonly used on images (because they are by requirement, fixed in size). This needn't be the case though, and in this instance, might offer you a way out of a "full site redesign" and giving the effect of "zooming".
This might solve the problem without redesign, but may be tricky and would require a bit of testing. The way stylesheets cascade, shrinking the font a little more, element by element, might cause a few issues.
detect screen resolution via JS
apply appropriate CSS
ctrl + - is the browser feature and you should never rely on that.
try this article http://www.alistapart.com/articles/alternate/
or try to google "javascript switch css"
this is a bad idea for many reasons. zooming is client specific so you will run into cross browser compatibilities if even possible at all. your best bet is to use css and set a min and/or max width. you don't need to redesign but (assuming proper html structure and usage of external css) changing some width values should do the trick.
Simple - I have a layout that is 800 by 600. When I press Ctrl and +, it zooms in and looks wonderful.
I want to know if there's a CSS/Javascript way to do the same? Without the user having to do it (because users will not do it and see the small layout).
Same question was posted by someone Setting IE "Optical Zoom" feature using Javascript/CSS that got no good replies.
There is a zoom CSS property, but it is part of CSS3 and is most likely not widely supported. By setting this on the body element using JavaScript you can zoom the entire page.
I would agree with the sentiments of the answers to the question you linked to though in that it should be up to the user to choose their own zoom settings. If your site is too big/small to see, it indicates a problem with your site design.
You can set all sizes as dynamic (use em for fonts, % for divs/images sizes). Then change the main wrapper and the main font size using javascript.
You can also use CSS switching. Put all the colors and such in one css file. Then create 3 or 4 levels of zoom and inside hardcode different sizes for all the existing classes.
Example:
main.css
a{color:red;}
small.css
a{font-size:10px;}
medium.css
a{font-size:12px;}
Not all designs (in fact I'd wager, none, without targeted style sheets) can cope with the vastly different sizes of screen out there today, from portrait orientated screens at public libraries, to ultra fine artworking Macs with giant landscape screens and tiny little laptops - the latter two often used by executives that have NO understanding of how the zoom features in a browser work and also often have terrible eye sight and little patience.
My suggestion is to use relative sizing like Marcgg suggests. If you're really looking to be super flexible the you could use javascript or browserhawk (or equivalent) to measure the screen sizes and switch out style sheets for those that are really not going to work with your layout.