huckfinnaafb

This is a fallacy listed, "the fallacy fallacy", first column second row on the left with the symbol of a fractal.

The character set is also optional if sent as an http header.

http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2

And a supporting talk by paul irish http://paulirish.com/2011/primitives-html5-video/

Then Java, Chrome, Ruby, Rails, Bash, Curl, Python, Apache, Lynx, Scheme, Unity and dozens of other project names must infuriate you :).

The difference being that Diablo 3 has an in-game real-money market, and more people playing the game means more people putting money into that market. The same strategy has been applied (successfully) with Team Fortress 2.

This is not a new idea, either. Free to play but in-game real-money purchases have been going strong with casual games since it became easy to send money over the net.

I'm not saying it will happen, but it's not an impossibility.

Creating software that helps whoever uses it is the only immediate requisite for being a useful programmer.

Ridiculous. Coming to your partner's defense is not a matter of gender, but one of loyalty. Reverse the genders in this case and the threat still applies.

>I break about half of those rules and it works very, very well.

Can you go into more detail about which rules you disagree with or find unnecessary?

Working on a project with no set style standard, this article does a good job of voicing my frustrations. When tasked with inventing a new piece of the software, each designer, programmer, and manager tends to disregard all previous design decisions and create their own idea of what the project should look like. It's resulted in a totally inconsistent look, each page only bearing a passing semblance of the one before.

But a living style guide is worth nothing if the team members willfully choose to ignore it and pursue their own style agendas (and they are personal agendas, make no mistake). I've implemented some seriously ugly interfaces in the name of consistency, and the project is better for it.

The biggest hurdle is convincing management that this new flashy module simply does not mesh with the rest of the software. Design wants to impress, management is impressed, off to the nerds to implement it.

Some issues...

Even using the grid normally, it ends up using more horizontal space than on the viewport, forcing a horizontal scrollbar (Chrome 18).

Another problem: setting max-widths on units. Any proceeding units are handicapped by this and often just leave empty space to the right.

I also don't like the presence of three sets of classes when two would be appropriate. "ingrid" as the container, and "span-x" for each column division. And this is unavoidable, as you need to define "in-[parts]" in the container to even use the span-x classes. I understand that it's less work if you stick to equal parts, but this is not the majority use case in my experience.

I find the naming scheme awkward. "in-twos" and "in-thirds" instead of "in-halves" or "in-threes". Keep it consistent.

---

All in all, I wouldn't recommend this to my mother.

I use Nicole Sullivan's snippet in her github project, https://github.com/stubbornella/oocss/blob/master/core/grid/...

(demo: http://oocss.org/grids_docs.html)

And it's been damn bullet proof, being used in production code.

Depending on the severity of your "ums", this is a facet "normal people" may need not perfect (or even need to work on).

This article is the minimum strategy, the 80% of a good presentation. Ums are a detractor but not as much a one as poor product knowledge or mechanical storytelling.

The entire "More" menu seems out of place. I would expect it to have options related to search, and a few items in there definitely are relevant, but the presence of the Privacy and Feedback links make it seem like things were thrown in there because there wasn't anywhere else for them to go.

Minor comment: the spacing between the top of the page and the top of the search bar is inequal to the spacing from the bottom of the search bar to the top of the content body. 2px top margin to the #search_form seems to balance that out.

Otherwise, looks great. Love what you've done with the place.

What was your motivation to use fixed pixel widths for grid sections instead of percentages?

"Do we really need yet another boilerplate? Yes."

Not entirely convincing :P

Can anyone explain exactly why this is sinister? If the label is aware of the price they're selling the license at and buying the data, where is the unfair deception?

Of course views/week is not necessarily the best measure of success. Those 5 views a week for 500 questions may have been excellent matches, whereas hundreds might have been poor matches. I admit though that it's more likely a numbers game.

There's good code, which is something that good products build their foundation on, and near perfect code, which can get in the way of building realistic solutions on time.

>Do you really need a full objet-oriented API right now? Do you really need to make a dozen interwoven classes, when it’s possible just a hundred or so lines in one class will do fine? Can you do all the same error checking and unit tests in a much smaller code base?

This is not necessarily "good code". That's code you think is good. Excessive or complex code is not good code, and I think the author should redefine his usage to what programmers sometimes perceive as good code.

Not that it matters, at all. It's a gift, an endorsement.

It really doesn't look like variables to me. A variable would be a reference to a singularly defined property, such as a color or border style, not a hook to an entire list of properties. Certainly it could be used as a variable: that is, defining a class with a single property and hooking to that. But let's assume it's being used as a variable, why not write something like this?

    .data { 
        font-size:11px;
        font-family:Courier;
        color: #555;
    }
    .magic { 
        color: royalBlue;
    }

    <p class="data magic">Magical data</p>
    <p>Normal text with <span class="magic">magical <span class="data">data</span></span>.</p>

I've inherited .magic into .data without sacrificing the ability to use .magic and .data by itself. As long as you keep your CSS classes semantic and disperse them intelligently into the markup, it's really not an issue of making large scale changes with minimal effort. Of course, in practice, this isn't always the case, but I think adding more ways to inherit properties will increase complexity more than help write good styles.

I think the outcry for these features is a symptom of a poor understanding of the cascade and the language. There are much larger issues I'd like to see addressed, like the wide adoption of layout definitions which has better rules for defining vertical positioning and more fluid widths, both of which are pretty nightmarish without resorting to tables.

I'm torn on this. Inheritance already exists through assigning multiple classes and the cascade, and now it's impossible to use a "child" class without dragging its parent along with it unless you override "apply" inline.

Not terribly clear as to why we need specific functionality for inheritance when we already have an expressive way of defining it.

Of course he might not do it at all.

Correct me if I'm wrong here, but a site can't "be" HTML5. It can use technologies that require browsers which have implemented it from the HTML5 draft, but there is not a watershed to it.

I think the whole marketing fiasco has really warped the perception of what it means to use HTML5. Implemented HTML5 tech should be considered more of a supplemental library than a platform or language.

The existing moderators can elect new moderators who can carry it on. The current (and only) mod is currently simply choosing not to, and made his intentions clear in that regard.

> "Everytime, and I mean everytime, I see IceFrog given credit to DotA, there will always be that guy who tries to discredit him"

Probably because the claim he invented DotA is wrong. I'm not trying to discredit him, he's probably the single largest single contributor to the genre. But saying he invented it is wrong and a smack in the face to those who did.

Valve may have creative rights on the details, but I'd be surprised if they could convince a judge that they own the rights to a whole genre of gaming. Especially when there's already a plethora of popular games already under it.

IceFrog isn't strictly the author of DotA. DotA is, if memory serves, based on an even older mod called Aeon of Strife. And DotA's development history is riddled with support from the WC3 mapping community so it's really unfair to name any one individual as a sole creator or rights holder. There really is no rights holder to the game and there have been at least 3 major releases by distinct developing groups: Demigod (GPG), LoL and HoN.

I'm not sure why a legally counselled written contract wouldn't be considered legally binding.

The sudden explosion in other form factors has people thinking they'll somehow replace the desktop. Unless my office starts making everyone work on a tablet, this is not the case.

Is developing for Facebook not painful?

I know brands tend to go after any and all cases where the IP is even remotely related, but I wonder if this is a concentrated effort by Bethesda as they view "Scrolls" an actual threat, or just a knee jerk reaction to a game they might see as amateur. If the former, it will be interesting to watch the community's reaction to a prolonged legal assault on Minecraft. I know it's causing a big stink in some parts of the internet already.

22 years old, it guessed I was 25-34.

This is full viewport, not fullscreen. Which I guess is fullscreen if you tap F11.

Edit - Scrap that, only works in Safari. My mistake.