Out of curiosity, why are you opting for this solution rather than a new syntax, like the @variable syntax used by LESS?

The stuff in the draft is a strict superset of the LESS/SASS/etc variables. If you restrict yourself solely to setting data properties on :root{}, you have identical power. Setting them on other elements, though, gives you a weak (but useful) form of scoping for "free".

Nothing has changed at the end of our path; knowing only the cruel leads the way to our fall.And there's no long anyone left by me. As the blind leads the blind to his faith,but only to find he remains unforgiven. So he turns but his angel is already gone.

qubital wrote:Coding, is it worth mastering Perl?I'm currently reading Mastering Regular Expressions and the author is kinda pushing Perl but I'm not sure, seems kinda antiquated.

Oh-oh! This could turn into a Religious War.

What languages do you know?

If you don't like the look of Perl you're in good company. Different languages offer slightly different "flavours" of RE, and Perl-style RE is often seen as the default flavour. I don't know Perl, but I often use regular expressions in python, awk & sed, and in grep commands. And I've used them occasionally in JavaScript.

qubital wrote:Coding, is it worth mastering Perl?I'm currently reading Mastering Regular Expressions and the author is kinda pushing Perl but I'm not sure, seems kinda antiquated.

Oh-oh! This could turn into a Religious War.

What languages do you know?

If you don't like the look of Perl you're in good company. Different languages offer slightly different "flavours" of RE, and Perl-style RE is often seen as the default flavour. I don't know Perl, but I often use regular expressions in python, awk & sed, and in grep commands. And I've used them occasionally in JavaScript.

I know Haskell and some Scheme. I was looking to learn a language that would aid my Linux skills.

Perl used to be the scripting language of choice for linux, but from what I hear the main contenders are Ruby and Python while Perl is on its way out.

I'm not a linux guy, so I may be wrong, but that's just what I've been hearing.

Nothing has changed at the end of our path; knowing only the cruel leads the way to our fall.And there's no long anyone left by me. As the blind leads the blind to his faith,but only to find he remains unforgiven. So he turns but his angel is already gone.

qubital wrote:Coding, is it worth mastering Perl?I'm currently reading Mastering Regular Expressions and the author is kinda pushing Perl but I'm not sure, seems kinda antiquated.

Perl's regular expressions are the most powerful around. In fact, both Python and Ruby uses Perl's regular expression engine. You should be able to use the regular expressions from the book directly in these languages without any modification.

qubital wrote:Coding, is it worth mastering Perl?I'm currently reading Mastering Regular Expressions and the author is kinda pushing Perl but I'm not sure, seems kinda antiquated.

Perl's regular expressions are the most powerful around. In fact, both Python and Ruby uses Perl's regular expression engine. You should be able to use the regular expressions from the book directly in these languages without any modification.

With the caveat that if there are places they are used in Perl code snippets, you'll have to transliterate them of course. That could take some effort.

I can also imagine there are some modifiers (like /abc/bi to match "abc" but insensitively -- I don't actually know if this is how Perl does it, but I think I've seen it) which also have to be translated as well. E.g. in Python you'd have to pass some CASE_INSENSITIVE constant to the re constructor.

Also, I'm with people who think that in a world with today's Python, Perl serves very little purpose and wish that no new code was written in it. (Of course, I also think that about C, with partial exceptions for actual embedded systems, so take that with a grain of salt.)

EvanED wrote:I can also imagine there are some modifiers (like /abc/bi to match "abc" but insensitively -- I don't actually know if this is how Perl does it, but I think I've seen it) which also have to be translated as well. E.g. in Python you'd have to pass some CASE_INSENSITIVE constant to the re constructor.

Since the book is written in Perl's regex, they should work with Perl. The /i is called a modifier; for a complete list, see `perldoc perlre` and search for /Modifiers/.

EvanED wrote:Also, I'm with people who think that in a world with today's Python, Perl serves very little purpose and wish that no new code was written in it. (Of course, I also think that about C, with partial exceptions for actual embedded systems, so take that with a grain of salt.)

Yeah, Pythoners have been dis'ing Perl from the start. I'd wish they would grow up.

EvanED wrote:Also, I'm with people who think that in a world with today's Python, Perl serves very little purpose and wish that no new code was written in it. (Of course, I also think that about C, with partial exceptions for actual embedded systems, so take that with a grain of salt.)

Yeah, Pythoners have been dis'ing Perl from the start. I'd wish they would grow up.

I've been dissing it well before I knew much about Python. You can feel free to like it if you want, but I'm more than content not having to deal with it. But I won't say any more about it in this thread.

EvanED wrote:shawnhcorey wrote:EvanED wrote:Also, I'm with people who think that in a world with today's Python, Perl serves very little purpose and wish that no new code was written in it. (Of course, I also think that about C, with partial exceptions for actual embedded systems, so take that with a grain of salt.)

Yeah, Pythoners have been dis'ing Perl from the start. I'd wish they would grow up.

I've been dissing it well before I knew much about Python. You can feel free to like it if you want, but I'm more than content not having to deal with it. But I won't say any more about it in this thread.

EvanED wrote:shawnhcorey wrote:EvanED wrote:Also, I'm with people who think that in a world with today's Python, Perl serves very little purpose and wish that no new code was written in it. (Of course, I also think that about C, with partial exceptions for actual embedded systems, so take that with a grain of salt.)

Yeah, Pythoners have been dis'ing Perl from the start. I'd wish they would grow up.

I've been dissing it well before I knew much about Python. You can feel free to like it if you want, but I'm more than content not having to deal with it. But I won't say any more about it in this thread.

I'm a Rubyer and making fun of Perl is a favorite pastime of mine.

Well, I've been taught not to pick on those less fortunate than me. That's why I don't dis Python or Ruby.

Maelstrom. wrote:Python 3 has 'correct' division by default, instead of integer division. Your argument is invalid as soon as Python 3 hits the main stream

Which will be a while. Many OSes are keeping v2 since it's backward compatible with all the old Python code. We still have COBOL hanging around for the same reason; Python 2 is not going away very fast.

Programmers have to remember that integer division is not real division. And the more a programmer has to remember, the greater the chances of a bug. Remember: datatypes were invented by compiler designers to make writing compilers easier; they were not invented to make programming easier.

Maybe I'm just weird, but I think it makes sense for (traditional) Python to use integer division when dividing one integer by another. OTOH, I tend to explicitly use the // operator for integer division and to use a float() "cast" when I specifically desire real division. Maybe some people find this aspect of Python to be annoying or confusing, but I don't.

I used to enjoy programming in Amiga E, a rather powerful object-oriented compiled language. One of its quirky features was that it used "calculator precedence" for arithmetic, ie operators were evaluated in strict left to right order with no precedence, apart from that dictated by parentheses. It was annoying at first, but you soon got used to it.

PM 2Ring wrote:One of its quirky features was that it used "calculator precedence" for arithmetic, ie operators were evaluated in strict left to right order with no precedence, apart from that dictated by parentheses. It was annoying at first, but you soon got used to it.

HP calculators have post-fix notation. It is annoying at first, but you soon get to hate it.

PM 2Ring wrote:Maybe I'm just weird, but I think it makes sense for (traditional) Python to use integer division when dividing one integer by another.

^ That.

It's quite possible this is simply because I'm used to C, but integer division among integers makes sense to me. In almost every situation where I want a floating-point answer, I already have floating point inputs.

Vaniver wrote:Harvard is a hedge fund that runs the most prestigious dating agency in the world, and incidentally employs famous scientists to do research.

afuzzyduck wrote:ITS MEANT TO BE FLUTTERSHY BUT I JUST SEE AAERIELE! CURSE YOU FORA!

shawnhcorey wrote:Programmers have to remember that integer division is not real division. And the more a programmer has to remember, the greater the chances of a bug. Remember: datatypes were invented by compiler designers to make writing compilers easier; they were not invented to make programming easier.

I don't think thats correct. Data types were invented because not all values used in a program have the same type.

Because the inventors of the programming language this is written in apparently thought that real division is the only correct division and that all non-complex numbers should share the same data type.Yes, the code is incredibly ugly, I think that it is really the worst thing I ever wrote in my life. And no, the programming language had no integer types, integer division, bitwise shift, bitwise or, bitwise and or any other operator that worked directly on integer variables.

shawnhcorey wrote:HP calculators have post-fix notation. It is annoying at first, but you soon get to hate it.

I quite like postfix notation: I was rather intrigued by it when I first saw a HP calculator in the early 1970s, but I've never owned one myself. I have used postfix notation quite a lot in the last couple of decades, though, since I enjoy writing in PostScript. I admit it does take me a few minutes to get my brain into (or out of) postfix mode, but once I am in postfix mode I find it quite easy to read and write. I suppose it's fair to say that writing PostScript is slightly easier than reading it, but I tend to structure my PostScript programs to make them human-friendly and I rarely have problems understanding PostScript programs I wrote years ago.

PM 2Ring wrote:Maybe I'm just weird, but I think it makes sense for (traditional) Python to use integer division when dividing one integer by another.

^ That.

It's quite possible this is simply because I'm used to C, but integer division among integers makes sense to me. In almost every situation where I want a floating-point answer, I already have floating point inputs.

Agreed. I can't think of any situation where I had division where I wasn't taking advantage of integer division or using floating point numbers to begin with.

Nothing has changed at the end of our path; knowing only the cruel leads the way to our fall.And there's no long anyone left by me. As the blind leads the blind to his faith,but only to find he remains unforgiven. So he turns but his angel is already gone.

Haskell looked at all the different options for division and said "screw it, let's just put all of 'em in there". And so it has all three of floating-point-division, integer-division-rounded-down and integer-division-rounded-toward-0, each with its own name.

I’m learning CSS, and I’d like the h2 elements to have a background image. The difficult part, for me, is positioning the image relative to the text. To my own surprise, I came up with something that kind of works:

and <h2 class="bluebg">, which allows you to move the text/image*, but I’m pretty sure that is not the best way to do that. Do you know a better solution?

* If the image is 400x79, a height greater than 79 will move the image down without affecting the text. height: 59px and padding-top: 20px, on the other hand, will move the text down by 20px without affecting the image.

Huh, I didn’t know that, thanks. I don’t have a live webpage yet. I guess what bothered me with this method was that the position of the text didn’t stay the same, but then I realized that this is easy to fix with position: relative.

I'm slightly confused about what you're trying to achieve. :/ A live example would let me give you much better advice than just guessing. It sounds like you may be overcomplicating things, but I can't tell right now.

Positioning things with CSS is rather counterintuitive (stupid box models). So when you declare a width of 400px and a left padding of 60px, you're actually defining the element size as 460px. (To get around this, you can actually set a -webkit-box-sizing: border-box; rule, though I'm not sure how well-supported that is; there's also a -moz- version too, at least.)

So yes, what you're doing is, at least according to the specs, defining your element's content to be 400px wide, then you add 60px space to the left of that content, and the background image should span all of that, up to the borders. It can be quite confusing, yes. You'll get the hang of it. What you're doing is pretty much the "right" way.

@Xanthir: I think he's trying to place HTML text that's pushed slightly to the right, and overlaying that on top of an image. Like this. Presumably the background image involves something on the left of the text.