www.webdeveloper.com
Results 1 to 11 of 11

Thread: can anyone please explain me how they made this liquid layout?

  1. #1
    Join Date
    Jun 2014
    Posts
    17

    can anyone please explain me how they made this liquid layout?

    this is the website http://www.essers.com/en/ i dont understand how they did it, if you reduce the dimension of the browser windows you can see that it "snaps" and the grey header becomes higher, and the other content fit in the window.
    im pretty sure that the layout has been made using bootstrap but i cant achieve the same results by myself.

    this is my code:
    html:
    HTML Code:
    <!DOCTYPE html>
    <html>
    
    <head>
    	<title></title>
    	<link rel="stylesheet" type="text/css" href="../../CSs/main CSS/main.css" media="screen, projection, tv">
    </head>
    <body>
    
    
    <header>
    	<ul class="headerul">
    		<li id="home"><a href="#"><img src="../../css/main css/images/home.jpg"></a></li>
    		<li id="transpossible">IT'S TRANSPOSSIBLE.</li>
    		<li id="tracktrace"><a href="#"><img src="../../css/main css/images/track trace.jpg"></a></li>
    
    		<li id="news"><a href="#">NEWS</a></li>
    		<li id="contact"><a href="#">CONTACT</a></li>
    		<li id="dropdnlist">
    		<select>
    		<option>NL</a></option>
    		<option>RO</option>
    		<option>EN</option>
    		</select>
    		</li>
    	</ul>
    </header>
    
    
    </body>
    </html>
    css:
    Code:
    body 			{margin: 0px;
    					width: 100%;}
    
    
    header 				{width: 100%;
    					padding: 0px;
    					margin: 0px;
    					background-color: #505050;
    					height: 100px;}
    
    
    .headerul				{float: left;}
    
    
    .headerul li 				{display: inline;
    					list-style: none;
    					color: white;
    					float: left;}
    
    
    .headerul a 				{color: black;
    					text-decoration: none;}
    
    
    #home				{margin-left: 82px;
    					margin-top: 12px;}
    
    
    #home a 				{padding-right: 70px;
    					padding-left: 15px;}
    
    
    #transpossible			{font-size: 18px;
    					margin-top: 8px;}
    
    #tracktrace				{margin-top: 3px;}
    
    
    #tracktrace a 			{padding-left: 100px;}
    
    
    #news				{margin-top: 12px;
    					margin-left: 424px;
    					width: 35px;
    					font-size: 12px;}
    
    
    #contact				{margin-top: 12px;
    					margin-left: 20px;
    					font-size: 12px;}
    
    
    #dropdnlist				{margin-top: 10px;
    					margin-left: 20px;}
    (im trying to copy this website just for practicing)

  2. #2
    Join Date
    May 2014
    Posts
    911
    It's called responsive layout, and it's not THAT hard to do... you use what's called "media queries" to do it. Be warned though it only works in 'modern' browsers, as well as IE9/newer. Pay particular attention to how I worded that!

    A lot of people will tell you to make a 'mobile size' layout first and then make it into columns for larger displays -- I prefer to start with the desktop layout pre-media query browsers like IE8/earlier will get, and then strip columns off the design as needed.

    A "media query" is built like this:

    Code:
    @media (max-width:20em) {
    /* put your properties here */
      .headerul { float:none; }
    }
    What that says is the contents of that @media {} will only be applied if the available screen width is less than 20em... which in this case would strip the float off .headerul

    @media (min-width:xx) can be handy too, since that would apply only to pages wider than the value stated.

    That's really the basics of it.

    Technically I was an "early adopter" of responsive layout since I was already building elastic and semi-fluid layouts, and then enhancing them with JavaScript in what was called "McSwitchy" design. McSwitchy just used JavaScript to change a class on BODY you used as a trigger to do the same thing. Now with CSS3 we don't need the scripting.

    As I often say, GOOD layouts should be three things:

    1) Elastic -- fonts declared in % or EM and any fixed containers declared in EM so the layout auto expands to the user font preference. Remember, PX fonts should be avoided unless you really HAVE to use them on something advanced like a image replacement.

    2) Semi-fluid -- fluid design that expands and shrinks to fit the available space, but with a min-width to prevent it breaking on pre media-query browsers, and a max-width so really long lines of text don't get hard to follow.

    3) Responsive -- which we just covered. Using media queries to add or remove columns and swap out design elements to fit all sorts of screen sizes.

    ... the first two really being stepping stones to the third.
    Java is to JavaScript as Ham is to Hamburger.

  3. #3
    use @media tags or try writing percentage where you write pixel. % instead px

  4. #4
    Join Date
    Mar 2012
    Posts
    1,516
    To answer the question in the OP: the site you quote uses a Joomla template and Javascript, which, as DS has pointed out is not necessary anymore. Provided you make allowances for IE8, you can use @media to achieve the same effects without JS.

  5. #5
    Join Date
    Mar 2012
    Posts
    1,516
    Further to my comments above, I'd just point out that using EM instead of PX is not really anything to do with responsive layouts, as it applies equally to fixed layout. To clarify: browsers (and some OS's) have a facility to allow users to expand font sizes to suit their requirements. Basically it is an accessibility facility for the partially sighted, but it can also be used to compensate for different pixel sizes in modern displays. The problem is that the facility doesn't work if you use PXs. You have to use EMs (or percentages). Also, there is a downside:

    1. You need to test your page layouts at up to 2x the size of the text i.e. 1em = 32px (as well as the default 1em = 16px).

    2. For heading and menu items (that you do not want to wrap) and which are intended to be viewed on small-screen mobile devices, you may only be able to use fonts that are half the size that you might otherwise use. Why? Because you need to allow rooom for the user to expand the font!

    Thus allowing the user to expand the font sizes for greater legibility potentially means that the user will need to expand the font where it might otherwise not be necessary! Also, it is a fact that the vast majority of web sites are written in PXs, so the font re-sizing does not work most of the time! Whereas there is also the facility to set the default page zoom, which works whether you use EMs or PXs.

    So, on balance, is it worthwhile using EMs instead of PXs? Technically, I'd agree with DS that you should use EMs, and personally I intend to do so, but in practice the argument is already lost. Although the zoom facility is technically inferior, more importantly, it works on all sites.
    Last edited by jedaisoul; 07-24-2014 at 04:17 PM.

  6. #6
    Join Date
    Oct 2013
    Posts
    486
    @jedaisoul:

    What about using pt. (points) as the font metric? Does that react like EMs or PXs? In other words, does a 12pt font scale like a 1em font? Or is it "unscalable" like a 16px font?

    Hope that made sense.

  7. #7
    Join Date
    May 2014
    Posts
    911
    Quote Originally Posted by jedaisoul View Post
    Although the zoom facility is technically inferior, more importantly, it works on all sites.
    Sad part is, it often doesn't.... usually thanks to thinks like fixed width layout and a lack of responsive design, or worse some browsers not reporting how the zoom effect should impact media or even min/max width triggers. SO many pages break when you try to zoom them it's ridiculous -- and it's usually due to artsy-fartsy bull from some painter calling themselves a "designer", or outright developer ineptitude when it came time to make an actual layout instead of some goofy halfwit "layered" PSD.

    The REALLY sad part is, the only browser engine to EVER get it 100% right -- Presto -- has now been pitched in the trash in favor of Blink (Google's webkit fork) -- resulting in the pathetically crippled and useless ChrOpera... Though to me from a user interface standpoint ALL the other browsers are pathetic crippleware and like a trip in the wayback machine with Mr. Peabody to IE 3 mac... Even firefox with every extension out there still pales in comparison to the things that made Opera worth using over other browsers -- It can be dragged close, but there's still so much missing; Chrome or IE, don't even BOTHER if you actually got used to things like an in-built e-mail client, portrait tabs, favicon launchers on any toolbar, custom toolbar buttons, an actually USEFUL trashcan, notes, wand, single password to multi-pass security, user.css, user.js, built in accessibility user.js, etc, etc, etc...

    Which is why I'm still using Opera 12.17 as my primary browser, and am likely to stay there until it either stops working with websites altogether or something comes along that actually works how I've come to expect a browser to work the past decade or so.

    ... and is stable while doing so, which of course FF is decidedly not. Firefox, the browser that you have to add extensions to in order to make it usable, but becomes an unstable unreliable train wreck if you add extensions -- shades of phpBB.
    Last edited by deathshadow; 07-25-2014 at 04:32 AM.
    Java is to JavaScript as Ham is to Hamburger.

  8. #8
    Join Date
    Mar 2012
    Posts
    1,516
    No, Pt seem to work like PX not EM, at least in my simple test of Chrome.

  9. #9
    Join Date
    Mar 2012
    Posts
    1,516
    @deathshadow

    Well, I haven't tested all browsers, particularly obsolete ones, so perhaps I should have said; "Setting the default zoom works more often than font scaling (in current browsers)".

    Would you agree that is factually correct?

  10. #10
    Join Date
    May 2014
    Posts
    911
    No, I wouldn't say it works worth **** in modern browsers... FF and IE in particular make a right mess of things. Crum is a mixed bag as is ChrOpera, though they do a FAR, FAR better than say Safari, since Apple developers have their own little delusions over what accessibility means and now that Google has told them where to stuff it with webkit, forking it off into blink, Safari is starting to age worse than "real" Opera is. Hence all the garbage in Safari that still takes vendor prefixes even IE doesn't need anymore.

    Which is why most people who need accessibility will pay a grand for JAWS and consider Apple's attempts at things like screen readers to be a pathetic joke at best.

    Oh, and PT is a really mixed bag. In FF thanks to it's Nyetscape legacy PT is the only measurement that obeys the system metric -- aka the OS setting. It ignores the OS setting for EM, and if you change the default size/em in FF, PT remains based on the OS setting.

    Chrome and Safari just treats PT as pixels and has an 'arbitrary' scale thanks to Apple's having no clue what accessibility is or even how to print anything properly anymore (they don't even scale PT to the print DPI on a media="print" CSS anymore?!?) ... IE and 'real Opera' PT obeys the system metric OR the browser setting, and scales to what it's SUPPOSED to mean on print.

    Of course, PT should be meaningless for screen as 1pt is SUPPOSED to equal 1/72th of an inch, hence 12pt line-height = 6 lines per inch == 60 lines per page on 11" with the 'stock' half inch margin of the old daisy wheel and dot-matrix printers. Since the OS DPI setting in relation to the screen is most always 100% fiction, points isn't a great choice.

    Though back when we still had a lot of Nyetscape 4 users PT was the defacto choice if you cared about large font users as again, Opera, IE and Nyetscape obeyed the host OS setting for PT, while Nyetscape (and by extension Gecko/Mozilla) ignored the OS for the %/em default. It really wasn't until Opera 8, Safari and somewhat later Chrome came along that developers started abandoning PT...

    For pixels; about the same time the whole "drawing a pretty picture and calling it web design" idiocy came into being, pissing away accessibility, page speed, and functionality for "ooh, shiny"; even if it ignores every accessibility recommendation and design guideline out of the W3C the past decade and a half.

    Though the specifications and guidelines -- like the HTML spec and the WCAG are partly to blame for being endless legalese a normal person who didn't go to law school for six to eight years would never comprehend. The WCAG is a good idea, but it's just too damned wordy for normal developers to spend the time to understand. Much like the HTML specification which can't even use words like "empty" or "importance" in a manner "normal people" are willing to take the time to grasp.

    The part of me that spent four years writing technical manuals for barcode scanners (some of which I also designed) recoils in horror at what the W3C calls a "specification" -- and it just gets worse and worse with every new version.
    Java is to JavaScript as Ham is to Hamburger.

  11. #11
    Join Date
    Mar 2012
    Posts
    1,516
    @ deathshadow

    I accept what you say, as you have clearly researched the issue much more than I have. So where does that leave us?

    1. It is a fact that, like it or not, the vast majority of sites are built using pixel measurements. So the EM functionality only works on the tiny minority of sites that support it.

    2. Browser handling of zoom functionality is a mess.

    So there is no cross-browser solution to accessibility. However, I infer from your comments that Chrome and Opera are much better at handling zoom than FF and IE. Therefore people needing to set a defaut level of zoom should prefer them as their browsers.

    However:

    3. The problem of accessibility is not web-specific anyway.

    4. JAWS and MAGic (the low-vision partner app) are far better solutions to accessibility across a range of apps, including web browsing.

    Hence the needs of visually impaired users, particularly those needing greater assistance across a range of apps, are best dealt with by dedicated apps like JAWS and MAGic. Which leaves users with minor visual impairment or a preference for larger font sizes. They may benefit from modest levels of zoom using Chrome or Opera. If so, when developing web sites, it may be worthwhile to take into account the use of modest levels of zoom on Chrome and Opera browsers.
    Last edited by jedaisoul; 07-26-2014 at 11:35 AM.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles