Coding: Fleeting Thoughts

[Rium]

Sorry, I’ll try to explain better. I want to move the background image relative to the text. The padding-approach does exactly that, but it didn’t look very elegant to my eyes, so I figured I’d ask if there was a better way. Now, I’d like to achieve a consistent distance between the headline (the actual headline text) and the text above and below. With this method, the distance varies wildly when I use images with different heights and paddings, so I thought I could just move the entire thing up (or down) with position:relative and set the distances with margins. Maybe using only margins would be a better idea.

Steax, you’re right, I’ll substract the padding-left from the width, but I was mostly confused about the vertical padding.

My code is probably horrible on several levels, but I made a fiddle here. I’m clueless why the margins have no effect, but I hope you get the picture.

[Steax]

The top/bottom padding: it's actually working as intended; if you apply an outline or border, you'll see that it's resizing accordingly. The issue is that you set your background alignment to bottom, and since the image is 120px high, only empty space gets generated on top. Change the alignment to "top" and you'll see what I mean.

There are several ways to fix what you want to do. First, and probably most correct for your situation, is to use the line-height attribute, and set that to the element height. This will align your text to the object's height center. Just add "line-height: 120px;" and watch what happens. You can also use text-indent to push the text on the x-axis, though I'm not sure that's a the "semantic" option. Other options include using a wrapper or inner element and positioning that.

Note that xanthir knows about the CSS standard much better than I (or probably anyone here), so he probably knows more.

On the second bit, yes, you always want to use margins to set distances between it and other elements in its flow. Relative positioning should only be used when absolutely necessary.

Your code is actually pretty good!

Extra notes: There is a caveat to using line-height: if your text becomes long enough that it requires more than 1 line, it will introduce a wide space between them. For these situations, you should use padding.

[Aaeriele]

I’m clueless why the margins have no effect, but I hope you get the picture.

They're not working because you forgot a semicolon after the margin-top bits, so it's reading both lines together as one and failing to parse properly.

Here's a version with proper semicolons added: http://jsfiddle.net/sx5sU/6/

[Xanthir]

Sorry, I’ll try to explain better. I want to move the background image relative to the text. The padding-approach does exactly that, but it didn’t look very elegant to my eyes, so I figured I’d ask if there was a better way. Now, I’d like to achieve a consistent distance between the headline (the actual headline text) and the text above and below. With this method, the distance varies wildly when I use images with different heights and paddings, so I thought I could just move the entire thing up (or down) with position:relative and set the distances with margins. Maybe using only margins would be a better idea.

I'm still not sure what you mean by "move the background image relative to the text". It *sounds* like (and looks like, from your fiddle) what you want is for the box to be the size of the background, and for the text to be vertically centered within it.

This will be easier to do when Flexbox is supported everywhere (it's two properties and you're done), but for now Steax's suggestion is probably the best if you can be *sure* that there will only ever be one line of text. I've implemented it here: http://jsfiddle.net/sx5sU/7/

This works because when the line-height is bigger than the font-size, the extra space is split evenly between the top and bottom. So, by setting the line-height to the height of your background, your text will be (roughly) vertically centered.

If you have multiple lines of text, this immediately breaks, as the next line goes below the background. But for this case it's probably okay.

If you need multiple lines of text to be centered, it's a bit trickier using current CSS. The best method is to lean on display:table-cell. I've illustrated this here: http://jsfiddle.net/sx5sU/8/ Note that this will *not* allow margins as written, because the table-cell is wrapped in an anonymous table-row and table, and cells don't get margins. If you want margin control, you'll need a second wrapper with display:table and the margins on it.

Once we get flexbox working across browsers, it'll be as simple as:

Code: Select all

h2 {
  background: url(foo);
  width: <width-of-image>;
  height: <height-of-image>;
  display: flexbox;
  flex-align: center;
}


DONE. Works for any number of lines, and has no weird side-effects like display:table-cell does.

[Xanthir]

You can also use text-indent to push the text on the x-axis, though I'm not sure that's a the "semantic" option. Other options include using a wrapper or inner element and positioning that.

Nothing wrong with using text-indent, as long as you're sure you'll only have one line of text. This is all styling, there's no such thing as "semantics" at this layer.

[Rium]

The top/bottom padding: it's actually working as intended; if you apply an outline or border, you'll see that it's resizing accordingly. The issue is that you set your background alignment to bottom, and since the image is 120px high, only empty space gets generated on top. Change the alignment to "top" and you'll see what I mean.

Okay, now it’s my turn to not know what you mean. Are you referring to my first example (red-high in this Fiddle)?

Fluttershy: Thanks.

Xanthir: The background image has an area where the text should go, which isn’t necessarily the center. It doesn’t matter if the box is slightly bigger than the image, but the image shouldn’t be cropped.

I think my problem is pretty much solved, I now have a pretty good understanding of how to use padding and margins to get it right. Thanks for your help, everyone!

[Steax]

The top/bottom padding: it's actually working as intended; if you apply an outline or border, you'll see that it's resizing accordingly. The issue is that you set your background alignment to bottom, and since the image is 120px high, only empty space gets generated on top. Change the alignment to "top" and you'll see what I mean.

Okay, now it’s my turn to not know what you mean. Are you referring to my first example (red-high in this Fiddle)?

I was referring to your original fiddle (this one). Assuming you fix the semicolon issue on the top example, the text still won't go to the center of the image, and instead just generates more whitespace on top.

If you want it easy, you can set -x-box-sizing rules. This way you just set the height/width to the actual image background and you then use paddings accordingly, so you don't have to mentally do the math. The only browser that doesn't support it (BIG SURPRISE!) is IE5-7.

You can also use text-indent to push the text on the x-axis, though I'm not sure that's a the "semantic" option. Other options include using a wrapper or inner element and positioning that.

Nothing wrong with using text-indent, as long as you're sure you'll only have one line of text. This is all styling, there's no such thing as "semantics" at this layer.

I suppose so, yeah. I've had too many arguments with semantic nutheads in my time.

[Xanthir]

Xanthir: The background image has an area where the text should go, which isn’t necessarily the center. It doesn’t matter if the box is slightly bigger than the image, but the image shouldn’t be cropped.

Ah, okay.

Then what you want is to use the padding-top + height thing to push the text down to the appropriate place.

As Steax alludes, you can use "box-sizing:border-box;" (supported on IE8+!) to avoid having to fuck around with 'height', as it makes the 'height' property control the size of the border-box rather than the content-box. Then you just set the height to the height of the image, and adjust the padding as you need without any additional work.

There shouldn't be any need to use additional margins to align the text and image.

[tastelikecoke]

so I made a python function that computes the Graham's number. I wonder when it would crash my computer (or more boringly, raise an exception.)

That aside, I'm stuck at how to compute the last digit of Graham's number in just a minute or less.

[Xanthir]

For those of you interested in CSS, I just completed a major restyling effort for our Editor's Drafts to be more usable and fully WCAG-compliant. Here's my Flexbox spec with the new styles, but nearly all of the EDs (all the ones we've moved to the new default.css file) will use it too.

[b.i.o]

There is a special hell waiting for people who center-align body text. Even on April 1st.

[shawnhcorey]

There is a special hell waiting for people who center-align body text. Even on April 1st.

Yes, it's a round room with a wrap-around screen. Center that, you poor souls!

[sourmìlk]

What the fuck is with windows type naming conventions? Who thought that LPCTSTR and PFNGLACTIVETEXTUREPROC and HWND were good type names?

[You, sir, name?]

What the fuck is with windows type naming conventions? Who thought that LPCTSTR and PFNGLACTIVETEXTUREPROC and HWND were good type names?

Some Hungarian guy?

[sourmìlk]

I thought that Hungarian Notation applied to variable names rather than type names. And if Hungarian Notation is such that it requires all-caps type names, without word delimiters, using only unpronounceable and unintuitive initialisms then it is a bad convention.

[Steax]

What the fuck is with windows type naming conventions? Who thought that LPCTSTR and PFNGLACTIVETEXTUREPROC and HWND were good type names?

Upon my first foray into C++, I looked into my IDE's template projects (I wanted to do GUI soon instead of CLI), compiled, thought it would be easy, looked at the source, saw that crap, and immediately moved on to other languages.

[Yakk]

Hungarian notation, the idea that macros should be capitalized, overuse of macros and legacy. Note that MS got it right in office, and then deployed it wrong in windows (Hungarian notation). Google the story.

[EvanED]

I thought that Hungarian Notation applied to variable names rather than type names.

Typenames follow some of the same conventions as variables. For instance, I could have a DWORD dwHeight. If I wanted a pointer instead, not only would the variable be called lpdwHeight but the type of it would be LPDWORD. (Actually they might just use DWORD* in that case, but you'll see lots of LPstruct names and such.)

Personally, I think the biggest problem with MS's type names is the all caps.

[shawnhcorey]

Well, the reason they use LPstruct names is because of the strange pointer notation in C. To declare two stings in C:

Code: Select all

char *s1, *s2;

The pointer symbol, '*', needs to be entered twice. But with LP notation:

Code: Select all

LPSTRING s1, s2;

[Yakk]

And LP because at the time there where long and short pointers with short pointers being a 16 bit segment offset only. And short alphabet soup names because of the eight char limitation of some linkers in C days, so.brevity was important. Add on decades of growth on top of that and a reluctance to throw out old code...

[EvanED]

Yep. And C for "const", and T for... uh, "either narrow or wide chars depending on the setting of the UNICODE preprocessor flag" (there're a couple 't's in there) and everything looks like a locally reasonable decision. And yet then you get to LPCTSTR...

(As an aside, I think the issue that shawnhcorey points out is just further evidence that Denis Ritchie did lots of LSD around 1970, but that's just me. Not to disrespect the man in actuality, of course.)

[Yakk]

The decorators around a name when defined are supposed to echo how the variable is going to be used.

Ie:
char_type_variable = *foo;
becomes
char *foo;

This means that the type is on the "left" hand side of the equals, and the decorations are tied to the variable name.

A more insane case is char (*func)(int, double); which is used by saying char_type_variable = (*func)(x, d); But the same pattern emerges.

It ends up not scaling well, but the idea was elegant -- parsing a declaration uses nearly the same code as parsing an expression, but sort of backwards.

[EvanED]

Yeah, I know why it is the way it is. I still think it's bonkers (esp. function pointers). The one somewhat beautiful part of C declaration syntax is if you have a declaration of a variable and you put typedef before it, then the declaration remains legal and defines a typedef instead, of the same name.

I think I prefer the C++11 using foo_t = int; syntax (if that's still legal for non-template typedefs?) for C++ code because the new name is given first¹, but the C version does have a really nice parallel syntax for the two constructs.

But I joke about the LSD thing. To be clear, I don't like C; I have a lot of problems with it and C++. But the design space was very very different in 1970, both because of far more limited machines and because we didn't know nearly as much about programming language design. And thus I think very few of C's decisions (or Unix's, which I also rag on Ritchie for sometimes) were actually bad at the time, and it was really pretty revolutionary at the time and went a long way towards advancing computing. What I really meant was "anyone who designs a language now who follows that rule of C must be taking LSD."

¹ I don't have experience with trying to read this code, but I suspect that it'd be easier. I find it hard to scan a long line like std::vector<pair<int, int>>::const_iterator iter to jump immediately to the name of the variable being declared, especially as you start adding more template parameters (which in addition to making the type longer also adds spaces to it, so you can't even just look for the break). You have to scan backwards from the end of the line. And I find I'm much more interested in the story "I'm declaring x to be an int" than in "I'm declaring an int I'm going to call x." Just think of one of the common reasons to look at a declaration that's already written: you want to see what type something has! It's like part of the reason why I prefer Foo const & to const Foo & -- the Foo is the more important part!

Obviously the new using aliases don't help with variables, but the step in typedef world is equivalent and still forward. It's just an analog to Amdahl's law grossly limits the overall benefit.

Edit: I think I'm done mucking with this post now. :-p

[Yakk]

using foo = decltype( (int(*)(int))nullptr );
I kid.

(But wikipedia seems to indicate that using with non-templates works.)

[sourmìlk]

And LP because at the time there where long and short pointers with short pointers being a 16 bit segment offset only. And short alphabet soup names because of the eight char limitation of some linkers in C days, so.brevity was important. Add on decades of growth on top of that and a reluctance to throw out old code...

And yet I don't see this problem in other very old APIs. OpenGL functions from 1992 still have lovely names like glVertex3i() and intuitive type names like GLvoid or GLint, not LPCSTRGLTPFNINT or whatever.

[Sc4Freak]

Didn't the old OpenGL API do the exact same thing? It's been a long time since I've used OpenGL but I seem to recall all its functions were postfixed with the type of the arguments it took.

[chridd]

Didn't the old OpenGL API do the exact same thing? It's been a long time since I've used OpenGL but I seem to recall all its functions were postfixed with the type of the arguments it took.

They are, or at least many of them (including the example sourmìlk gave, glVertex3i), but they have more than 8 characters in their names. The types are also simpler (3i = 3 ints, as opposed to LPCT etc.), and they have a purpose of distinguishing e.g. glVertex3i from glVertex3f.

[sourmìlk]

Exactly, they're readable. I can tell you what glVertex3i does by the function name. I cannot tell you what LPCTSTR does by the type name.

[Yakk]

Have you read the story of Hungarian notation in office vs windows? Find it.

Btw, what about LPCTSTR isn't clear? Long pointer to constant compile time determined string.

The limitation on length of symbols may have been gone by then in most compilers, but the habits remai

The decision to use ALLCAPS for type names makes it obvious what is a type name and what is not. Someone decided that was worth it. I would think that was a bad idea, but once decided these things stick.

If you are looking for why choices made are optimal in hindsight you are being foolish. Decisions with limited information by people where made and many of them where sticky.

[Aaeriele]

Since people keep mentioning the Hungarian Notation Office v. Windows story, I figured it'd be worth it to just link it:

http://www.joelonsoftware.com/articles/Wrong.html (scroll most of the way down to "I'm Hungary")

[sourmìlk]

Have you read the story of Hungarian notation in office vs windows? Find it.

Btw, what about LPCTSTR isn't clear? Long pointer to constant compile time determined string.

The limitation on length of symbols may have been gone by then in most compilers, but the habits remai

The decision to use ALLCAPS for type names makes it obvious what is a type name and what is not. Someone decided that was worth it. I would think that was a bad idea, but once decided these things stick.

If you are looking for why choices made are optimal in hindsight you are being foolish. Decisions with limited information by people where made and many of them where sticky.

I am perfectly satisfied with the explanation that it seemed like a good idea at the time. Of course, it wasn't that good an idea because people have done better, but still, it works.

LPCTSTR isn't ambiguous, it's just difficult to read and its name doesn't give you a clear indication of what it does unless you already know what it does.

[Sc4Freak]

I think most things in C are like that...

What in the world does "atoi" do?

[Thesh]

It's pretty obvious that is searches a string for the character 'a' and replaces it with the character 'i'.

[phlip]

I think most things in C are like that...

What in the world does "atoi" do?

ASCII-to-integer.

Though, I've never understood exactly what the "T" in TCHAR/LPTSTR/etc stands for...

Also, Aaeriele: that was a very interesting article... thanks for the link!

[Steax]

Since people keep mentioning the Hungarian Notation Office v. Windows story, I figured it'd be worth it to just link it:

http://www.joelonsoftware.com/articles/Wrong.html (scroll most of the way down to "I'm Hungary")

That's very interesting and dealt with some issues I've often had trouble with. Thanks!

[Sc4Freak]

I think most things in C are like that...

What in the world does "atoi" do?

ASCII-to-integer.

Though, I've never understood exactly what the "T" in TCHAR/LPTSTR/etc stands for...

Well yes, the point is that "atoi" is just as cryptic as "long pointer to constant generic string".

The "T" is for "type", in the same way we often use T as a template parameter - it's a stand-in for another type. Except in this case the T is defined by compile-time constants. I suppose it's as good of a character as any to choose for that.

[Jplus]

Since people keep mentioning the Hungarian Notation Office v. Windows story, I figured it'd be worth it to just link it:

http://www.joelonsoftware.com/articles/Wrong.html (scroll most of the way down to "I'm Hungary")

Great, thanks. I think what he's saying here makes a lot of sense, but there is one very important nuance in his article that I'd like to highlight:

Apps Hungarian was extremely valuable, especially in the days of C programming where the compiler didn’t provide a very useful type system.

(emphasis mine)

Apps Hungarian is a really good idea, but nowadays there is another technique available which solves the same problem even better. It's called "typeful programming" or "type-rich programming". Basically you make separate types for things that shouldn't be used interchangeably, so any mistake in that direction will yield a compiler error. Lately it's a hype in C++ and its close relatives (such as D), but in principle you can apply it cleanly in any static, strong-typed language with overloading. Without overloading you can still apply the technique (e.g. in C), but then you'll have to throw some Apps Hungarian into the mix as well.

[Yakk]

*nod*, instead of marking up the integers that are rows with an r, and the ones that are columns with a k, you make two types of integer.

One of them is a row, and the other is a column.

Direct conversion of a row to a column leads to a compiler error in type-rich programming. In hungarian aps notation, it just looks wrong to the programmer reading it.

[troyp]

Yeah, in Haskell you can often arrange things so that almost any error causes a compile-time error.

Of course, then you start becoming complacent...and when you *do* have a runtime error, suddenly you're shocked and you say "My program compiled, but now it's...it's giving the wrong answer!"

[Meem1029]

From what I get of it (still learning Haskell), if you're not doing that sort of thing in Haskell you're doing it wrong.