• setContentView(R.layout.레이아웃아이디) 는 xml화일의 레이아웃을 생성한다.재 호출하는 경우는 기존 레이아웃을 새 레이아웃으로 교환한다.
  • findViewById(R.id.뷰아이디) 의 경우는 이미 생성된 레이아웃내의 view obj를 되돌린다.
  • ViewPager mVp = new ViewPager(this);

    mVp

    .setId(R.id.지정할아이디이름); 를 통해 view를 dynamic하게 생성하고 아이디를 지정할수 있다. 아이디는 ids.xml에 <item name=“아이디이름” type=“id” /> 의 형식으로 또한 작성되야한다.

  • mVp.setLayoutParams(new LinearLayout.LayoutParams(
                                           LinearLayout.LayoutParams.MATCH_PARENT,
                                           LinearLayout.LayoutParams.WRAP_CONTENT,
                                           (float) 1.0));
    이와 같은 형식으로 생성된 element의 속성들을 설정할수 있다.  참조)  https://developer.android.com/reference/android/view/ViewGroup.LayoutParams.html
  • 레이아웃을 dynamic하게 생성하려는 경우는  LayoutInflater layoutInflater = (LayoutInflater)
           this.getSystemService(this.LAYOUT_INFLATER_SERVICE);
    를 이용하여 Layoutinflater obj를 얻고 이를 통해 생성한다. 참조)  https://developer.android.com/reference/android/view/LayoutInflater.html#inflate(int, android.view.ViewGroup)
  • tabLayout mode를 변경하는 경우. 예시)tabLayout.setTabMode(TabLayout.MODE_SCROLLABLE);
  • setContentView(R.layout.레이아웃아이디) 는 xml화일의 레이아웃을 생성한다.재 호출하는 경우는 기존 레이아웃을 새 레이아웃으로 교환한다.
  • findViewById(R.id.뷰아이디) 의 경우는 이미 생성된 레이아웃내의 view obj를 되돌린다.
  • ViewPager mVp = new ViewPager(this);

    mVp

    .setId(R.id.지정할아이디이름); 를 통해 view를 dynamic하게 생성하고 아이디를 지정할수 있다. 아이디는 ids.xml에 <item name=“아이디이름” type=“id” /> 의 형식으로 또한 작성되야한다.

  • mVp.setLayoutParams(new LinearLayout.LayoutParams(
                                           LinearLayout.LayoutParams.MATCH_PARENT,
                                           LinearLayout.LayoutParams.WRAP_CONTENT,
                                           (float) 1.0));
    이와 같은 형식으로 생성된 element의 속성들을 설정할수 있다.  참조)  https://developer.android.com/reference/android/view/ViewGroup.LayoutParams.html
  • 레이아웃을 dynamic하게 생성하려는 경우는  LayoutInflater layoutInflater = (LayoutInflater)
           this.getSystemService(this.LAYOUT_INFLATER_SERVICE);
    를 이용하여 Layoutinflater obj를 얻고 이를 통해 생성한다. 참조)  https://developer.android.com/reference/android/view/LayoutInflater.html#inflate(int, android.view.ViewGroup)
  • tabLayout mode를 변경하는 경우. 예시)tabLayout.setTabMode(TabLayout.MODE_SCROLLABLE);

What are the differences between LinearLayout, RelativeLayout, and AbsoluteLayout?

YouTube에서 Laravel Tutorial Part 4 – Views, Blade, and Layou… 보기

YouTube에서 Laravel Tutorial Part 4 – Views, Blade, and Layou… 보기

http://designshack.net/articles/css/whats-the-deal-with-display-inline-block/ 에서 참조 

We’ve been using floats for layout pretty much since we left tables behind. It’s a quirky solution that can often cause troubles, but if you know what you’re doing, it works.

One interesting alternative to floats that people are turning to more and more lately is to set the display value of an element to inline-block. What does this do exactly? How is it like a float? How is it different? Let’s dive in and see what we can discover.

The Display Property

Web browsers render different elements in different ways. Some elements are block-level, meaning that their default display value is set to block. Block-level elements have a definable width and height and automatically create a new row in the layout as they’re created.

One example of a block-level element is a paragraph. If I toss two paragraphs into a HTML document, they stack on top of each other rather than appearing side by side. I have a lot of freedom over their dimensions and can really treat them as individual building blocks to shape as I please.

screenshot

Other elements have their display value set to inline by default. This means they don’t have a definable height and width and will not create new rows in a layout (thus they appear “inline”). Inline elements are generally the type of thing that you institute within a paragraph or other block-level element: strong, em, anchor, etc.

Here’s what happens if I toss a bunch of anchor tags into an HTML document. Unlike the the paragraphs above, which automatically stack, these elements are created side by side. Their width and height are determined by the content they contain and can’t be manually overridden as with the block-level elements.

screenshot

There are a few other basic display default values that you’re probably familiar with as well. For instance, items in the head portion have a display property of none.

Setting Your Own Display Value

One really interesting feature of CSS is the ability to change the default display behavior of elements. Though a standard behavior is already set for a given element, we can override that for our own purposes.

For instance, we can easily take those inline anchor tags from the second example above and make them act more like the block-level paragraphs from the first example. We do this be setting the display property to block in our CSS.

screenshot

Now our anchor tags behave like block-level items, so each one creates a new line and can have a custom height/width value applied.

As you can imagine, it’s more difficult to work with the reverse of this example by taking a block-level element and setting the display value to inline. Instinctively, you might use display: inline to try to make the two paragraphs above appear side by side, but when you do this, the result is instead that the two flow together into a single paragraph.

screenshot

We’ve now lost all ability to set our width and height so the two paragraphs are inexorably integrated, which isn’t at all what we were going for.

Floating Elements

So what if we want the two paragraphs above to remain distinct but appear side by side as individual columns instead of stacked into rows? The typical answer that many of us have turned to for years is floats. By applying “float: left” to the paragraphs, we can maintain block-level functionality while creating multiple columns of content.

screenshot

Floats come with some interesting behavior. For instance, floated items tend to collapse their parent container, leading to all kinds of messy issues if you’re applying background colors or borders. To get around this, we have a few tricks. We can either clear the floats on a new element (these days it’s often a pseudo-element) at the end of the container or use overflow:auto on the parent. Both fixes have their caveats, but if you know how to leverage each properly you can typically pull off any layout feat without too much trouble.

display: inline-block

There are tons of values for the display property beyond what we’ve mentioned already, some of which are helpful, others that I doubt you’ll ever use. The topic of today’s discussion is by far one of the most interesting and useful of the bunch: inline-block.

Watch what happens when we take our two paragraphs from the original example above and apply adisplay value of inline-block.

screenshot

Looks a lot like a float right? So what happens if we add in a parent container? Does it have the collapsing problem that we saw with floats? Nope! Everything works just how we expect it to.

screenshot

What’s happening here is that we’re telling the browser to display the paragraphs inline, but allow them to retain their block-level characteristics. This means we can set a width and height manually and have the two elements remain distinct, but also have them appear next to each other in the document flow. Pretty slick!

The Alignment Issue

On the surface, inline-block may seem like the layout savior you’ve been waiting for. Who wants to mess with messy clearfix hacks when you can skip it altogether with this method? It turns out though that floats aren’t the only layout method with quirks, inline-block also has some strange functionality that you have to wrap your head around.

One of the first things that you’ll floats and inline-block look quite different when you have several elements with varying heights. For instance, here’s what happens when you float a bunch of paragraphs to the left:

screenshot

Now here’s what happens when you use inline-block to pull off the same thing. Notice that the bottom edges of the paragraphs are aligned instead of the top as in the previous image.

screenshot

Fortunately, this isn’t a huge problem. To address the issue, make sure you set the vertical-alignproperty to top.

screenshot

The Whitespace Issue

There’s another important place that the behavior of inline-block differs from floats. I find it bizarre that anything in HTML and CSS could be whitespace aware when it comes to layout, but that’s exactly what we find here. Consider the following examples.

screenshot

Here we can see that when a group of list-items is floated, they smash right up against each other like we would expect, allowing us to manually set the gap without any unexpected extra space. However, when we do the same with inline-block, there’s a little bit of default space that won’t even go away if we set our margins to 0.

As you can see, one solution is to take out the whitespace in our HTML and push the elements right up against each other. Once again, I find this pretty confusing but it does work. An alternative solution that produces the same result without screwing with the visual hierarchy in your HTML is to apply a margin of -4px on the list items.

screenshot

Browser Support

Now that we know what inline-block is and how it functions differently than floats, it’s time to discuss everyone’s favorite topic: browser support. What atrocities will we have to embark upon to make sure this technique actually works across the board?

When we stop by CanIUse.com to see the answer, the results are probably a lot better than you would’ve expected.

screenshot

Here we can see that we have at least partial support across the board and full support for everything but IE7 and older (feigned shock and awe). The note at the bottom informs us that inline-block is “only supported in IE6 and IE7 on elements with a display of ‘inline’ by default.” This means that the paragraph examples that we’ve used all throughout this article are out.

Fortunately, the Mozilla blog posted some fixes for this way back in 2009. To get IE to play along nicely, we just need to trigger hasLayout with the zoom property and then use the star hack to target IE6/7 and set the display to inline. This allows you to functionally treat the inline elements as if they were inline-block elements. It’s certainly not pretty, but it gets the job done.

1
2
3
4
5
6
7
8
9
li {
  display: inline-block;
  width: 100px;
  vertical-align: top;
 
  /*Dirty IE Hack*/
  zoom: 1;
  *display: inline;
}

Further Reading

If you’d like to learn more about inline-block, here are some articles that I found to be particularly helpful in my research.

A Better Solution?

To be honest, I’ve never really played around with inline-block too much before today, but I’ve been seeing more and more suggestions in the comments that I explore this method as an alternative to floats so I thought I’d take the advice. I was hopeful going into it that it was indeed some magic, no-hassle way around floats, but in truth it really isn’t. There are still several unexpected behaviors that you have to know about and respond to, resulting in some hacky code much like we often see with float clearing fixes.

To be fair though, it is in fact a pretty simple way to accomplish float-like layouts. More importantly, the CSS that you have to implement to make sure it’s cross-browser compatible is briefer than even the popular micro clearfix hack from Nicolas Gallagher. This may make it a better way to go for many projects.

Ultimately, I think I will in fact begin adding this method to my bag of tricks. I suspect that certain times will arise when floats aren’t ideal (example: right floats render everything in reverse) and this will be a great alternative to have in those situations.

What do you think? Is inline-block a good alternative to floats? What situations can you think of where one clearly has an advantage over the other?

inline-block is something I hadn’t used until a couple of months ago. I was comfortable with block and inline elements so I didn’t feel the need to learn anything more. I was also under the impression, as I’m sure many developers are, that anything other than display: blockand display: inline has cross-browser inconsistency problems and should be avoided.

This article focuses on why you should start using display: inline-block, understanding this value as well as how to make sure it is consistent across all modern browsers and IE7+.

Note: If you don’t yet know the differences between inline and block level elements, check out what css-101 has to say about it.

inline-block is your missing friend

inline-block solves all sorts of problems web-devs run into on a daily basis. I’m going to go through various common scenarios and cover how I would deal with them in a cross-browser fashion. You may notice some odd/hacky CSS included in the following examples – this will be covered in the Browser Compatibility section later in the article.

inline-block vertically center (IBVC) hack

Chris Coyier talks about a “Ghost” IBVC method and he credits Michal Czernow for it’s origin. Chris also mentions how it’s equivalent to the display: table/table-cell method since it also doesn’t support IE7. I’ve been playing around with inline-block and tinkering with vertical centering and I’ve come up with something that seems to be the ‘Ghost’ method (I’d discovered the ‘Ghost’ method after stumbling upon this solution) with a few differences. The two differences being mine supports IE6+ (not that IE6 matters at all anymore, just an FYI) and it doesn’t require pseudo elements to function.

Being able to vertically center an element with a dynamic height is something that has plagued developers (or me at least) for a very long time and the cross-browser solution has been somewhat of a holy grail. I’ve seen many different vertical centering methods, the most popular being the display: table used with display: table-cell. The problem with this is IE7 doesn’t support either of those display values.

I feel this hack is a more simple and easily understandable way of vertically/horizontally centering an element than the previously mentioned table/table-cell/IE7-bug-hack method. I also feel it’s much easier to understand and work with than the Gary Turner method too, but well done to him for coming up with that over 7 years ago. I’m sure other people will feel differently about this being the “best” way, however this is what I prefer..

Problems

vertical-align property

One slight downside to this I’ve noticed is vertical-align: middle vertically aligns the capital letters, so lower case letters or inline-block elements are very slightly off center. I’ve noticed elements being off by about 2px to 4px depending on what size the items are. Although this occurs it’s pretty much negligible for me – especially since I can’t actually notice this unless I actually count pixels.

Space characters

Space characters are handled like a space would be handled within inline-elements. This means that spaces and or tabs will be displayed as a space once the page has rendered. There are a couple of ways to work around this problem but it can be annoying nonetheless.

IE7 hand-holding

The above mentioned ‘space characters’ problem doesn’t take affect in IE7. The problem IE7 does come with is that it requires at least 1 other inline-block element to be present to allow the inline-block to vertically center. To get around this, I’ve added an “invisible” element after the item I’m centering – I’ve added it afterwards incase :first-child is used. This was included in the Ghost method through pseudo elements. Even though I’ve managed to remove pseudo elements, I’ve had to add an equivalent (or worse since it’s actual markup) for IE7. Boo.

Alternative methods

There is an IE7 CSS bug in which you can center an element vertically, and if used along side the table/table-cell method, it can work nicely (However I haven’t used it in practice). This can also be done using the Flexbox layout module – Flexbox is definitely something that will be used much more in future, however as Le Roux pointed out to me, the current Flexbox support right now is a bit flakey – So it may be another 1 or 2 years before we can start using it with absolute confidence.

Centering navigation items

I often come across a navigation design where the amount of items in the navigation should be dynamic, however the navigation itself should remain centered regardless of how many or how wide the items are. Previously I would have centered this with display: table, however, since display: table doesn’t have any IE7 support, I would have probably also used an IE7 javascript fallback (Or just let the navigation appear left aligned in IE7). With display: inline-block, this same result can be achieved with 2 (or 4 including IE7 support) css properties and values.

How simple was that? Seriously?

Article block listings

Generally I solve the following kind of problem differently depending on the exact design and how I feel at the time.

article listing example

An easy inline-block solution would be:

The design could have been more tricky, though. Typically the height would be dynamic, or possibly both the height and width. As you can see this isn’t exactly a masonry layout since each row starts and ends at the same top-offset. It is still not possible to solve a masonry design in LTE IE9 without javascript. The height of these items are dynamic though, mere floats wouldn’t work correctly. If we used floats would end up with something like this:

To avoid that we could use :nth-child and detect the first item in each row and then clear: left, but that would pose some cross-browser problems itself since :nth-child is only supported by modern browsers. We could add classes to these items via the CMS/backend language, but it would be easier if we could just get this working with CSS alone and without any problems! :(
Yay, inline-block the the rescue again! :D You didn’t expect that did you?!

More navigation

Surely there is some limit to the IE7 support? What about an inline-block within an inline-block?!

In the above example I have 3 levels of nested inline-block items and it works perfectly in IE7+.

Browser compatibility

If you’ve read up until this point, you are well aware that an IE7 hack should be used to “enable” the inline-block functionality.

The IE7 hack

.item { display: block; *display: inline; zoom: 1; }

This could be turned into valid CSS if you are using the <html> conditional classes (included in h5bp):

.item { display: inline-block; }
.lt-ie8 .item { display: inline; zoom: 1; }

Why does that work?

IE7 doesn’t support inline-block per se, however you can mimic the functionality by making it be an inline element and triggering hasLayout on the element. The zoom: 1 visually doesn’t change anything. It is applied this way because it is one of the properties that triggers hasLayout.

Conclusion

inline-block is an amazing and underrated and underused property, in my opinion. inline-block is something that can and should be used today with confidence. We fear that which we do not understand – hopefully inline-block is now added to your CSS toolbox.